Přejít k navigační liště

Zdroják » Zprávičky » Jak vyřešit nejčastější problémy s IE6

Jak vyřešit nejčastější problémy s IE6

Zprávičky Webdesign

Pokud musíte podporovat IE6 (a to pravděpodobně většinou musíte), pak vám článek 10 Fixes That Solve IE6 Problems shrne několik základních problémů, na které můžete s IE6 narazit, a jejich řešení. A pokud náhodou máte svůj vlastní seznam problémů, nezapomeňte se s ním pochlubit v komentářích.

Komentáře

Subscribe
Upozornit na
guest
20 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
ITGuru

Můj názor je shrnut v článku Je správné optimalizovat webové stránky pro IE6? na mém blogu a v komentáři. Myslím že podpora IE6 je v současnosti nesmysl. Zaměstnavatelé webdesingových firem a zákazníci by se měli nad problémem zamyslet a malinko u toho uvažovat.

Hoween

Že si to myslíte Vy je hezké, ale realita je úplně jiná. V současné době se IE6 pohybuje okolo 30-60% v závislosti na typu webu a žádný zadavatel dobrovolně nezahodí 1/3 zákazníků. Zvlášť když v řadě případů jsou kecy webdesignérů o problémech s optimalizací jen vyjádření jejich lenosti, že se jim to dělat nechce. Optimalizovat pro IE6 není až tak krvavé, ale holt se to musí umět a chce to zkušenosti. S trochou ohýbání není s XHTML 1.0 + CSS 2.1 v IE6 problém, tak proč s tím máte problém Vy?

Ano, také bych byl nejradši, kdybych IE6 nemusel řešit, ale řešit ho musím a minimálně ještě tento rok většina lidí bude. IE6 samo chcípne, jako chcíplo IE4, IE5, IE5.5, IE/Mac, nebo jeho existenci utnou velké portály (viz zpravodajské portály v Norsku)… Ale nechcípne díky podobným filozofickým názorům nezkušených webmasterů ;-) Na to jsou jejich webíky příliš malé a názor příliš bezvýznamný.

ITGuru

Netvrdím že je to velký problém, ale že by se to dělat nemělo. Do nedávna jsem upravoval weby pro IE6 a když bylo potřeba, tak bez hacků a podobných prasáren. Nemyslím že to je nějak extra složité. Stačí vědět co IE6 dělá špatně nebo nedělá vůbec. Ale jak já jsem nezkušený a Vy dokonalý profesionál myslím nemusíme řešit i když to tak třeba může být.

Podporou IE6 jeho životnost prodlužujeme. Vy IE6 nechcete (soudím podle "Ano, také bych byl nejradši, kdybych IE6 nemusel řešit" a podle toho že si neumím představit kodéra, který by chtěl udržet IE6 co nejdéle naživu), ale jeho životnost prodlužujete (nebo alespoň svým názorem) jenom aby Vám neutekly korunky. To je podle mě špatný přístup. Já pro IE6 prostě nedělám a když nějaký zákazník chce web pro IE6, musí si najít Vás aby ho měl. Vy na rozdíl ode mě vyděláte, ale já na rozdíl od Vás podpořím dobrou věc, za kterou mi poděkuje 100% kodérů. Prostě upřednostňuji logiku a rozum před penězi.

K té statistice zastoupení IE6: jistě, záleží na zaměření webu atp. Já myslím zastoupení v ČR a to průměrné. V poslední TZ serveru navrcholu.cz, kde se uvádí zastoupení IE6 23,20% je to k 31.10.2008. Ale popravdě já si myslím že nezáleží na zastoupení, ale na tom že se IE6 chová špatně, takže i kdyby byl podíl zastoupení 100%, tak by se podporovat neměl a to byste viděl jak rychle by se podíl změnil kdyby se všem všechny weby načetli rozhozené. A bylo by to špatně? Nebylo – prostě mají špatný prohlížeč a dobrý to zobrazí dobře. Mě to přijde tak jednoduché a logické, že ani nevím proč se to vůbec řeší.

Hoween

Aby mně neutekly korunky? :-D Optimalizaci pro IE6 si zvlášť opravdu neúčtuji, a navíc to pro mě není žádná podstatná položka. Takže to je pro mě práce jako každá jiná a na vývoj prostě padne pár hodin víc. Korunky utíkají zadavateli a ten si to pochopitelně nenechá líbit. Protože i kdyby ho vývoj měl stát o 5tis víc, a pak mu zákazník s IE6 udělá kšeft za 10tis, tak se mu to bohatě vrátí.

