Rozšírené hľadanie
Piatok 29. November 2024 |
meniny má Vratko
WebExpo 2022: konference optimalizovaná pro frontendisty

26.07.2022 11:30 Když si prolistujete historii Vzhůru dolů, asi nebude potřeba zdůrazňovat, že WebExpo je pro mě srdeční záležitost. Letošní ročník je pro mě však velmi speciální. Alespoň trochu jsem participoval skoro na každém ročníku, během 10. - 12. června 2022 bude ale můj rukopis znát více než obvykle. Věřím, že WebExpo 2022 bude speciální pro celou českou frontendovou komunitu. Hned vám řeknu proč. Spolupráce komunity Frontendisti.cz a WebExpo Po loňském online FrontKonu jsme letos chtěli uspořádat živou konferenci komunity frontendistek a frontendistů. Pracovali jsme ve štábu s různými variantami, ale nakonec přijali nabídku Šárky Štrossové, aby naše konference byla součástí WebExpa. Řeknu vám, proč si myslím, že to je pro české a slovenské frontendisty dobrá zpráva. V prvé řadě: konference bude, to samo o sobě není zlé. :) Za druhé: organizačně bude akce obstarána profi týmem WebExpa a to na úžasném místě, v kině Lucerna v centru Prahy. No a v neposlední řadě: cílem spolku Frontendisti.cz je nejen komunitu vzdělávat, ale také propojovat. WebExpo je pro tyto účely ideální. Jednak je prostředí konference výborné pro networking a jednak přijede řada lidí ze zahraničí, ale také řada designérů, marketérů, webových manažerů… WebExpo má letos samá frontendová lákadla V tu chvíli se prostě centrum Prahy stane místem pro popovídání s někým, kdo věci vidí jinak a uvažuje jinak. Místem pro vzájemnou inspiraci. Výsledkem naší spolupráce je sobotní část programu, která má název Collab with Frontendisti.cz. Z programu, který jsme pečlivě sestavovali ze spousty přihlášených přednášek a na základě zkušeností s FrontKonem, vybírám následující oblasti: JS frameworky: React 18 Features od Břeti Profta a Terezy Vaňkové nebo Remix Run od Martina Macháčka . JavaScript: Promises Rikiho Fridricha a Railway Oriented Typescript Robina Pokorného. CSS a HTML: Cascade Layers, které představí Ondřej Žára a HTML can do that? Tomáše Pustelníka . Rychlost webu zastupuje Michal Matuška a jeho optimalizace Web Vitals pomocí webfontů. Svět CMS: JAMstack - Ondřej Polesný a State of CMS - Honza Sládek . Nestačí to? Mrkám na účastníky FrontKontu, kteří vědí že na místě vás 11. června ještě čeká několik překvapení. Vstupné na naši část programu je výrazně nižší než na celou konferenci. Nyní stojí 125 €. Doufám, že se vám náš program bude líbit. Ale zvažte také koupi lístku na celou konferenci. Další program WebExpo Pokud jde o program mimo sekci frontendistů, asi nejvíc mě zaujala jedna přednáška a jedna diskuze: Simple Machine Learning For Web Developers: From Theory To Practice O strojovém učení bych se strašně rád dozvěděl více, ale vždycky to na mě bylo trošku „heavy“. Vyslal jsem dotaz autorovi přednášky a odpověď mě nalákala: …pro nezkušené bude k dispozici několik živých, online hostovaných ukázek, např. rozpoznávání ručně psaných písmen nebo detekce objektů na fotografii. Ty fungují bez jakéhokoli backendu, jen v prohlížeči, takže diváci mohou k těmto ukázkám přistupovat ze svých mobilních zařízení a hrát si s nimi, aby pochopili možnosti neuronových sítí na straně frontendu. Tuhle přednášku tedy nemůžu minout. Roundtable Discussion: How To Find Time For Technical Improvements Problém, který řešíme při konzultacích k rychlosti webu snad u většiny klientů. Jak na to všechno najít u vývojářů čas, když jsou tlačení do přidávání nových vlastností produktu? Jsem zvědavý, s čím přijde tato diskuze. Pavel Kalandra mi napsal tento první tip z Mews: Když připravujeme workload na nějaký čas dopředu, plánujeme produktovou roadmapu zvlášť od technické roadmapy. Takže máme garantované určité procento času, kde si pak tech lead sám určí, co je pro něho největší priorita. I tuto páteční diskuzi tedy přidávám do programu. A co další lákadla WebExpa? Když se podíváme na frontend a okolí, je toho hodně. Shrnu to do odrážek: Vitaly Friedman o designu složitých rozhraní. Prabashwara Seneviratne o vývoji her pomocí HTML. Tom Krcha o produktovém řízení, např. pro Adobe XD. Michal Sänger o GraphQL na velkých projektech. Runa Sandvik o technologiích, které podporují svobodu slova . Jan Toman a jeho Data-Informed Design Systems. Podívejte se také na workshopy – o frontendu, UX, přístupnosti, ale také například bezpečnosti. No a nemohou chybět parties a program pro děti, na který se těší i naši kluci. Jako vždy i letos můžete využít 15 % slevu na konferenční vstupenku. Kód je vzhurudolu. Ahoj 10. - 12. června na WebExpu!

