Proměnné v CSS - lesk a bída standardizace

Řada webdesignerů se těší na brzké zavedení proměnných do CSS. Návrh specifikace vznikl velice rychle, WebKit je již implementoval a ačkoliv někteří s jejich zavedením nesouhlasí, vše se zdálo být na rychlé a bezproblémové cestě (což je ve světě webových standardů dosti neobvyklé!).

K jejich rychlému zavedení je třeba, aby byla včas specifikace prohlášena za stabilní, a aby prohlížeče CSS promněnné implementovaly. Obojí spolu souvisí. Čím dříve bude specifikace hotová, tím dříve se může objevit v prohlížečích a naopak čím dříve se objeví v některých prohlížečích, tím dříve může být hotova. (Že by kruh? Ale tak to prostě je.)

Ovšem od úterý probíhá v diskusní skupině CSS WG debata, ze které vyplývá, že nic není tak růžové. Dave Hyatt píše, že implementaci z WebKitu odstranil, protože ačkoliv všichni proměnné v CSS chtějí, nedaří se dohodnout, jak má jejich implementace vypadat:

It's off pending a decision of any kind. :) The feature works well, but it seems everyone has his/her own idea of how this feature should work, and nobody has the same opinion. I'm basically disgusted at this point and giving up on the whole feature.

A dodává, že nechce, aby se do ostré verze Safari (nebo Google Chrome) dostaly CSS proměnné v podobě, která není dosud jistá, protože tak dlouho očekávaná novinka by se začala rychle používat a WebKit by ji pak musel podporovat navěky, i přestože by oficiální implementace vypada úplně jinak:

The problem with leaving CSS variables turned on in WebKit is that if the feature ships, it is going to be hugely popular. We know this. Whatever we ship, we will have to support on OS X forever, because apps on the platform will scramble to use this feature.

Já sice chápu Davevovu opatrnost, ale myslím si, že přesně takovéhle nejisté oblasti jsou doménou vendor prefixů. Je to vlastně jeden z důvodů, proč se vendor prefixy používají a Dave toho (dle mě zbytečně) odmítá použít.

Na druhou stranu i ostatní prohlížeče obsahují vlastnosti, které sice jsou naprogramované, ale z nějakých důvodů se do veřejných verzí nedostávají (ať již nejsou dost otestované nebo by mohly být kontroverzní, případně se čeká na specifikaci), takže Davův postup není nijak výjimečný.

Pro designery to znamená jediné: CSS proměnných se sice dočkáme, ale možná přijdou ještě o něco později.

Pro zájemce celé vlákno [Css Variables] Variable Declaration Blocks.

Lesk a bída standardizace

Standardizace je pomalý proces. Sejde se vám kupa odborníků, každý má na věc jiný názor, no a teď standardizujte. Hlavně ale nepočítejte s tím, že se během pár měsíců na něčem dohodnete! Dejte si raději rezervu jednoho roku. Minimálně! Jen několik měsíců může trvat výběr správného názvu jednotlivých funkcí!

V HTML5 funguje (ano, skutečně to funguje!) metoda osvíceného diktátora. Všichni se pár týdnů o podobě nové vlastnosti hádají, pak si Ian Hickson sedne, sepíše návrh specifikace a zveřejní ji (tedy de facto rozhodne sám a za sebe, byť na základě návrhů ostatních). Následně se všichni hádají o jeho návrhu a objeví se pár blogpostů, že Hickson celou skupinou manipuluje a nikdo kromě něj nemá na specifikaci vliv, nebo někdo ze skupiny protestně odejde.

Hickson ty nadávky igronuje a podívá se na kritiku návrhu, vybere z ní nejlepší myšlenky a svůj návrh podle nich přepíše. Tohle kolečko se ještě dvakrát zopakuje a ve výsledku tu je specifikace, se kterou naprostá většina zúčastněných souhlasí a je s ní spokojená.

Existuje i další "standardizační" proces, kdy se výrobci jednoho prohlížeče pro něco rozhodnou, rychle to naimplementují a vydají. Druhý prohlížeč to naimplementuje taky (někdy trochu jinak, protože ten první prohlížeč k tomu nedal pořádnou specifikaci) a než se nadějeme, používáme to všichni. Je to sice plné problémů, je to návrh, za který se někde i vyhazuje od zkoušky, ale světe div se, vývojáři jsou rádi, že aspoň něco mají.