ITGuru

Nemyslel jsem korunky za verzi "s IE6" oproti "bez IE6", ale za "Mít zakázku" vs. "nemít zakázku". Tj. kdybyste vyřkl podmínku, že pro IE6 to nebude. Pak hrozí, že nebude ani zakázka. Já jsem pro "nebrat zakázky". Když to zákazníkovi nenakóduje nikdo, tak to bude bez IE6 a IE6 je zase o jeden hřebíček do rakve bohatší.

Hoween

Naštěstí jsem v situaci, kdy opravdu nemusím vzít každou zakázku. Ale když se rozhoduji, tak tam podmínka IE6 nehraje žádnou roli. Pro IE6 dělám aplikaci automaticky, není s tím žádný velký problém a IE6 odříznu ve chvíli, kdy jeho podíl klesne pod 5%. Ale ignorovat IE6 jen pro nějakou svou vlastní hrdost a vyšší princip, to je trochu zvláštní hrdost ;-)

ITGuru

Neignoruju IE6 pro hrdost, ale protože to je špatné. Proč nejdete dupnout nějaké kočce na hlavu? Já, protože to je špatné. IE6 je jednoznačně špatný prohlížeč – na tom se myslím shodneme. Pro mě to je prostě dostatečný důvod proč ho nepodporovat. Nepodporuji věci co se mi nelíbí, natož co jsou špatné.

Chamurappi

IE6 je jednoznačně špatný prohlížeč – na tom se myslím shodneme.
Můžeme se na tom shodnout při skupinové terapii rozhněvaných kodérů, ale neshodneme se na tom s normálními uživateli. Ti ho používali a stále používají. Stačí jim. Někdo jim možná brzy vnutí novější verzi nebo jiný prohlížeč, ale to nic nemění na tom, že jim Explorer 6 stačí. Můžeš jim vnucovat dojem, že nestačí a že si potřebují zobrazovat stránky napsané čistěji a na vyšší technické úrovni, ale prakticky vzato jsou jim tvé problémy dočista ukradené a tu jednoznačnou pravdu si neuvědomují.

Vnucovat návštěvníkům nějaké své vyšší dobro není špatné? Před šesti lety se říkávalo, že je.

McBig

"Optimalizovat pro IE6 není až tak krvavé, ale holt se to musí umět a chce to zkušenosti."

Co se zkušeností týče – ano, ty jsou vážně třeba, ale otázka krvavosti optimalizace je přímo úměrná složitosti webu a zadání. Sám pro IE (a velmi velmi nerad) optimalizuji a vedle nějakých webů, kde si jen hraji s umístěním či velikosti, člověk narazí na opravdu kravské chování, když chce něco víc, např. s javascriptem.