Metrika „Kumulativní posun layoutu“

23.07.2022 17:00 Metrika, která udává stabilitu vzhledu stránky během vykreslování. Jedná se o jednu z metrik rychlosti webu, i když v tomto případě bychom mohli mluvit spíše obecněji o metrikách uživatelském zážitku . Metrika Cumulative Layout Shift je velmi důležitá, protože je součástí Core Web Vitals a zohledňuje se v rámci signálů Google Page Experience. CLS udává součet posunů layoutu v rámci nejhoršího pětivteřinového okna během používání stránky. Vašim cílem je tedy zajistit co nejvyšší vizuální stabilitu. Problémy, které řeší Všichni to známe. Stránka vypadá, že je vykreslená… už už se chystáme kliknout… ale v tom se spustí externí skript, posune nám rozvržení a my klikáme na reklamu. Vtipně to popisuje následující video od autorů metriky z Googlu: To, že stránky během vykreslování „poskakují“ není nic nového ani nečekaného. Vyplývá to z asynchronní povahy některých prvků webu. Do stránek se totiž vkládají až po prvotním vykreslení. Potíže může dělat například: webový font, který se nahrazuje systémové písmo, obrázek nebo video bez definovaných rozměrů, komponenta třetí strany, která se vykreslí pozdě a ještě mění velikost špatně provedené animace v CSS Na možné problémy a jejich řešení se ještě v textu podíváme. Nejprve ale něco ke způsobu počítání CLS. CLS skóre Nástroje měřící Cumulative Layout Shift vrací číslo mezi 0 a 1. Čím je hodnota nižší, tím lépe. Z textu o Web Vitals už víte, že metriky mají tři různé intervaly hodnot. Takto je to u CLS: Hodnota LCP Mobil Desktop Dobrá ≤ 0,1 ≤ 0,1 Vyžaduje zlepšení ≤ 0,25 ≤ 0,25 Špatný > 0,25 > 0,25 Vašim cílem tedy je dostat se pod hodnotu 0,1 nebo v horším případě nepřekročit 0,25. V nástrojích Lighthouse nebo PageSpeed Insights se metrika CLS do celkového skóre projevuje váhou 15 %. Obrázek: Metrika CLS. Ideální je samozřejmě měřit CLS na celé skupině vašich návštěvníků, například pomocí Chrome UX Reportu. Ten vám pro vaši doménu vrátí 75. percentil hodnot CLS u všech shlédnutí stránek. Jak se CLS počítá? Cumulative Layout Shift původně představoval součet všech posunů layoutu během celého používání stránky. V roce 2021 se ale výpočet pro potřeby Web Vitals změnil. Autoři z Google to popisují takto: Maximální okno relace omezené na 5 sekund se sekundovou mezerou. No tak díky. Osobně mi trvalo týdny, než jsem tuto definici rozklíčoval. Podívejte se na obrázek a já se vám to pokusím vysvětlit. Obrázek: Nové počítání metriky CLS. Vezme se jen jedno, nehorší okno. Zde Session Window 1. Následuje dekódování šifer: Nechtěné posuny se počítají vždy do oken relací o délce maximálně pět vteřin. Pokud nastane vteřina bez posunů, okno se ukončí dříve než po pěti vteřinách. V rámci celého trvání návštěvy konkrétního URL se pak vybere jen to nejhorší okno . To se uvede jako CLS pro tuto stránku. Tento nový výpočet má zamezit zbytečně velkým hodnotám CLS u návštěv, kde je uživatel dlouho na jednom URL. Myslím, že problém zde byl hlavně s nekonečným scrollováním a podobným kejklemi. Na většinu stránek se tento nový výpočet nijak neprojevil. Pokud by vás snad zajímaly detaily o tom, jak se tato metrika přesně počítá, zavítejte na web.dev, kde to lidé z Googlu rozebírají. Pro potřeby počítání této metriky, ale také vlastních měření vzniká Layout Instability API s rozhraním LayoutShift, které má podporu v prohlížečích vycházejících z Chrome. To jen, pokud by vás to nějak moc zajímalo. Jak to měřit? CLS je možné získat jak ze syntetických měření, tak od reálných uživatelů . Obrázek: Ideální stav. Web layoutstability.rocks vám CLS změří jednoduše a rychle. Jako vždy se i tady mohou výsledky i výrazně lišit, protože nástroje pro syntetická měření umí CLS získat pouze z úvodního načtení stránky, kdežto uživatelská měření obvykle měří celý průběh používání stránky. Výsledky se liší i v rámci nástrojů sledujících reálné uživatele . Náš oblíbený SpeedCurve například počítá CLS také jen pro první viewport. Syntetická měření CLS umí strojově vytáhnout například tyto nástroje: Web layoutstability.rocks PageSpeed Insights WebpageTest Lighthouse Měření uživatelů Data od reálných uživatelů vám poskytnou například následující nástroje: PageSpeed Insights Search Console Chrome User Experience Report Rozšíření pro Chrome „Web Vitals“ JS knihovna web-vitals Na závěr se podíváme na obecné tipy, jak vylepšit špatné CLS. Optimalizace CLS Zamezte poskakování při vykreslování. Zaměřte se na to, abyste v layoutu rezervovali prostor obsahu, který se bude vykreslovat asynchronně – webfontům, obrázkům, videím, komponentám vykreslovaným asynchronním JS: Obrázkům nastavte vždy poměr stran pomocí parametrů width a height. Dalšímu asynchronnímu obsahu jako je video, prvek iframe nebo komponenty vykreslované pomocí JS držte prostor pomocí technik jako je trik s paddingem. Zajistěte, aby vlastní font nezpůsobil při nahrazování výchozího písma výrazné překreslení stránky. Animujte vždy CSS vlastnosti, které se umí renderovat pomocí GPU, takže např. transform:translateY namísto top. Na místo indikátorů načítání používejte tzv. „skeletony“, které napodobují obsah, na který uživatel čeká. Ale buďte s nimi opatrní, špatná implementace skeletonů z mé zkušenosti často CLS ještě zhorší. Fanoušky AMP by mohlo zajímat, že tento framework je stavěný od samých základů tak, aby se CLS rovnalo nebo blížilo nule. Další obecná doporučení v angličtině od Googlu jsou na web.dev. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .

S Petrou Dolejšovou a Martinem Koptou o soukromí na webu

22.07.2022 07:46 Pojďme už lišty nechat lištami a zamyslet se nad důvody, proč vlastně my webaři máme řešit soukromí uživatelů. Chtějí to uživatelé nebo se jen EU zbláznila? Zkusme přijít na to, jak asi bude vypadat soukromí na webu z pohledu tvůrce webů za pár let. Kdy přijde norma ePrivacy a co to vlastně je? Zakáže nám EU po pomazánkovém másle i Google Analytics? Přejeme vám příjemný poslech. Podcast MP3 ke stažení My webaři si vždycky nějak poradíme. Zvládli jsem GDPR, teď i cookie lišty. Přesto je pro nás téma soukromí uživatelů stále plné otazníků. Aktuální spory EU s americkými korporacemi ohledně používání Google Analytics nebo Google Fonts, výhružky Facebooku, že může opustit evropský trh to ukazují. Do toho vstupují různé postoje různých advokátů. Situace ohledně soukromí se prostě pro běžného webaře stále více komplikuje. V budoucnu leccos může řešit a zjednodušit norma ePrivacy, opět od EU, ale nyní je, alespoň podle Martina Kopty, řada na technologických gigantech, zejména výrobcích prohlížečů. Přes to všechno jsou zde slibné signály od českého Úřadu pro ochranu osobních údajů, který podle Petry Dolejšové sice začne s kontrolami, ale nebude řešit malé ryby a i u velkých bude podstatné, aby ukázali snahu situaci řešit. Takže nervozita je, hlavně u menších webů, možná zbytečná a situace nám dává možnost se ještě chvíli v klidu učit chápat problematiku a třeba nevyžadovat ze soukromí uživatelů něco, co nakonec nepotřebujeme. Hosté Petra Dolejšová Petra je advokátka na volné noze a zabývá se právem v marketingu, e-commerce, GDPR a médii. Říká o sobě, že boří mýty o nudných právnících a že z cookie lišt už jí krapet píská v uchu. Twitter, LinkedIn, petradolejsova.cz Martin Kopta Martin je jeden z nejzkušenějších českých UXáků. Nyní Product Manager v Tipsportu. Board member v Asociaci UX. Budoucí webaře učí na FIS VŠE v Praze. Twitter, LinkedIn O čem mluvíme? Proč potřebujeme řešit soukromí na webu? Chtějí to vlastně uživatelé? Načítání dat o provozu jako senzor v prohlížečích, který můžeme povolit. Je to o hodných a zlých firmách nebo o možnosti zakázat. Zbytečná démonizace cookies a svobodná vůle uživatele. Odkud jdeme a kam směřujeme? GDPR, cookie lišta, ePrivacy Poněkud otravná forma cookie lišty Někdy možná přehnaně opatrný přístup advokátů ePrivacy a budoucnost soukromí v EU. Kdy stav doženou tech giganti? Kauza Google Fonts a Google Analytics. O co jde v boji EU s korporáty z USA? Alternativy ke Google Analytics. Postoj Úřadu pro ochranu osobních údajů. Snaha se prý cení. Bude možné řešení bez právníků pro malé ryby? Prý stačí zdravý selský rozum. Co se budeme muset naučit my, webaři? Dále na Vzhůru dolů Jak jsem web zbavoval šmírovacích cookies Cookie lišta GDPR Odebírejte podcast ze Vzhůru dolů Spotify – iTunes – Google Podcasty – TuneIn – Anchor – RSS podcastů. Pište nám na e-mail podcast@vzhurudolu.cz.

