Musí naše webové stránky vypadat zcela stejně ve všech prohlížečích?
Dlouhé hodiny trávíme laděním stránek pro starší prohlížeče. Výsledný kód je pak plný prezentačního HTML a CSS obsahuje spoustu různých hacků. Je to tak správně? Pokusím se vás přesvědčit, že ne a že to jde i jinak. Pozor, dnes píšeme SUBJEKTIVNĚ!
Dnešní článek patří do rubriky Subjektivně. Jejím cílem je poskytovat prostor pro názory a pohledy na aktuální dění v oblasti webových technologií i na jejich vývoj do budoucna. Jedná se o osobní názory, které se nemusí vždy shodovat s názory redakce. Pokud máte co říct, pojďte k nám psát Subjektivně.
Kodér vs. grafik a programátor
Když programátor napíše program, očekává, že program se bude vždy chovat přesně tak, jak jej napsal. Když grafik navrhne logo, zase všichni očekáváme, že logo bude vždy vypadat stejně. A když kodér nakóduje web, klient předpokládá, že jeho web bude za všech okolností vypadat tak, jak mu ho grafik vymyslel. Na první pohled to zní celkem logicky, na ten druhý si ale člověk uvědomí, že zatímco grafik i programátor vědí přesně, jak se výsledek jejich práce zpracuje a zobrazí uživateli, kodér hledá průnik zobrazovacích schopností prohlížečů.
Zmíněné předpoklady a chování vedou ke dvěma problémům:
- Rozvoj webových technologií může brzdit jeden zastaralý, hojně používaný, prohlížeč.
- Aby se webové technologie mohly pohnout kupředu, při určitém malém procentu uživatelů se v prohlížeči přestane testovat, prohlásí se za zastaralý a téměř nikdo se o něj již nezajímá.
Výsledkem je, že máme mnohem více práce, naše zdrojové kódy jsou samý <div>, samá třída a po nocích hledáme způsoby, jak obejít omezení staré technologie a vytvořit to, co si klient žádá.
Uživatelé starých prohlížečů pak nemají důvod přecházet na novou verzi prohlížeče, vždyť všechny webové stránky se jim zobrazují tak, jak mají. A protože tito uživatelé nepřešli, my musíme stránky pořád kódovat tak, aby bezchybně fungovaly i v těchto starých prohlížečích. Bludný kruh.
Až odejde IE6…
Již nějaký čas je jedním z největších snů webdesignérů to, aby IE6 odešlo na věčnost. Neznalí poměrů v oboru prohlížečů se pak před vydáním nové verze IE ozývají, že to bude poslední hřebíček do rakve IE6. Ti zkušenější spíše skepticky vrtí hlavou a na brzký odchod IE6 nevěří.
Ale připusťme si na chvilku fakt, že by skutečně IE8 srazilo podíl IE6 řekněme pod 5 %. Co se pak stane? Kapitán Pejsek vyhlásí tento den jako svátek všech webdesignérů a přestaneme tento neoblíbený prohlížeč všichni hromadně podporovat? Jenže tím ztratíme zhruba 5 potenciálních zákazníků z každé stovky. A důvod jejich ztráty, naše pohodlnost, se mi zdá jako zcela nedostačující.
Jako bych některé z vás slyšel křičet: Nejdřív tvrdíš, že IE6 de facto brzdí vývoj, a teď zase, že jej máme podporovat, i když jeho podíl spadne na mizivá procenta. Tak co s tím?
Chtěl bych vám teď představit způsob, jakým podporovat nejen IE6, ale i jeho předchůdce a spoustu dalších prohlížečů a ještě si ušetřit práci a čas. Onen způsob se jmenuje:
Progressive Enhancement
Tento anglický termín představuje speciální přístup ke kódování webových stránek (do češtiny bychom jej mohli přeložit jako postupné vylepšování). V zásadě se jedná o to, že výsledné stránky budou v prohlížečích s dobrou podporou standardů vypadat tak, jak je grafik navrhl a budou si moci dovolit využít spoustu úžasných věcí z nových specifikací CSS či HTML. Ve starších prohlížečích pak budou vypadat o něco jednodušeji a řekněme hůře, ale budou stále dobře použitelné, přístupné a nijak nebudou odrazovat návštěvníka rozpadlým layoutem nebo něčím podobným.
Progressive Enhancement.
Jak na to? Postupně (viz obrázek s vrstvami). Nejprve se soustředíme na sémantické označkování obsahu a poté začneme postupně pomocí CSS tvořit layout a grafiku. Napřed nastavíme věci, které budou fungovat ve všech prohlížečích, a poté postupně vylepšujeme grafiku s tím, že pokud je určitá věc příliš složitá na implementaci ve starších prohlížečích, nebo vyžaduje kupříkladu čistě prezentační HTML, tak ji prostě implementujeme pouze v novějších prohlížečích, kde to lze udělat bez problémů. Odříznout starší prohlížeče od příslušných pravidel jistě všichni umíme, ať už pomocí pokročilých CSS selektorů (kterým staré prohlížeče nerozumí), nebo, v případě IE, pomocí podmíněných komentářů.
Wikipedie říká:Progressive enhancement je webdesignerská strategie zdůrazňující přístupnost, sémantické značkování a externí linkování stylopisů a skriptovacích technologií. Progressive enhancement využívá webových technologií metodou vrstev, což dovoluje komukoliv přistupovat k základnímu obsahu a funkcionalitě stránky, ať používá jakýkoliv prohlížeč nebo internetové připojení. Uživatelům s lepším připojením a modernějšími prohlížeči zároveň nabízí podobu stránky s lepším uživatelským zážitkem.
Pro bližší seznámení se s touto metodou včetně konkrétních rad doporučuji skvělý článek Progressive Enhancement with CSS na magazínu A List Apart. Poprvé byl termín progressive enhancement použit v roce 2003.
Všimněte si, že tento přístup vyřeší skoro všechny naše dříve zmíněné problémy. Můžeme používat moderní technologie a umožníme přístup na naše stránky v podstatě všem uživatelům. Paráda, ne? A pokud navíc chytře používáme pokročilé selektory, mohou nás částečně přestat trápit i rostoucí procenta uživatelů přicházejících na web z mobilu, kde je chaos v prohlížečích ještě větší a možnosti testování naopak menší.
Není to moc práce?
Na první pohled to tak určitě vypadá. Přístup vyžaduje poměrně detailní znalost schopností i starších prohlížečů (což lze obejít googlováním) a člověk musí nad kódováním najednou mnohem více přemýšlet.
Na druhý pohled si ovšem určitě uvědomíte, že přístup nám umožňuje škrtnout si nekonečné hodiny ladění pro IE6 a můžeme použít spoustu nových užitečných věcí z CSS 2.1 a občas i CSS3. (To ovšem záleží na cílové skupině webu. U některých webů zkrátka není dobrý nápad, aby se web nezobrazoval „v plné parádě“ ani uživatelům nejnovějšího přírůstku rodiny IE. U jiných webů to naopak nemusí být žádný problém.).
A někteří z vás možná volají: Vždyť to v IE6 stejně musí fungovat, tak jaképak škrtnutí nekonečných hodin ladění.
. Zde mohu argumentovat pouze osobními zkušenostmi. Zprovoznit v IE6 základní layout není žádný problém, stačí si pamatovat pár věcí, které nikdy nesmím použít. Problém s IE6 nastává ve chvíli, kdy po něm chci něco nestandardního.
Příkladů je spousta, určitě si hned vzpomenete na poslední výmysl grafika, kam zakomponoval tunu kulatých rohů, průhledné PNG, spoustu přesného absolutního pozicování atd. Ano, všechno to jde udělat, něco snadněji, něco hůře. Otázka, na kterou si musíme odpovědět, je, zda se vynaložený čas na implementaci takového grafického prvku v IE6 (nebo kterémkoli jiném prohlížeči) vyplatí. Zastánci progressive enhancement tvrdí, že ne.
Klient na to nikdy nepřistoupí
Jeden z nejtěžších úkolů bude každopádně přesvědčit klienta, že je to ta správná věc pro jeho webové stránky. Argumentů můžete použít spoustu. Od zkrácení doby vývoje webu přes nižší výdaje za (kvalitní) kód, atd. Těžký kalibr pak může být to, že tuto techniku sami používáte na svých webových stránkách. Vždyť často si vás klient zvolí právě díky nim. Nabízí se mu pak otázka, že pokud si sám vybral firmu, která své stránky takto vybudované má, nebude to dost dobré i pro něj?
Ale protože člověk je sám sobě často nejhorším klientem a nechce sám ze sebe dělat pokusného králíka (výjimky jako já potvrzují pravidlo a jistě odpustí), ještě jednou vás odkáži na již zmíněný článek na A List Apart, který uvádí i příklady již funkčních webových stránek užívajících progressive enhancement.
Závěrem
Pokud jste se dočetli až sem, asi si uvědomujete, že se jedná o běh na dlouhou trať. Musí se změnit to, jak lidé přemýšlí o webových stránkách. Ale do budoucna to vypadá jako téměř jediná technika, která zajistí rychlý rozvoj webových technologií a zároveň umožní všem lidem pohodlný přístup na váš web.
Takže až budete redesignovat váš firemní web, zkuste se zamyslet nad tím, zda se chcete nadále nechat omezovat minulostí, nebo se chcete raději podívat do budoucnosti.
Honza Sládek
Návrhář uživatelských zážitků. Spoluzaložil Clevis s.r.o., školí responsive a mobile webdesign, organizuje konferenci Webovina a soutěž pro mladé Junior Internet.
To je invalidni clanek, ktery si plete jabka a hrusky, tedy vzhleda chovani. Ja jako programator neocekavam, ze muj program bude vypadat vsude stejne a jako koder ocekavam, ze se bude chovat vsude stejne a vyuzije ty sluzby, ktee mu prostredi nabidne.
Je velice dulezite, aby webova prezentace vypada ve vsech prohlizecich stejne, alespon velice podobne (nebavime se o pixel-perfect vzhledu). Pokud jsem castym navstevnikem nejake web. prezentace, ziskam o techto strankach nejaky mentalni model, napr. nahore je zakladni navigace, v pravo je dalsi navigace, vlevo nahore je LOGO a dole je paticka. Na toto usporadani si uzivatel zvykne a pokud je toto v kazdem prohlizeci jinak, pryc z tohoto webu, uzivateli pripadne zmateny. Proto je dulezite, aby web. vypadal ve vsech moznych prohlizecich stejne.
Přečetl jste si článek a víte, o co ve webdesignu v tomto případě jde? Nikdo tady napíše, že v prohlížeči A bude layout 1 a v prohlížeči B ten samý web v layoutu 2. Web si má zachovávat základní funkčnost, to znamená ve všech prohlížečích bude ten samý layout. Jenom holt pro zkriplence typu IE6 bude ořezaný a nikdo se v něm nebude honit za dokonalou kopií grafického návrhu.
To by vsechny weby musely vypadat jako v lynxu na mobilu, abys tohodle naprosto a zcela pitomeho pozadavku dosahl :-).
to je blbost, uživatelé většinou používají jen jeden prohlížeč, nechodí na web v sobotu s IE, v neděli s Firefoxem, v pondělí s Operou a v úterý se Safari a zejména většinu problémů představuje ie6 a jeho uživatelé většinou neví, že nějaké jiné prohlížeče existují
V první části článku jsme se dozvěděli, že nemá smysl snažit se o pixel-perfect vzhled, prostě proto, že IE6, IE7 nebo Opera si vždy něco vyloží po svém. Což každý normální kodér už dávno ví.
Ve druhé části jsme se dozvěděli, že uživatelům zkriplených prohlížečů se má nabídnout pouze základní funkčnost, uživatelé moderních prohlížečů mohou využít web "na plno". Jistě, uživatelům IE6 se prostě nenabídnou kulaté rohy, dokonalá průhlednost a vypne se polovina JS funkcí. Web stále funguje a kodér si nemusí trhat vlasy jakým hackem to PNG do IE6 dostat.
Zákazník na to celé přistoupí poměrně ochotně – většina z nich už dávno aspoň na IE7 funguje, takže si svůj budoucí web prohlíží v něm a IE6 verzi si může kodér udělat podle sebe, aniž by ho zákazník jebal, že něco nevypadá dokonale.
Tohle všechno dělá dobrý kodér automaticky už rok, dva. Takže byť subjektivní, přesto zbytečně amatérský a out-of-date článek.
Taky mi ten "kuuul" anglicky termin pripadl po precteni definice jako nalepka pro neco, co stejne uz vsichni vicemene pouzivaji…
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.
Gmail je IMHO určitým příkladem. Sice možná nejde o funkčnost (nebo jo? Nevím.), ale o rychlost. Poznámka typu "get faster gmail" je taky dobré řešení.
Poznámka "klient na to nepřistoupí" je úplně mimo. Klient má IE7 a nic jiného ho nezajímá. Báchorky o dalších prohlížečích bere s rezervou. Stačí že to chodí jemu, víc nepotřebuje.
To není tak úplně pravda. Klient má většinou povědomí o ostatních prohlížečích, ale dost slyší na dvě věci: 1) statistika, 2) peníze. Na základě bodu 1 akceptuje třeba i ten Firefox (dost často vyžaduje, aby to chodilo ve víc prohlížečích, zvlášť když na aktuálních stránkách má 20% neIE prohlížečů). A bodem 2 se dá argumentovat u IE6, pokud vyžaduje dokonalou funkčnost v IE6, pak mu profík prostě vysvětlí, že ho to bude stát 2x tolik. Když si to zákazník vysvětlit nenechá, klidně tu zakázku pustím. Já mám nabídek na práci dost a nebudu si kazit život striktní optimalizací pro IE6, když mám také zákazníky, kteří ji nevyžadují.
Klient ale urcite ma zakaznika, s velkou pravdepodobnosti zrovna toho nejdulezitejsiho, kterej pouziva IE6 a pokud se na webu neco rozpadne, tak se o tom klientovi urcite nezapomene zminit. A klient pak bude vysilovat, ze jeho nejdulezitejsimu zakaznikovi se zobrazil rozpadnej web. Nastesti, pokud ma jen IE6, tak nemuze srovnavat a klidne se mu tam muze zobrazit omezenej web, pouze nesmi vypadat na prvni pohled rozpadle. :)
Urcite s tebou nesuhlasim. Teraz idem prerabat web a co ma prekvapilo najviac je to ze samotny klient dosiel s tym aby mu to fungovalo vo vacsine prehliadacov.
Dobrý postup, líbí se mi. Jako vedlejší efekt by mohlo být příjemné "tyjo Franto ty máš ten web nějakej hezčí, co to máš za prohlížeč?" ;-)
Jenže tento "efekt" umožňuje i klasické metoda zpětného opravování chyb ;-)
Aha, takže mám dokonce (minimálně) dva postupy na výběr, to je dobře.
Existuje ještě třetí možnost, kterou čím dále více potkávám na stránkách zahraničních webdesignerů – IE 6 prostě pomocí podmíněného komentáře odstřihnou úplně a nešťastnému uživateli se zobrazí jedna stránka, která mu tu více, tu méně ohleduplně sdělí, že je páprda, který nefandí novým technologím a tím pádem nemá na webu autora co pohledávat. Baj baj, dinousare.
Ostatně, čas od času na takové weby natrefím i u nás, ale protože se povětšinou jedná o osobní blogy, přejdu to mávnutím ruky s tím, že majitel webu zřejmě o mou návštěvu nestojí, což je v pořádku. Do obýváku si také nezvu každého.
Hm, to se mi nestává a ani to nepovažuju za řešení. Zobrazit funkční web bez nadstandardu a zobrazit hlášku "my víme co máš používat" se mi zdá jako k "nám do obýváku ani nepáchneš" a "na naší televizi toho moc bez brýlí neuvidíš".
Díky za otevření tématu Progressive Enhancement. Jeho myšlenka je určitě správná a hlavně v budoucnu se bude všem kódérům hodit.
Myslím si ale, že jste na IE6 zbytečně příkrý. Když jej srovnám s historicky snad nejvíce nenáviděným prohlížečem (Netscape 4.7x), je IE6 docela dobrý produkt.
Pracujeme teď na redesignu poměrně navštěvovaného webu se čtvrtinovým procentuálním zastoupením IE6 mezi uživateli. To že bychom "neřešili" IE6 si neumí představit nejen klient, ale ani já.
Nemluvím teď o pokročilém chování řízeném javascriptem (ale i tady se s pomocí frameworků dá najít myslím docela rozumná cesta – třeba jQuery IE6 plně podporuje). Co se vzhledu týká, nemyslím si, že v případě IE6 musíte dnes dělat příliš velké ústupky.
IE6 se sice chová mírně jinak, ale hasLayout se dá naučit, průhledná PNG a box-model se dají obejít a ty ostatní chyby jsou velmi dobře zdokumentované. Stačí jen chtít se je naučit — a myslím si, že je to úplně stejné, jako se naučit pokročilé vlastnosti jiného prohlížeče se čtvrtinovým zastoupením. Nedělejme z něj voodoo panenku.
Jenže na rozdíl od NN 4.7, IE6 se stále používá, zatímco NN 4.7 dávno zemřel. A až zemře IE6, řadě webmasterů se oddechne.
Pokud jde o box-model, nikdy jsem problém s box-modelem v IE6 neřešil. Stačí používat standardní vykreslovací režim. Co se týká ostatních chyb, stačí se je naučit a při vytváření layoutu s nimi počítat.
Díky za pozitivní komentář.
Souhlasím, IE6 není špatný prohlížeč. Akorát je starý a proto neobsahuje části novějších specifikací. Používal jsem jej jako příklad, protože mi přišel jako nejrozšířenější zástupce prohlížečů, kvůli kterým tu a tam prostě musíme použít trošku toho prezentačního html, abychom dostali požadovaný grafický efekt. Což IMHO není zcela ideální. Ale zcela jej neřešit jde proti všem myšlenkám jak přístupného webu, tak i Progressive Enhancement a doufám, že si právě toto čtenář z článku neodnese.
IE6 není špatný prohlížeč… Jen to HTML, CSS, JavaScript a PNG mu moc nejdou. Tedy mu v podstatě nejde nic, z čeho je web dělaný… Vás vážně někdo jako kodéra zaměstnává?
Kodér hodný svého jména nemá většinou s IE 6 žádné problémy, především proto, že jeho chyby, chování i omezení jsou tak dobře zdokumentovány, že kupříkladu řešení problému s PNG je vzdáleno pouhé jedno kliknutí myši od této diskuse.
Dnes dostupné frameworky (Mootools, jQuery a podobně) dokazují, že ani použití moderních javascriptových fičůrek není v IE 6 neřešitelné.
O problémech jmenovaného prohlížeče s HTML jsem ovšem nikdy neslyšel, mohl byste mě, prosím, vzdělat?
Jistě, frameworky umožňují používat JS na prakticky stejné úrovni ve všech prohlížečích. Jde o to jak rychle pak výsledná aplikace funguje a jaký je tedy uživatelův dojem. Gmail jistě znáte, zkuste ho používat v IE6 a pak třeba ve Firefoxu 3.1, nebo Google Chrome.
Problémy s HTML má IE6 v případě tagů abbr a acronym. Nad tagy col a colgroup má chybnou implementaci colspanu a šířky. A narazil jsem i na problém s tagem caption, ale za to ruku do ohně nedám, v tuto chvíli nemám čas hledat příslušný testcase.
Mohl byste me nasmerovat? Nasel jsem 2 vyuzitelne reseni problemu pruhlednosti PNG v IE6. Jedno nechava podivne okraje a druhe je tak pomale, ze se hodi jen na X obrazku na strance a navic to stejne problikne.
Mrkněte ke Kahimu -> http://kahi.cz/blog/o-konecnem-reseni-png-v-ie6
nezvládne zobrazit dvě stránky najednou :)
>> musíme použít trošku toho prezentačního html, abychom dostali požadovaný grafický efekt.
Honzo, co konkrétně myslíte tím "prezentačním html"? Nechci vás chytat za slovíčka, toho si v diskuzi ostatně užijete dost :), ale pokud máte na mysli definici vzhledu v HTML, pak marně dumám, kdy jsem ji kvůli IE6 musel použít.
Prezentačním html mám na mysli "zbytečné" divy, spany a classy v html kódu. Tedy věci, které by buď nebyly vůbec nutné (taková matrjoška je dobrý příklad) a nebo by šly obejít pomocí pokročilejších CSS selektorů.
A příště klidně tykejte.
Matrjoška? K čemu?
Zbytečné divy.. Tady se asi neshodneme. Co se týká samotného HTML zastávám docela pragmatický postoj.
Užitečnost prvku nebo třídy navíc kvůli IE6 vnímám stejně jako třeba užitečnost prvku nebo třídy navíc kvůli mikroformátům. Nevadí mi kód navíc, když to pomůže uživateli a kód zůstane dobře spravovatelný.
Osobně vnímám rozdíl mezi tím, zda je tam div navíc kvůli mikroformátům (a tím pádem přidává sémantickou informaci dokumentu) a nebo zda je tam proto, že starý prohlížeč jinak nedonutím ke spolupráci. Druhý zmíněný případ se mi zkrátka příliš nezamlouvá (a IMO tím vlastně nadržujeme jedné skupině uživatelů. Ostatním tento zbytečný tag přeci nepomůže). To, že v praxi se to běžně užívá, je samozřejmě jiná věc. Ale je to tak správně?
Pro mě je správně to co je správné pro uživatele. Uživatel s IE6 je dnes pro mě v případě html kódu stejně důležitý jako uživatel se zařízením, které rozumí mikroformátům.
Nerozumím v téhle souvislosti pojmu "zbytečný tag" – buď někomu pomůže a tudíž do HTML patří nebo nikomu nepomůže a nepatří tam.
Kdybyste to nenapsal Vy, musel bych to napsat já :-) :-p
Problém s "progressive enhancement" vidím jeden – když použiju např. zaoblené rožky, stín textu apod. s tím, že v IE holt bude stránka o tyto efektíky ochuzená, dříve či později mi klient pošle stížnost, že je v IE chyba – rožky se nezaoblují a stíny se nevrhají. Myslíte, že běžný klient si pamatuje, jak jsem mu někdy před dvěma měsíci vysvětloval, že je to tak schválně? Z tohoto důvodu to raději nepoužívám, aby se mi to jako bumerang nevrátilo zpět.
Kdo je ten nervósní pán s exkrementem ve jméně a s kriplem v každé větě?
Na rozdíl od vás se nesnižuji k argumentaci na úrovni ubohého komolení cizího nicku.
Popravdě řečeno, je to sice trošku ot, ale stejně by mě původ toho nicku zajímal. Nic jiného než exkrement v tom najít neumím. A to jsem se snažil a UTFSE.
Na toto téma bylo řečeno a napsáno naprosto vše už před 5 lety. Ale ať si to klidně mladší zopakují…
Jen mě napadlo, proč nepoužívat identifikaci prohlížeče pomocí User Agent stringu a podle toho uživateli poskytnout odlišnou verzi stránky? Vždyť User Agent byl původně vymyšlen k tomu aby server poznal jestli uživatel používá Mosaic nebo Mozillu, a tak mu poskytnout stránky s/bez rámů (frames).
Protože může mít uživatel nastavený jiný user-agent string, než je jeho prohlížeč?
Protože může být za proxy, která to odstraňuje?
Protože se prostě dá udělat layout tak, aby fungoval ve všech mainstreamových prohlížečí bez této obskurnosti?
Tohle je amatérský nesmysl, který se dávno nepoužívá ;-)
Pokud odstraníte UA string, tak se nedostanete ani na tenhle web – http://www.ceskatelevize.cz A takových webů určitě bude víc.
Vámi uvedený amatérský nesmysl používá třebas Chamurappi na http://www.webylon.info
Jde to hackovat v CSS;-) http://teststranek.kvalitne.cz/css-rozlisovac/
Ano, taky Chamurappiho považuji jen za křiklouna, jehož snaha bojovat proti standardizaci je celkem zoufalá a úsměvná.
Hackování CSS založené na vendor-specific vlastnostech… Zajímavé, ale nějak mi uniká smysl všech podobných obskurních hacků, když není problém udělat layout čistě.