Článek sem jen zběžně prokouk, zde připisuji špeky na které sem přišel:
– rozdílnost chování u padding vs. margin jsou známé, ale při nějakém složitém menubaru s obrázky mohou pěkně štvát, vivat hacky | a _
– když je design tabulkový (grafici sou blázni) a člověk nemá jinou možnost něž stříhat, tak dokud IE nemá v buňce br tak dělá mezery pod obrázkem (ne jen nelogické ale kravské)
– při počítání pozice na strance opět jeden způsob pro IE a jeden pro zbytek :(
– zjišťování rozměrů stránky dtto
– onload u iframu (nevim proc) se volá 2x, a ještě divně
– pokusy javascriptem hejbat se styly (změna pravidel) o5 dvě verze (IE a neIE)
– ajax – zatím nepoužívám, ale dtto
– kdo si dělal wysiwyg editor a chtěl do něj dostat něco víc, ví o čem mluvím
– dynamická změna tabulek je také různochovající se
– a chybějící alfa průhlednost u PNG – na to už začínám kašlat, když to stačí, tak nepoužívám průhlednost ale někdy to třeba je… navíc občas musí člověk s obrázky dělat kouzla aby se to alespoň trochu vypadalo, ale to už si nechávám zaplatit.

A ano, vím o tom že některé problémy nejsou IE6-only. JS většinou cpu do knihovny, takže to člověk jednou udělá a má, navíc dělám weby tak, aby na JS nebyly závislé ale šlo jen o přidanou hodnotu, nicméně je to boj. Kdekoli se má objevit vyskakující menu a submenu atd… začínám prohledávat staré weby, abych zjistil jak sem to tam vlastně dělal že to fungovalo. To pak není jen o lenosti, je to o tom že IE (a opravdu není ani nááááhodou samo) občas umí pěkně házet klacky pod nohy, jen to dělá nejvíc a hlavně pak starší verze.

Hoween

rozdílnost chování u padding vs. margin jsou známé, ale při nějakém složitém menubaru s obrázky mohou pěkně štvát, vivat hacky | a _
EEhh? Striktní Doctype to řeší, podtržítkový hack je svinstvo – máme podmíněné komentáře.

když je design tabulkový (grafici sou blázni) a člověk nemá jinou možnost něž stříhat, tak dokud IE nemá v buňce br tak dělá mezery pod obrázkem (ne jen nelogické ale kravské)
Naučte se kódovat. Rozřezával jsem hodně velké šílenosti, nikdy jsem tabulkový design nepotřeboval, ani milion divů/spanů. Prostě to chce přemýšlet.

zjišťování rozměrů stránky dtto
Na čtyři řádky JS. Nějaký problém?

pokusy javascriptem hejbat se styly (změna pravidel) o5 dvě verze (IE a neIE)
Naučte se používat CSS, nebo příslušné JS frameworky. Běžně to používám, nikdy jsem s tím problém neměl.

kdo si dělal wysiwyg editor a chtěl do něj dostat něco víc, ví o čem mluvím
Ano. Každý PHP programátor si někdy napsal svůj framework, a kdo říká, že ne, píše ho dodnes. Proč si dělat vlastní editor, když jich je X přizpůsobitelných?

Tohle jsou opravdu věci o neznalosti a lenosti ;-)

McBig

"Striktní Doctype to řeší" – neřeší, podívejte se do definice, ve strictu toho občas spoustu nemůžete psát, stačí si pustit validaci….
Podmíněné komentáře ano, ale psát 2x nebo dokonce 3x ? na svinctvo se musí svinctvem

"Naučte se kódovat. Rozřezával jsem hodně velké šílenosti, nikdy jsem tabulkový design nepotřeboval, ani milion divů/spanů. Prostě to chce přemýšlet."
Opet lež, použít float a pozicování místo tabulky na tvorbu tabulky je zcestné a zcela nelogické. A pokud mluvím o tabulce, myslím tim tabulku, ne hlavičku, patičku a něco mezi co vypadá jako tabulka. Navíc díky tybulce ta stránka vypadá v IE všech verích, Opeře, Safari, FF všech verzí, mobilní opeře, webkitu, linksu a kdo ví v čem jiném.

"Na čtyři řádky JS. Nějaký problém?" Ano mám problém psát spusty věcí 2x pro IE a pro zbytek, kde to sme ?!

"Naučte se používat CSS, nebo příslušné JS frameworky. Běžně to používám, nikdy jsem s tím problém neměl." Ano .. a nebo si ten framework udělám sám, to jestli to udělám já nebo někdo jiný na věci nic nemění, pořád se to někdo musí hackovat, navíc některé frameworky vypadají sice mooc hezky, ale ta rychlost…

"Ano. Každý PHP programátor si někdy napsal svůj framework, a kdo říká, že ne, píše ho dodnes. Proč si dělat vlastní editor, když jich je X přizpůsobitelných?"

Zkoušel sem jich několi, ale líné editory které umí vše nechci, chci něco rychlého co umí základ. A opět, že se s tím pral někdo jiný neznamená že se s tím někdo nemusel prát.

Hoween

ve strictu toho občas spoustu nemůžete psát, stačí si pustit validaci….
Konkrétně? Ano, strict mi neumožní psát kód jako prase, to je jeho účel.

Opet lež, použít float a pozicování místo tabulky na tvorbu tabulky je zcestné a zcela nelogické.
Tohle nemá cenu. Zamrzl jste někdy před šesti lety. Jistě, tabulky se dělají tabulkami, ale tabulky jsou určené pro tabulková data, nikoli pro tvorbu layoutu. To je trend, jaký funguje už hezkých pár let.

Navíc díky tybulce ta stránka vypadá v IE všech verích, Opeře, Safari, FF všech verzí, mobilní opeře, webkitu, linksu a kdo ví v čem jiném.
Když vynechám links/lynx, i moje weby s beztabulkovými layouty vypadají všude stejně. V čem dělám chybu?