Tak a teď si vyberte!

Máme tu několik špatných cest. Jenže tu dobrou cestu nikdo nezná, a tak se vývoj webu často odehrávách na těch cestách, které jsou zrovna v tu chvíli z těch všech špatných ty nejméně špatné.

Vzpomeňte si na to, až zas někde uslyšíte, že Ian Hickson je diktátor, nebo že prohlížeč XY implementoval cosi svého. Netvrdím, že je to správné, ale někdy to může být to nejlepší řešení.

CSS exploit aneb proč na webu nemáme soukromí

Tvorba specifikací je odpovědná věc. Jednou vytvořené specifikace budou platit roky a s každou chybou, která se do nich dostane, se můžou potýkat celé generace.

Chyby se do specifikací skutečně dostávají a často jsou neškodné, že si jich všimnou jen vývojáři prohlížečů, ale běžný webdesigner si s nimi hlavu neláme.

Jen opravdu výjimečně se objeví chyba, která má dopad až na koncového uživatele. Toho, který sedí v teple u svého prohlížeče, pohodlně si kliká a o zkratkách CSS nebo HTML nemá ani potuchy.

Největší chyba webových specifikací

Mluvím teď o chybě všech chyb, o tzv. CSS exploitu. Popravdě si myslím, že se jedná o historicky největší chybu, která se kdy do webových specifikací dostala. A přitom základní myšlenka vypadá zcela nevině, citujme z původní specifikace CSS1, odstavec 2.1:

User agents commonly display newly visited anchors differently from older ones. In CSS1, this is handled through pseudo-classes on the 'A' element:

A:link { color: red } /* unvisited link */
A:visited { color: blue } /* visited links */

Myslíte, že zavedení pseudotříd link a visited nemůže mít pro uživatele neblahé následky? Pokud ano, tak se šeredně mýlíte. Stejně tak se zmýlili i tvůrci CSS1. I když těžko jim to mít za zlé, v letech 1994-1996, kdy kaskádové styly přicházely na svět, ještě Web nebyl plný bezpečnostních problémů, a jak by taky mohl být, když samotný JavaScript byl teprv v plenkách (objevil se koncem roku 1995).

Dnes mi o CSS exploitu vyšel článek, pokud jste o CSS exploitu dosud neslyšeli a pokud si myslíte, že na Webu existuje soukromí, doporučuji si ho přečíst:

Pokud si myslíte, že stránka, kterou právě čtete, o vás nemůže nic zjistit, tak se mýlíte. S jistou pravděpodobností by pomocí tzv. CSS exploitu dokázala odhadnout, jaké vyhledávače používáte, které e-shopy navštěvujete (včetně kategorií, které vás zajímají), zda používáte internetové bankovnictví nebo PayPal, jestli nenavštěvujete politicky nekorektní stránky a mnohem víc.

Více se dočtete v článku CSS exploit a neexistující soukromí na webu.

Chceme jednotné výchozí CSS pro všechny prohlížeče?

Včera se v HTML WG objevil zajímavý návrh. Justin James v e-mailu s předmětem Proposal: Default style definitions for elements navrhuje, aby se součástí HTML specifikace stalo i ustanovení výchozích kaskádových stylů pro všechny prohlížeče.

Myšlenka je to určitě zajímavá (snad každý webdesigner se minimálně jednou podivil, proč má každý prohlížeč výchozí styly jiné), otázkou je, zda by byla v dnešním spektru různých platforem a zařízení se svými zvyklostmi a omezeními rozumně realizovatelná.

Vývojář Gecka Boris Zbarsky ji odmítá, Anne van Kesteren tvrdí, že Ian Hickson má v úmyslu se tomu věnovat.

Jsem zvědav, jaké další názory se v diskusi ještě objeví. Pokud vás to zajímá, sledujte příslušné vlákno, přečtěte si i loňské vlákno na stejné téma a wiki stránku HTML Issue: Default Style Sheet, kde se mají sbírat náměty k řešení.

