Vlákno názorů k článku
Musí naše webové stránky vypadat zcela stejně ve všech prohlížečích?

Narozdíl od ostatních diskutujících si nemyslím, že článek je nošením dříví do lesa. Zdroják čtou i méně zkušení webdesigneři. Ti třeba o popisovaných postupech, které nám ostříleným přijdou známé, mnohdy netuší. Zkuste se vžit do doby, kdy jste sami začínali dělat první weby...

Zkrátka o postupech a technikách, které vedou k tvorbě lepších webů, má smysl psát pořád - a kdo to zná, nemusí přeci článek číst.

Jaké postupy tento článek popsal? To, že nemá smysl nutit se do pixel-perfect vzhledu? A ty tam opravdu někde vidíš popsaný nějaký postup, který "ostřílení znají a méně zkušení se naučí"? Já ne. Je to jen vágní blaf, vhodný někam na blog, který nic konkrétního neříká. Že se uživatelům kripl prohlížečů nemají nabízet "vyšší funkce" je jasné prakticky každému, kdo se někdy o něco takového v kripl prohlížeči pokusil.

Chtěl jsem článkem spíše upozornit na metodu Progressive Enhancement, která je zatím poměrně nevyužívaná (a to i na zahraničních webech). Pokud se něco používá, tak je to většinou Graceful Degradation, což je metoda filozofií někde zcela jinde (opravuje vzniklé chyby po nakódování webu). Progressive Enhancement je hodně o sémantice, vzhled je vlastně až druhotná záležitost a klidně se může i pozměnit layout. (Kupříkladu v nových prohlížečích by mohl být udělán pomocí display-table a v IE6,7 zjednodušen a vytvořen pomocí floatování).
Je mi líto, že jsem Vás pro metodu Progressive Enhancement zatím nezískal, možná když si přečtete článek na A List Apart, změníte názor. ;)

Nevím, jestli si ze mě děláte legraci, nebo jestli to myslíte vážně. Progressive Enhancement se nepoužívá v první řadě proto, že je zbytečně pracný a nutí kodéra naprosto zbytečně vyrábět několik CSS šablon. Metoda zpětného opravování je podstatně rychlejší a jednodušší na tvorbu a správu. Kodér, pokud není úplné hovado, zcela automaticky využívá standardů a metod současných prohlížečů, a pak jen opraví těch pár věcí, co má rozhozené v IE pomocí podmíněných komentářů. A v okamžiku, kdy IEx spadne pod Y procent, smaže příslušný komentář a zůstane mu o jeden css soubor méně. Progressive Enhancement vám nikdy nic takového neumožní, jednoduše proto, že ještě IE8 bude stále kripl, neschopný bezchybně zpracovávat CSS2 a CSS3.

Takže zatímco s poklesem IE6 pod 5% já smažu podmíněné komentáře a dál mé weby budou fungovat na jediné CSS šabloně, Vy, díky vašemu skvělému systému, budete stále udržovat 3-4 samostatné CSS šablony, které v podstatě dělají to samé. Jen u každého prohlížeče jinak. Je to Vaše volba, že si přiděláváte práci a pokud Vám ji zákazník zaplatí, je to jen Vaše plus. Ale když už o tom píšete, zkuste trošku praktického pohledu i z druhé strany.

Ale to přece nemusí být jen o víc CSS šablonách. Můžu použít vendor-prefixy (-moz-border-radius a další), text shadow a další. "Staré prohlížeče" mě v tuhle chvíli nezajímají - ty to zobrazí hranatě, bez rámečku apod. Je to v podstatě stejné jako Graceful Degradation, ale místo abych šel zpět, tak jdu dopředu. Když se border-radius dostane do specifikace a budou ho podporovat prohlížeče tak můžu stejně jako vy umazat vendor-prefix a nic jiného měnit nemusím.
Problém je, že zatímco na zpětnou kompatibilitu se myslí kvůli přístupnosti apod., tak progessive engancement vám nikdo nezaplatí a v komerčním projektu na to většinou ani není čas.

Vendor prefix v produkčním prostředí, které nejste schopný deterministicky předpokládat a budete se na jeho funkčnost spoléhat? Vy si opravdu musíte dělat legraci, nebo jste **** a *****. Vendor prefix může z prohlížeče kdykoli zmizet a výrobce Vás o tom nemusí informovat - tak je vendor prefix definovaný a nikdo soudný ho ve veřejném prostředí nepoužije.