Novinky z Google I/O 2022 a proč prohlížeče najednou táhnou za jeden provaz?

20.07.2022 22:30 Google na každoroční konferenci pro vývojáře mnohé oznámil a leccos ukázal. Akci jako celek nesleduji, ale během ní a po ní si ze záznamů a ohlasů na socsítích vyzobávám to, co mě nejvíc zajímá – frontend, a tedy HTML, CSS, performance a občas trochu JavaScript. Mám pocit, že letos to bylo docela velké. A hlavně se jedna podstatná věc změnila – prohlížeče si méně konkurují a více spolupracují. Alespoň z pohledu webového vývojáře. Proč na Vzhůru dolů píšu zrovna o letošním ročníku? Letos jsem se rozhodl, že se o ty novinky musím podělit i s vámi, čtenáři Vzhůru dolů. Jednak zde vnímám dluh, protože jsem se téhle konferenci zde ještě přímo nevěnoval. Ale ten bezprostřední impulz k sepsání byl jiný. Nejspíš patřím mezi nejstarší frontendisty v Česku. Nás, starochy, spojuje obvykle jedna věc – povyk kolem nových technologií a kolem nových úžasných možností prohlížečů nás nechává relativně chladnými. Už jsme to zažili mnohokrát a to také u technologií, které se prostě neujaly. Zdá se mi ovšem, že Google I/O 2022 vcelku slušně vyhajpoval i relativně klidného Michálka. Novinek, zejména kolem CSS, je strašně moc a navíc bych řekl, že mnoho z nich může být onen pověstný „game-changer“. Vezměme třeba Container Queries, selektor „rodiče“ :has nebo Cascade Layers . Už jen tato trojice pravděpodobně výrazně změní způsob, jak píšeme styly, pričemž zdaleka nejde o osamocené novinky v CSS. Když jsem pátral po příčinách implementace tolika novinek a zároveň v tolika prohlížečích najednou, musel jsem skončit u Rachel Andrew. Tolik novinek a podpora v prohlížečích k tomu. Díky Compat 2021 a Interop 2022! Vývojáři prohlížečů totiž prakticky poprvé v historii spolupracují, aby vyřešili nekompatibility v podpoře webových technologiích. Loni byla výstupem iniciativa Compat 2021, která pomohla vyřešit nepříjemné rozdíly v implementaci gridu a flexboxu – a například také přidat použitelnost vlastnosti gap ve flexboxu. Letošní iniciativa Interop 2022 má za úkol sladit priority ve vývoji a je domluveno, že prohlížeče co nejdříve naimplementují tyto vlastnosti: Color spaces & CSS color functions - pro míchání barev známé ze Sassu, color-contrast - pro automatický výběr správně kontrastní barvy) Jednotky pro viewport Scrollování Subgrid CSS Containment Už se naopak povedlo naimplementovat následující: Cascade layers accent-color bfcache Vlastnost size-adjust Je toho více a vypadá to opravdu zajímavě. Podstatné je, že skupina lidí sdružená v této iniciativě stanovuje prioritizaci vývoje technologií i na základě průzkumů mezi vývojáři , což je myslím docela silný důvod se takových dotazníkových šetření zúčastnit. Průběžný vývoj můžete sledovat na webu Interop 2022 Dashboard. Mimochodem, aktuálně tam skóring vede Safari, což je už několikátý signál o velkých změnách ve vedení vývoje tohoto zaostávajícího prohlížeče. Abych to shrnul – vývoj specifikací a jejich implementací v prohlížečích byl překotný po celou dobu zhruba poslední dekády. Změnilo se to, že výrobci prohlížečů synchronizují priority v implementaci. My vývojáři z toho budeme profitovat tak, že důležité novinky uvidíme v krátké době ve všech moderních prohlížečích. Co mě na Google I/O dále zaujalo? Tohle měl být stručný článek, takže si toho hodně budu muset nechat pro sebe. Nebo víte co? Ty další zajímavosti zde uvedu alespoň na jedné malé číslované hromádce. K rychlosti: Video, jak optimalizovat metriku LCP. Nová metrika Interaction to Next Paint , která asi jednou nahradí FID. Video o jejím vzniku. Rozšířená realita v brýlích v kombinaci s překladačem umožňuje lidem povídat si spolu. Twitter. Chrome na Androidu umožní při platbách kartou generovat jednorázové číslo. Twitter. Page Transitions umožní animovat přechody mezi stránkami, tohle je fakt cool! Video. Google pak důležité novinky shrnuje v článku. Co zaujalo vás? Napište na Twitter nebo Facebook Vzhůru dolů. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .

Ohlédnutí za WebExpo 2022

19.07.2022 13:30 Změny ve vývoji prohlížečů, zase to Safari, Railway oriented TypeScript, parties na WebExpu, nové vlastnosti v HTML, verzování CSS a jeho výhody, Cascade Layers a ITCSS, JS promisy, Remix, JAMstack… probrali jsme toho opravdu hodně. Tentokrát bylo to natáčení ale opravdu speciální. Viděli jsme se poprvé na živo a s publikem, v malém kině Lucerna, hned po skončení WebExpo 2022. Nebylo to osobní setkání po čtyřech letech natáčení trošku zvláštní? Podcast Dále: MP3 ke stažení, audiozáznam na YouTube. O čem mluvíme? Martin a jeho příspěvek o Compat 2021 a Interop 2022 Změny ve vývoji Safari Robinův Railway Oriented JavaScript Lidi na WebExpu: Češi vs. zahraniční návštěvníci Novinky v HTML jako dialog. Atomizace našich oborů. Sleduje někdo vůbec novinky v HTML? Proč by se CSS zase mělo začít verzovat? Vzpomínáme na CSS3 Potřebujeme vlastně ještě nativní UI elementy jako je právě dialog ? CSS Cascade Layers a taky metodika ITCSS Promisy v JavaScriptu a JAMstack, Next, Gatsby, Remix… je toho hodně a co vybrat? Důležitost Developer Experience Co bude další velká věc na frontendu? Konec Sassu, WebAssembly… Těšíme se na viděnou na dalším WebExpu, a to 19. - 21. dubna 2023! Odebírejte podcast ze Vzhůru dolů Spotify – iTunes – Google Podcasty – TuneIn – Anchor – RSS podcastů. Pište nám na e-mail podcast@vzhurudolu.cz.