BTW jistý předpis již existuje jako součást CSS specifikace, ovšem nejedná se o žádné nařízení (prohlížeče se podle něj chovat nemusí a ani tak nečiní).

Vyhledávání podle CSS selectorů ve WebKitu

V posledních nočních buildech WebKitu (prohlížeč Safari) najdete nativní implementaci funkcí querySelector() a querySelectorAll().

Obě funkce jsou součástí specifikace Selectors API, o jejíž přípravě jsem se zmiňoval loni v létě, a umožňují snadné vyhledávání elementů pomocí syntaxe známé z CSS. Například document.querySelectorAll("#menu :visited"); vrátí všechny odkazy z menu, které již uživatel navštívíl.

Podobný přístup se dnes používá v řadě knihoven (jQuery, Prototype a další). Cílem specifikace Selectors API je používané přístupy sjednotit. Nativní implementace v prohlížečích bude navíc oproti javascriptovým knihovnám rychlejší, o čemž se můžete přesvědčit na testovací stránce. Na mém počítači běží nativní implementace (poslední sloupec tabulky) více jak o jeden řád rychleji, posuďte sami:

Webkit je první jádro, které zmíněné funkce implementovalo, proto zatím asi nikdo nebude obě volání používat přímo. Je více než pravděpodobné, že nové verze javascriptových knihoven budou rozpoznávat prohlížeče s nativní implementací a sami vyberou rychlejší variantu. Kód tak bude fungovat všude, ale v některých prohlížečích mnohem rychleji.

Budeme mít CSS5?

Ian Hickson ve svém červnovém příspevku The CSS working group is irrelevant kritizuje současný stav CSS a naznačuje možnosti vzniku CSS5 pod záštitou WHATWG.

The CSS specs show their age; they come from a time where specifications were much vaguer than those of the modern day. Someone really needs to do to CSS what the WHATWG has been doing to HTML, defining everything in detail, explicitly, with strict and clear normative conformance criteria, taking implementations into account, defining things like quirks mode. (The WHATWG community refers to such a hypothetical project as "CSS 5", as a reference to the way the current WHATWG specs define HTML5, XHTML5, and DOM5 HTML.)

One way to address this would be for the WHATWG to start a "subproject" to address CSS, while we wait for the W3C CSS group to learn from the W3C HTML group and become open. The biggest problem would be finding editors who would be willing and capable of doing the incredible work of rewriting CSS from scratch.

Situace okolo CSS dnes není zcela růžová. Pokusil jsem se jí popsat ve svém dnešním článku Quo vadis, CSS? na Lupě.

Obecné stylesheety pouze v hlavičce

Před měsícem jsem ve spotu Obecné stylesheety pouze v hlavičce? psal o debatě mezi Hyattem a Glazmanem na téma <style> pouze v hlavičce.

Nedávno byl výsledek zanesen do specifikace. V té v tuto chvíli o <style> stojí:

Contexts in which this element may be used:

If the scoped attribute is absent: in a head element.
If the scoped attribute is absent: in a noscript element that is a child of a head element.
If the scoped attribute is present: at the start of article, aside, div, and section elements.

Pokud dobře čtu DTD HTML4, tak samotné <style> bylo povoleno pouze v hlavičce dokumentu. Takže podstatnou změnou je pouze zavedení <style scoped>.

Pozorný čtenář si mohl všimnout další, byť nesouvisející změny a tou je povolení <noscript> v hlavičce dokumentu, které v HTML4 nebylo (HTML4 povolovala v hlavičce <script> ale již nikoliv <noscript>), více viz vlákno v mailinglistu. Kromě možnosti CSS aplikovaného pouze v případě vypnutého JavaScriptu se nabízí využití pro metarefresh, pokud je zapotřebí průběžně obnovovat stránku a oddělit JavaScriptové řešení (používající např. XHR) a klasický metarefresh.

Obecné stylesheety pouze v hlavičce?

David Hyatt v pátek napsal:

Unscoped <style> found outside the <head>

Please make this non-conforming. I don't think we should encourage this bad practice.

HTML5 v tuto chvíli podporuje vložení stylesheetu i na specifických místech dokumentu např. na začátku každého <divu> a Hyattovi se tento přístup nelíbí.

Zajímavá byla reakce předsedy Dana Connollyho:

I wonder who you are directing this request to. You're an editor. If you want the spec to change, please change it and let us know.

Kdo pečlivě sleduje všechny změny specifikace možná tuší, na co narážím (ne každá změna je vždy veřejně diskutována, v tak velikém počtu to někdy ani nejde, některé jsou prostě vloženy do specifikace a čeká se, jakou vyvolají reakci), ale o tom někdy příště.

Hyattovu návrhu oponoval Daniel Glazman:

I am not sure this is bad practice and I see this as a very interesting thing for wysiwyg copy/paste between two different document instances. Can you please detail why it is bad practice ?

Glazman je mimo jiné autorem editoru Nvu a není divu, že má trochu praktičtější pohled. V dnešním světě plném redakčních systému autoři obsahu ne vždy mají možnost zasahovat ho hlavičky a přidat vlastní styly někdy potřebují.

Hyatt nicméně svou připomínku rozvedl. Ve svém požadavku totiž nezakazoval vkládání všech stylesheetů, ale jen unscoped styleshteetů (obecných stylesheetů):

Scoped style is a new feature of HTML5.

http://www.whatwg.org/specs/web-apps/current-work/#the-style

I am proposing that be allowed anywhere, but that should only be conforming if used inside the head. I do not believe anyone has presented a valid use case for using unscoped outside of the , and given the performance impact it will have on the display of Web pages, the practice should be strongly discouraged.

I think "scoped" should be even more limited than it already is, and that the HTML5 spec should limit the scoping to nodes that follow the in a pre-order traversal of the tree.

Scoped (cílené) stylesheety se aplikují pouze element a potomky elementu, do kterého byl stylesheet vložen. Pokud bych například do článku tohoto příspěvku vložil cílený stylesheet, aplikoval by se pouze na tento článek (je celý ohraničen divem) a nikoliv na zbytek stránky. Což je ostatně přesně to, čeho bych jeho vložením chtěl docílit.

Debata ještě neskončila, pokud jí chcete sledovat, čtěte vlákno začínající Hyattovým příspěvkem.

Magické tělo

Tato článek se lehce odchyluje od tématu, týká se více CSS WG než HTML. Začátkem jara vznesl Simon Pieters z WHATWG připomínku v mailingu listu CSS WG:

Make XHTML <body> magic just like HTML <body>.

Having special rules for <body> in HTML but not in XHTML makes it harder for authors to switch to and from XHTML.

I think these are the special properties:

• 'background-color'
• 'background-image'
• 'overflow'

Pouze pro účely tohoto postu budu za XHTML považovat pouze XHTML s MIME 'application/xhtml+xml' (jen pro zjednodušení psaní, ostatně Simon to pravděpodobně tak myslí).

Jde o to, pokud v HTML nastavujete pozadí <body>, roztáhne se po celém oknu prohlížeče (byť <body> tak daleko nesahá = chová se magicky), pokud totéž uděláme v XHTML dokumentu, pozadí zaujme jen plochu, kterou <body> skutečně pokrývá (což je logické, ale zpětně nekompatibilní).

Po relativně dlouhé a zajimavé debatě (doporučuji k přečtení začínaje Simonovým mailem) zazněl kompromis od Berta Bose, předsedy CSS WG:

The WG still thinks the exception for HTML should not be carried over to other formats, but we've added some text to the status section of the document, under the heading "at risk":

The effect of 'overflow' and 'background' is different on BODY elements in HTML than on other elements. It may be that the exceptional handling of BODY in HTML is extended to BODY in XHTML1.

This means that we reserve the possibility of making BODY in XHTML1 an exception, just like BODY in HTML, if we consider that the state of implementations makes it necessary. We'll make that decision no sooner than six months after publication of the document as a Candidate Recommendation.

Simon založil bugy pro Gecko a Webkit (Safari), kde požaduje odpovídající změnu chování (v Opeře je <body> magické v XHTML již nyní). Nezbývá než čekat na výsledek.

Za specifikacemi stojí skuteční lidé a výměna názorů desítky lidí pak ovlivní generace webdesignerů. Ostatně to je jedním z témat celého tohoto blogu.

Jaké by mělo být tělo XHTML podle vás? Magické nebo logické?