Progressive enhancement Vám opravdu nikdo normální nezaplatí, protože je to nestandardní a zbytečné řešení. Pokud opravdu v praxi děláte to, že máte "divový" layout a v CSS jednotlivým divům nastavujete display-table... vlastnosti, tak to už rovnou můžete používat tabulkový layout. Na jedné straně tady říkáte něco o sémantice a přístupnosti, kam patří i známé "tabulky jsou určené na tabulková data a nikoli na layout", a v zápětí ten tabulkový layout vyprasíte v CSS. Takže na jednu stranu budete něco plkat o sémantice, na druhou budete dál používat tabulkový layout. Bravo, přepište dějiny webdesignu, toto je revoluční myšlenka.

Spíš vy nechápete smysl toho slova enhancement. Vendor-prefix použiju proto, protože v některých prohlížečích bude mít uživatel ze stránky lepší zážitek - bude to mít hezčí, jednodušší, rozšířené o něco navíc... Kdyby snad vendor-prefix zmizel, nebude mít uživatel na stránce stín, kulaté rohy, ale všechno mu bude fungovat dál (text uvidí, základní layout se mu nerozhodí atd.). Vy snad ve veřejném prostředí pro jistotu nepoužíváte ani javascript, protože může kdykoli zmizet (uživatel si ho vypne a je to!). Já myslím, že používáte, ale snažíte se to ošetřit, aby stránka byla použitelná i bez něj.
S tou tabulkou je to legrace. Asi byste radši neměl odkazům přiřazovat display:block, protože a-čko je přece řádkový prvek a vy ho předefinujete na blok. To je proti přírodě. Tabulky by se pro layout neměly nepoužívat, protože narušují tok dokumentu. Takže když si obsah hezky rozdělím do bloků, kterým pak nastavím display:table, mělo by to čtečce a dalším zařízením být jedno, kdežto když dám obsah do td-ček je to už o něčem jiném.

Můžete mi, prosím, vysvětlit, jak redefinice řádkového kupříkladu elementu na blokový (případně blokového na tabulkový ) naruší sémantiku a přístupnost HTML dokumentu?

Spíš mi vysvětlete, proč zde jsou uživatelé s nulovou aurou, kterým se příspěvky zobrazují a jiným ne. Holt si asi všichni nejsou rovni.

Ale k věci. Dokážete mi vysvětlit, proč se odborníci už několik let bijí za názor, že "tabulky nejsou určeny na tvorbu layoutu" a vzápětí ty samé tabulky vyrábíte přes CSS?

Registroval jsem se před hodinkou, což může být odpověď na vaši otázku, proč nedisponuji žádnou aurou a proč vám nejsem roven.

Tabulky nejsou určeny na tvorbu layoutu, na tom se asi shodneme všichni. Ovšem pokud se nemýlím, v tomto článku ani v komentářích se nebavíme o HTML a jeho sémantičnosti, ale o vizualizaci podávaného obsahu pomocí kaskádových stylů.

Protože jste mi ale neodpověděl na otázku, ptám se znovu a jednodušeji - použiji-li v CSS definici display:table (nebo display:table-cell) z důvodu požadavku klienta, aby jeho malý roztomilý webík byl ve viewportu vertikálně vycentrován, jakým způsobem tím naruším sémantičnost a přístupnost webové stránky, jak jste zmiňoval ve svém předchozím příspěvku?

Poprosil bych vás o konkrétní a faktickou odpověď namísto zcela zbytečných osobních výpadů. Děkuji.

Tím ho nenarušíte jinak, ale také máte možnost to vertikální zarovnání udělat jinak. Nemluvím tady o jedné vlastnosti jednomu prvku. Mluvil jsem o řešení, které předhazuje autor článku - že celý web na úrovni sémantického kódu bude "DIVový", ale vzápětí v prezentačním CSS převedu všechny "DIVy" do tabulky - table, table-row, table-cell. V takovém řešení nevidím žádný smysl, naopak vidím veškeré jeho nevýhody - k něčemu takovému těch "DIVů" budu potřebovat podstatně víc (a pak jde do háje sémantika), než když ten layout udělám pomocí floatování, nebo pozicování.