Ano mám problém psát spusty věcí 2x pro IE a pro zbytek, kde to sme ?!
Jaký zbytek? Podmínkou zjistím počáteční velikost stránky, dál mám jen jednu větev kódu, žádné dvě.

pořád se to někdo musí hackovat, navíc některé frameworky vypadají sice mooc hezky, ale ta rychlost…
jQuery 1.3 je první framework, ve kterém neprobíhá žádné větvení / hackování kódu. Jeho rychlost si můžete vyzkoušet. S packovaným Prototype dosahuji také velmi dobrých výsledků.

McBig

"Konkrétně? Ano, strict mi neumožní psát kód jako prase, to je jeho účel."
Ne strict definuje ze napr. label musíte něčím obalit než ho dáte do formu, že a musíte nečím obalit než ho dáte do body – když to někomu vyhovuje ok… nevidím na tom nic špatného, ale tvrdit že toto "neobalování" je prasárna je přehnané, jen to prostě není psané striktně.

Možná sem zamrzl, ale dělat tabulku pomocí něčeho jiného než tabulky je minimálně proti logice. To že je IN chodit s čepicí na křivo ještě neznamená že tak budu chodit. Spousta věcí je IN a moderních, ale to vůbec neznamená že jsou rozumné !

"Jaký zbytek?" – vyjmenoval sem hned několik různých odlišností od IE a FF více rozdílů najdete třeba zde: http://www.quirksmode.org, ano v praxi narazí člověk na méně rozdílů, než je zde popsáno. To ale neznamená že jich není dost a člověk jen netestuje co že je to za prohlížeč a jak dotyčnou vlastnost zjistit / změnit a to je o čem tu mluvím.

"i moje weby s beztabulkovými layouty vypadají všude stejně."
Tak to bych velice rád nějaké viděl, osobně sem totiž moc bezproblémových webů neviděl, a pokud vypadají všude stejně tak je to v kódu pořádnej bastl.

"jQuery 1.3 je první framework, ve kterém neprobíhá žádné větvení / hackování kódu."
Možná by ste se měl do toho kódu podívat, ono by stačilo si nechat vypsat jenom komentáře, plné IE :) Vedle toho že je úsměvné že ten soubor je z části s unixovýma koncema řádků a s části dosovýma (což browserům nevadí), tak ten kód je postavený na ifech (ano rozhodně ne na těch hackovacích). Nicméně pokud je to o tom, že si jendou za měsíc vymyslím nějakou funkcionalitu a tu (s obtížemi nebo bez nich) přidám do tak setinového souboru, myslím že s rychlostí mám pořád hodně navrch – což ocení zejména majitelé slabších strojů a netbooků.

Hoween

Možná sem zamrzl, ale dělat tabulku pomocí něčeho jiného než tabulky je minimálně proti logice.
Tabulky jsou určené na tabulková data. Layout nepředstavuje tabulková data a tudíž ho není nutné cpát do tabulek. Co na tom nechápete?

Tak to bych velice rád nějaké viděl, osobně sem totiž moc bezproblémových webů neviděl, a pokud vypadají všude stejně tak je to v kódu pořádnej bastl.
Že děláte bastly Vy a neumíte napsat normální kus kódu, tak to ještě neznamená, že to nejde. Staníček, Prokop, Kopta – kodéři par excellence, o nich taky tvrdíte, že se jejich weby špatně zobrazují a že je jejich kód bastl?

Možná by ste se měl do toho kódu podívat, ono by stačilo si nechat vypsat jenom komentáře, plné IE :) Vedle toho že je úsměvné že ten soubor je z části s unixovýma koncema řádků a s části dosovýma (což browserům nevadí), tak ten kód je postavený na ifech (ano rozhodně ne na těch hackovacích). Nicméně pokud je to o tom, že si jendou za měsíc vymyslím nějakou funkcionalitu a tu (s obtížemi nebo bez nich) přidám do tak setinového souboru, myslím že s rychlostí mám pořád hodně navrch – což ocení zejména majitelé slabších strojů a netbooků.
jQuery zkoumat nemusím, stejně ho používám packovaný. A že se smějete kódu, jehož autorem je v současnosti nejlepší JS programátor na světě? A ještě tvrdíte, že váš setinový kód je efektivnější a šetrný k netbookům? Když vezmu v úvahu, že bez frameworku do pár set znaků kódu žádnou pořádnou funkčnost nedostanete, tak na to konto vám už můžu vzkázat jen to, že jste naivní prosťáček. Dobře napsaný framework je podstatně efektivnější, než jakýkoli homemade kód. A věřím tomu, že Resig opravdu bastl kód nepíše ;-)