Nová kniha „CSS: moderní layout“ je tady!

14.07.2022 01:00 Milé čtenářky, milí čtenáři, dnes vydávám svou novou knihu pojmenovanou „CSS: moderní layout“. Pusťte se s její pomocí do moderních metod, které vám ušetří spoustu času a poskytnou nové možnosti jak tvořit design webů. Z původně zamýšleného e-booku o CSS gridu se po dvou a půl letech práce stal komplexní průvodce všemi systémy tvorby layoutu ve stylech – gridem, flexboxem, zarovnávání boxů a vícesloupcovým rozvržením. To vše představuji na 440 stranách tištěné knihy. V knize je 170 ukázek v CodePenech a 11 příkladů nakódovaných v podobě tutoriálu. Vše doplňují desítky ilustrací, které v barevném tisku vypadají výborně a mám z nich obzvlášť radost. Mou ambicí bylo vytvořit skutečně komplexní příručku, kterou doufám ocení i zkušenější mezi vámi. Knihu „CSS: moderní layout“ si můžete objednat hned teď: Kniha s e-bookem stojí 899 Kč s DPH a poštovným. Tištěnou knihu můžete mít do několika pracovních dní za 699 Kč. E-book v PDF, EPUB a MOBI lze mít hned za 399 Kč. Těším se, co na ni řeknete! Zdraví vás Martin Michálek

Selektory v CSS: znáte je všechny?