Odborníci se bijí za to, že se pro layout nemá používat table-tr-td. Nebijí se za to, že nesmím použít display:table apod. V kódu mi dál zůstává např. DIV, který nenese žádnou informaci o formátování. Když dám do kódu td a přitom to použiji jen na naformátování, tak je to špatně. Co je v CSSku je víceméně šumák, tím jen přizpůsobuji obsah, aby vypadal hezky.

Jenže abyste tabulku vytvořil jen pomocí divů, potřebujete těch divů mnohem víc, než když vytvoříte layout klasickými metodami. Navíc vás tabulkový layout (lhostejno jestli přes HTML tabulky, nebo CSS tabulky) stále stejně svazuje - nemůžete pouhou změnou CSS změnit pořadí sloupců, protože buňky jsou v řádku tabulky natvrdo vyskládané zleva doprava.

Nejsem si zcela jistý, jak mě svazují divy v kódu. Pokud se přeci později rozhodnu změnit display: table-cell; na něco jiného (kupříkladu celou definici smazat a napsat float:left;) tak v HTML nic neměním a zároveň mohu překopat vzhled celého webu.

Mimochodem specifikace říká, že divy s table-cell jsou téměř to jediné co potřebuji, vše ostatní mohu vynechat a prohlížeč si to odvodí. Ale to je již zcela mimo téma článku a nerad bych to dále rozebíral. Nebojte, připravuji právě o této metodě článek, takže v diskusi pod ním se poté můžeme o jejích kladech a záporech handrkovat.

Ale proč layout s display:table vytvářet, když ho IE stejně nezobrazí? Jen kvůli skvělému Progressive Enhancement, kvůli kterému podle vás musím ten samý layout vytvářet několikrát? Když ho můžu udělat jen jednou a fungovat mi to bude stejně? Já to opravdu nechápu. Jaký je praktický přínos Progressive Enhancement? Co s ním můžu udělat navíc, co s Graceful Degradation nemůžu?

1. Nakóduju dle nejlepšího vědomí a svědomí.
2. Graceful Degradation = směr zpátky - řešim funkčnost při omezené podpoře koncového zařízení (vypnutý JS, funkčnost bez obrázků, bez CSS)
3. Progressive Enhancement = směr dopředu - přidávám kravinky při rozšířených možnostech koncového zařízení (podpora kulatých rohů, stínování, javascriptí kravinky atd.)
Pořád pracuji s jedním layoutem, přípdně i s jedním CSSkem.

Ale já ty kravinky nepřidávám. Já je používám standardně, a pro kripl prohlížeče je vypínám.

Pak musím odpovědět vaší větou: Vy používáte standardně vlastnosti z CSS3? Vás vážně někdo jako kodéra zaměstnává?
Použití vlastností z CSS3 totiž třeba do progressive enhancement spadá...

Nepoužívám, protože CSS3 je draft a jeho implementace se tedy v jednotlivých vykreslovacích jádrech může kdykoli změnit. A já vážně nemám čas s každou novou verzí každého prohlížeče retestovat všechny své weby - což autor článku zřejmě má. Že použití CSS3 hlásá nějaký Progressive enhancement přístup, no tak ať hlásá. Má práce spočívá ve vytvoření dokonale stabilního a funkčního prostředí - a to mi Progressive enhancement nenabídne. Ve chvíli, kdy já budu díky skvělému Progressive enhancement mít jeden kompletní layout s CSS3 pro supr čupr prohlížeče, CSS2 layout pro IE7 a CSS2 s berličkami pro IE6, tak se dostávám do dost slušného svrabu. Ale hlavně že používám progresivní metodu, která mi umožňuje používat nehotový CSS3. Nu vot, eto technika.

To je stejný případ, jako když v případě WiFi se stále tam, kde na tom záleží, nenasazuje 802.11n - jednoduše proto, že je to stále draft, který nemá garantovanou kompatibilitu. Já si nasazení něčeho nestabilního a nehotového nemohu dovolit.

Aha, takže metoda č.1 kravinky zapíná pro supr prohlížeče a metoda č.2 kravinky vypíná pro kripl prohlížeče? Rozumím správně?

Ne. Graceful Degradation využívá současných kravinek dostupných všude a pár blbostí vypíná pro kripl prohlížeče. Progressive enhancement pro každý prohlížeč zapíná něco jiného.