McBig

Tabulková data mohu napsat i bez tabulek, a stejně se k tomu právě ty tabulky hodí, rozdíl mezi daty a grafikou je jen v semantice – a tady mě nikdo nebrání nazvat tabulku layout. Až budou ve stylech (resp. v podporovaných stylech) tabulky, možná je pak nahradím, ale proč, když zase ostrouhají některé prohlížeče ? Ignorování tabulek je jen móda, nelogická, iracionální a navíc zbytečně náročná.

Pokud můj kód (aniž by ste ho viděl, nebo snad ano ?) považujete za bastl, pak si můžu myslet něco o zadní části těla, a já sem o nikom neřekl že je bastlíř – přečtete si ten komentář ještě jednou.

nikomu se nesměju – přišlo mě to prostě komické nic víc nic míň
A ano tvrdím že pokud je kód 100 menší a dělá JEN to co potřebuji, je efektivnější. Pokud to nechápete tak je mi Vás líto. (A znovu pro upřesnění, dělám stránky které na JS nejsou závislé, to znamená, že se dají téměř totožně používat bez JS, takže libovolný framework je už dopředu zbytečně velký a tedy zbytečně zatěžuje).

ITGuru

K těm tabulkám souhlasím s Howeenem. Jsem si jist, že jakýkoli grafický design lze udělat bez tabulek. Já jsem nikdy neudělal web v tabulkovém layoutu (dělám ale taky jen pár (5?) let). Toto striktně dodržuji. Naopak jak psal Hoween "máme podmíněné komentáře". Podmíněné komentáře považuji za hacky – akorát validní. Myslím že z pohledu logiky je to naprosto stejná prasárna jako jakékoli jiné hacky. Nikdy nepoužívám. Podmínkovat jestli je to takový nebo onaký browser je stejné jako psát nějak pro jeden a jinak pro druhý browser.

Hoween

Podmíněný komentář má ještě jednu podstatnou výhodu – hack pro příslušný prohlížeč mi nezasí*á čistý kód pro normální prohlížeče.

ITGuru

To ano, ale kód taky zasírá. OK beru že podmíněný komentář je lepší než hack, ale stejně jsem proti používání.

Chamurappi

ve strictu toho občas spoustu nemůžete psát
Můžeš psát cokoliv, <!doctype> tě v ničem neomezuje, jen specifikuje množinu elementů a atributů, při jejichž užívání bude stránka validní. Parseru prohlížeče je celkem jedno, co deklaruješ, odkazovaná DTD ho nezajímá.

Pojem „striktní Doctype“ se používá většinou jako přezdívka pro <!doctype> vyvolávající standardní režim. Ten můžeš mít, i když deklaruješ Transitional DTD, viz Pixyho tabulka.

mám problém psát spusty věcí 2x pro IE a pro zbytek, kde to sme ?!
Kde jsi ty? Už jsi někdy žil ve světě, kde stačilo napsat všechno jen jednou a všude to fungovalo? Práce kodéra odjakživa spočívala zejména v ladění odchylek prohlížečů. Myslíš si, že se to teď najednou změní, protože tržní podíl Exploreru 6 klesá?

McBig

"Můžeš psát cokoliv" – souhlas, i když tím parserem prohlížeče bych si nebyl 100%tně jistý, ale souhlas

"Pojem „striktní Doctype“ se používá většinou jako přezdívka pro <!doctype>" – ok, pak ano

"Už jsi někdy žil ve světě, kde stačilo napsat všechno jen jednou a všude to fungovalo?"
občas mám pocit že psát multiplatformě "těžkou" aplikaci je lehčí než multibrowserově lehkou aplikaci. Možná proto, že pokud nějaké standardy na systémové úrovni sou, tak si většinou dodržujou víc než u těch webových. I když uznávám, že i zde je diskutabilní co je a co není standardizováno atd…

"Myslíš si, že se to teď najednou změní, protože tržní podíl Exploreru 6 klesá?"
Nemyslím, doufám, resp. je to mé přání. Čím více se snaží MS nový IE protlačit mezi uživatele (i nelegálně užívaného systému), tím lépe pro kodéry.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.