07.07.2022 06:45 Tímto textem v příručce doplňuji mezery, které mám na Vzhůru dolů v oblasti pokrytí základů CSS. Při rešerši jsem si všiml, že takto komplexně se selektory snad žádný český text nezabývá. Tož tady jeden máte. Jasně, cílím zde především na začátečníky, ale myslím, že osvěžit si tohle téma neuškodí ani pokročilým. Pojďme se nejprve podívat na tabulkové shrnutí toho nejdůležitějšího, co v článku najdete. Nejdůležitější selektory Selektory vybírají určitou skupinu prvků v DOMu a dovolí ji stylovat. Selektor Zápis Třída .class Prvek tag Identifikátor #id Atribut Všechno * Nejdůležitější kombinátory Kombinátory spojují jednoduché selektory do složitějších skupin a umožňují, aby stylování platilo jen za určitých podmínek. Kombinátor Zápis Potomek A B Dítě A > B Následujícího sourozence A + B Pozdějšího sourozence A ~ B V článku zcela úmyslně neuvádím pseudotřídy, které mezi selektory v CSS bezpochyby patří. Ale pořád to tady chci udržet v rozsahu článku, nikoliv knížky. Text o pseudotřídách bude následovat. Selektory prvků Tyto selektory vybírají prvky z DOMu podle názvu HTML značky. tag – selektor typu Obsahuje název prvku HTML a představuje instanci tohoto typu prvku ve stromu dokumentu. Příklady: h1 – představuje všechny elementy v dokumentu. li span – vybírá všechny prvky zanořené v prvku . * – univerzální selektor Speciální varianta selektoru typu, který reprezentuje prvek libovolného typu. Příklady: * – představuje všechny elementy v dokumentu. body * .box – představuje prvek s třídou .box, který je v zanoření druhé úrovně v prvku . Selektory atributů Selektory, které vybírají prvky podle atributů – jejich existence, shody s jejich celou hodnotou nebo s částí hodnoty. .className – selektor třídy Jeden z nejznámějších a asi rovnou nejužitečnější selektor, který vybírá prvky podle třídy. Představuje prvky patřící do třídy identifikované pomocí atributu class v HTML. Příklad: … … … Selektor .a vybere jak , tak všechny . Další příklady: .heading – všechny prvky, které mají atribut class nastavený na heading. h1.heading – všechny prvky , které mají třídu heading. h1.heading.heading-large – všechny prvky , které mají třídu heading a zároveň heading-large. Možná jste si všimli, že zápis .heading je ekvivalentní zápisu vlnovkového selektoru atributu . Na selektorech třídy je dnes postaveno skoro celé stylování webů, vzpomeňme například metodiky OOCSS, BEM, ale i novější utility CSS. #id – selektor ID Selektor ID představuje instanci prvku s identifikátorem, který odpovídá hodnotě v atributu id. Příklad: … … … Selektor .a#first vybere jen . V HTML dokumentech je možné, aby jednomu ID selektoru odpovídalo více prvků, je to tak v pořádku z pohledu CSS selektoru, nikoliv ale samozřejmě z pohledu HTML sémantiky nebo přístupnosti. – selektory přítomnosti a hodnoty atributů Vybíráme, zda na prvku HTML existuje atribut nebo detekujeme jeho hodnotu. Toto jsou selektory, které hledají existenci atributu nebo jeho konkrétní hodnotu na HTML prvku. Typy selektorů atributů: Selektor Vysvětlení h1 Prvek , který má atribut title s jakoukoliv hodnotou. h1 Atributový selektor přesného obsahu. Prvek , který má atribut title v hodnotě přesně Ahoj. h1 Vlnovkový atributový selektor shody jedné hodnoty. Prvek , u něhož atribut title alespoň v jedné hodnotě obsahuje řetězec Ahoj. Hodnoty pro potřeby selektory oddělují mezerami, takže selektor splňuje. h1 Selektor shody prefixu. Toto je zvláštní. Vybraná hodnota musí být buď přesně Ahoj, nebo začínat Ahoj bezprostředně následovaná znakem -. Dává to smysl asi jen v případě výběru jazykových kódů. Např. odpovídá řetězcům en i en-US. – selektory podřetězců atributů Zvolíme prvky podle shody s částí hodnoty atributu. Jde o selektory pro hledání podřetězců v hodnotě atributu. Typy atributových selektorů podřetězců: Selektor Vysvětlení h1 Atributový selektor se stříškou reprezentuje prvek s atributem title, jehož hodnota začíná Ahoj. h1 Atributový selektor s dolarem reprezentuje prvek s atributem title, jehož hodnota končí Ahoj. h1 Atributový selektor s hvězdičkou reprezentuje prvek s atributem title, jehož hodnota obsahuje Ahoj. Ve všech případech selektorů podřetězců platí, že pokud by hodnota byla prázdný řetězec, pak selektor nepředstavuje nic. Prostě se selektorem daný prvek nevybere. – přepínač case-insensitivity Díky tomuto novému přepínači můžeme vypnout citlivost na rozlišování malých a velkých písmen. Standardně totiž selektory pro HTML malá a velká písmena rozlišují. Identifikátor i znamená „insensitive“ tedy nerozlišování velkých a malých písmen v selektoru. Příklady: h1 – vybere prvky s atributem title v hodnotě Ahoj, ale nikoliv už ahoj. h1 – vybere prvky s atributem title v hodnotě Ahoj a také ahoj. Mimochodem, i tenhle relativně nový přepínač podporují všechny moderní prohlížeče. Viz CanIUse.com. Podívejte se na demo od čtenáře Lukáše Chylíka. Identifikátor s před uzavírací závorkou značí „sensitive“, tedy citlivost na rozlišování velkých a malých písmen. Podporuje to nyní jen Firefox, ale vlastně s] v HTML není potřeba, protože jen kopíruje výchozí stav v prohlížečích. Kombinátory Kombinátory jsou speciální znaky, které umožňují kombinovat jednoduché selektory do složitějších a rozšiřovat platnost selektoru jen za splnění podmínek, jako je například vnoření prvku do určitého rodiče v DOMu. Kombinátor potomka Kombinátor s bílým znakem odděluje dva selektory a vybírá potomka , který je zanořený do určitého prvku A. Selektor ve tvaru A B představuje prvek B, který je libovolným potomkem nějakého předka prvku A. Příklad: … … … Selektor .box .a vybere prvek a také všechny prvky . Další příklady: .heading span – všechny prvky , které jsou potomkem prvků s třídou heading. h1 em – všechny prvky , které jsou potomkem prvku . h1 * em – všechny prvky , které jsou potomkem ve druhém a vyšším zanoření uvnitř prvku . A > B – kombinátor dítěte Kombinátor se znaménkem větší než vybírá prvek B, který je přímým potomkem prvku A. Tedy zatímco A B vybere B v jakékoliv úrovni zanoření uvnitř A, pak A > B vybírá jen ty B, které jsou přímými potomky A, tedy jeho „dětmi“. Vezměme příklad: … … … Selektor .box > .a vybere jen prvek . Další příklady: .heading > span – všechny prvky , které jsou přímým potomkem prvků s třídou heading. h1 > em – všechny prvky , které jsou přímým potomkem prvku . .box ol > li p – všechny prvky , které jsou potomkem , přičemž musí být přímým potomkem a potomkem libovolné úrovně v prvku s třídou .box. Mezera kolem kombinátoru dítěte je volitelná. h1 > em a h1>em je totožné. Pro lepší čitelnost zápisu se upřednostňuje zápis s mezerami. A + B – kombinátor vedlejšího sourozence Kombinátor s plus vybírá prvek B, který je vedlejším sourozencem A. Prvky reprezentované oběma selektory mají ve stromu dokumentu stejného rodiče a prvek reprezentovaný prvním bezprostředně předchází prvku reprezentovanému druhým . Máme zde příklad: … … … Selektor .a + p vybere jen prvek . Další příklady: h1 + p – prvek , který bezprostředně následuje za každým . h1.heading + h2 – prvek , který bezprostředně následuje po za každým s třídou heading. Mezery jsou opět volitelné. h1 + p je totéž jako h1+p, ale upřednostňujte tu první. A ~ B – kombinátor pozdějšího sourozence Kombinátor s vlnovkou vybírá prvek B, který je vedlejším sourozencem A, ale zároveň jej přímo nenásleduje. Oba prvky mají stejného rodiče. Rozdíl oproti A + B je u vlnovkového kombinátoru v tom, že prvky nutně nemusí být vedle sebe. Zpět k příkladu: … … … Selektor .a ~ p vybere prvky a . Další příklady: h1 ~ p – všechny prvky , které mají stejného rodiče jako . h1.heading ~ h2 – všechny prvky , které mají stejného rodiče jako s třídou heading. Mezery v selektoru jsou opět volitelné. Související „Problémy“ CSS Dědičnost Kaskáda a specificita Podpora v prohlížečích Všechny CSS selektory, které zde zmiňuji, jsou plně podporované ve všech prohlížečích, včetně MSIE. Jedinou výjimkou je přepínač citlivosti na velikost písmen , který už v tomto starém prohlížeči nerozchodíte. Je zde ale jedna skupina selektorů, zmíněná ve specifikaci Selectors Level 4, která podporu nemá. Selektory sloupců A || B – sloupcový kombinátor. Vybírá prvek A patřící ke sloupci B. Viz např. v tabulkách col.selected || td. Bylo by užitečné takový selektor mít, ale zatím to žádný prohlížeč nepodporuje, stejně jako podobně zaměřené pseudotřídy :nth-col a :nth-last-col . CanIUse.com Specifikace V pokračování tohoto textu se zaměřím na pseudotřídy v CSS, které jsou vlastně jen trošku zvláštní selektory. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .