Scukařina, žádná dřina – díl čtvrtý: jiná práce s CSS
V posledním díle našeho Scuk seriálu se od Djanga přesuneme blíž k prohlížeči — do CSS kódu. Ale kódu moc nečekejte. Pokusím se vám na technickém řešení jednoduché části uživatelského rozhraní ukázat dva principy vztahující se ke kodérské práci, které jsem na Scuku aplikoval nebo díky ní získal.
Seriál: Scukařina, žádná dřina (5 dílů)
- Scukařina, žádná dřina – díl první: agilně! 18. 8. 2010
- Scukařina, žádná dřina – díl druhý: Django je naše máma 25. 8. 2010
- Scukařina, žádná dřina – díl třetí: Djangová je náš táta 1. 9. 2010
- Scukařina, žádná dřina – díl čtvrtý: jiná práce s CSS 8. 9. 2010
- Scukařina, žádná dřina – appendix 15. 9. 2010
Rozhodnutí přijímaná až na úrovni konkrétních prvků webu
Rozhodujete se o podpoře konkrétních prohlížečů, technologií a způsobech řešení na úrovni celého projektu, nebo jste dokonce ta rozhodnutí jednou přijali pro všechny projekty, na kterých děláte, a ze zásady je neměníte? Ukážeme si, že pro uživatele je výhodnější, když se rozhodujete o několik úrovní níže — před implementací konkrétního prvku webu nebo aplikace.
Podívejte se na Scuk v IE6, v IE8 a pak třeba ve Firefoxu. Vypadá stejně? Jen zdánlivě. Pečlivý pozorovatel by našel řadu drobných rozdílů, které mají společný důvod — chceme, aby každá skupina návštěvníků dostala své velikosti přiměřenou, ale hlavně co největší porci radosti z používání.
Víte, že celkový uživatelský prožitek tvoří mnoho elementů — vzhled stránky, rychlost jejího načítání, způsob interakce, navigace, design, architektura informací, celkový vizuální styl a další. Pokud například vzhled dostane přednost proto, abychom zachovali jednotnost napříč prohlížeči, může to být na úkor rychlosti nebo nakonec efektivitě kodérovy vynaložené energie.
Vezměme triviální, ale všem blízký příklad — kulaté rohy. Zcela pochopitelně oblíbený prvek grafiků. Kdysi ruční kodérova práce. Dnes jí docílíme lusknutím prstů pomocí CSS3 konstrukce:
-moz-border-radius: 10px; border-radius: 10px;
Nebýt vendor prefixu pro Firefox, vypadá docela jednoduše, že ano? Jenže — i tak by svět byl příliš dokonalé místo. Vlastnost border-radius bude Internet Explorer podporovat až v připravované verzi 9.
Co s tím? Někoho napadne border-radius vůbec nepoužívat („Nemůžu ho použít všude. Je to hudba budoucnosti.”), jiného vykašlat se na Internet Explorer („Vždyť to není problém můj, ale Microsoftu a jeho bláznivých fanoušků.”), třetí bude hledat javascriptové řešení, které v prohlížečích nepodporujících border-radius kulaté rohy vykreslí (a najde CurvyCorners).
Rovnou tři možná řešení. Hurá? Řeknu vám, proč jsme se nerozhodli pro žádné z nich.
V moderních prohlížečích využíváme border-radius. Prostě proto, že nechceme hledat způsoby, jak si zkomplikovat práci. Prohlížeče velké části návštěvníků tedy hezky a hlavně rychle kulaté rohy vykreslí.
Víme, že javascriptové řešení typu CurvyCorners může na menším projektu usnadnit spousty práce, pokud je nasazeno univerzálně na celém webu. Jenže Scuk je aplikace velmi hojně javascript využívající a náročná na výkon. A my prostě kvůli kulatým rohům nechceme prohlížeč uživatele zatěžovat další vrstvou výpočtů v javascriptu.
Co tedy dál, když Internet Explorer ignorovat nehodláme? Jsem toho přesvědčení, že tak jako nelze webdesignérské postupy aplikovat jednotně napříč všemi typy webů, nelze je aplikovat ani napříč stránkami jednoho webu. O přítomnosti kulatých rohů se tedy rozmýšlíme nikoliv v rámci celého webu, ale jeho jednotlivých prvků.
Podívejte se na hlavičku Scuku:
Nepletete se, vypadá v obou prohlížečích stejně. Je to místo, kam zamíří oči návštěvníka nejdříve. Tady je důležité předat „zakulacený” vizuální styl Scuku všem bez rozdílu.
Border-radius už umíme, a tak v prohlížečích, které si s ním vědí rady, bude CSS kód položky navigace vypadat poměrně elegantně:
nav#categories li a {
display: inline-block;
padding: 10px 6px;
-moz-border-radius: 7px 7px 0 0;
border-radius: 7px 7px 0 0;
}
V prohlížečích, které border-radius nezvládají (jako Internet Explorer), pak namísto nastylovaných odkazů použijeme obrázek na pozadí:
.no-borderradius nav#categories .cat-vse a {
background-image: url(../img/layout/nav-cat-vse.gif);
width: 46px;
}
Všimněte si třídy .no-borderradius. Tu nám k <html> elementu dokumentu přidala užitečná knihovna Modernizr. Díky ní můžeme v CSS kódu detekovat přítomnost nebo nepřítomnost většiny vlastností HTML5 a CSS3.
Vaše otázka by mohla znít: Proč si tedy neusnadníme práci a nezvolíme jedno řešení a nepošleme obrázky i prohlížečům, které border-radius zvládají? Pro odpověď se vrátíme na začátek článku: Protože se snažíme maximalizovat uživatelský prožitek. Proč bychom měli zpomalovat načítání Scuku obrázky v navigaci i majitelům prohlížečů, kde to nutné není?
A pak — vidíte-li cíl kodérské práce ve stejném místě jako já, tedy ve zlepšení uživatelského prožitku technickými prostředky, nemůžete navrhnout řešení navigace Scuku jen s ohledem na objem času stráveného kodérem.
Vypadá tedy Scuk v každém prohlížeči jinak, nebo ne?
Vypadá. Na jiných místech uživatelského rozhraní Scuku už tak na kulatých rozích (a dalších CSS3 novinkách jako gradienty, border-image) nelpíme, a tak je nabídneme jen uživatelům moderních prohlížečů.
Zamířit svá rozhodnutí o podpoře prohlížečů, technologií a způsobech řešení na úroveň jednotlivých prvků stránky nám umožnilo lépe nalézat rovnováhu mezi vlastní vynaloženou energií a efektem výsledku na uživatelský prožitek.
Organizace CSS kódu pomocí „vypíchnutí zastarávajících”
Na závěr metoda organizace CSS kódu, kterou jsem poprvé aplikoval právě při vývoji rozhraní Scuku, a docela by mě zajímal váš názor na ni.
Podpora různých CSS3 vlastností napříč prohlížeči je velice různorodá, jejich implementace pomocí vendor prefixů z pohledu budoucnosti nejistá a v CSS kódu nám pak spolu sousedí pravidla, která budou mít dlouhého trvání, s těmi, jež mohou poměrně brzy zastarat nebo dokonce zaniknout.
A proto na ty potenciálně zastarávající myslíme už při psaní kódu a oddělujeme je od těch stabilních. Třeba v případě zmiňované položky navigace takto:
/* Polozka navigace */
nav#categories li a {
display: inline-block;
padding: 10px 6px;
border-radius: 7px 7px 0 0;
}
/* [OBSOLETE?] Vendor prefixy */
nav#categories li a {
-moz-border-radius: 7px 7px 0 0;
}
/* [OBSOLETE?] Polozka s Cufonem, ktery ma trochu jine proporce */
.cufon-active nav#categories li a {
padding: 9px 9px 7px 9px;
line-height: 12px;
}
Tady si držíme pevnou část pravidel a předpokládáme, že jednou přestaneme potřebovat vendor prefixy pro nastavení kulatých rohů ve Firefoxu a že namísto Cufónu pro náhradu fontů začneme používat @font-face nebo řešení některého z poskytovatelů webových fontů jako Typekit.
V jiných pravidlech s pomocí Modernizru a jeho “no-” tříd zase očekáváme zastarávání těch prohlížečů, které nepodporují některé z CSS3 vlasností (.no-borderradius).
Od tohoto experimentu v organizaci kódu si slibujeme oddělení dlouhodobě méně stárnoucího jádra od „nejisté” a rychle zastarávající části kódu. Jádro zůstává jednoduché a nejistý kód pak mám během dalšího vývoje na očích tak, abychom jej mohli postupně upravovat ruku v ruce s vývojem technologií.
Martin Michálek
Nezávislý specialista na webový frontend. O responzivním designu, HTML5, CSS3 a dalších tématech píše na blogu Vzhůru dolů nebo v ebooku. Pořádá školení. Na Twitteru je jako @machal.
Opravdu je nutné věnovat tolik prostoru pár kulatým rohům a jednomu buttonu? To jsou věci, které řeší každý kodér dnes a denně… Mimochodem než bych si zaplácal kód tímhle příkladem, raději použiju klasické sliding doors se stejným efektem, kratším kódem a podporou ve všech prohlížečích ;-)
Bohužel musím souhlasit. Článek je moc pěkně zpracovaný, ale jeho informační hodnotu by bylo možné shrnout do jednoho, dvou odstavců.
Ale ačkoliv jsem odpůrce jakýchkoliv segregací v CSS, zaujala mě myšlenka „využívat CSS3 kde lze, ostatním podstrčit obrázky“. Díky za tip.
Ale? Naopak, „kulaté rohy“ zde slouží jako vynikající, protože všem srozumitelný a jednoduchý příklad vlastnosti, kterou je potřeba upravovat specificky pro jednotlivé prohlížeče. _Postup úvahy_ shrnutý v článku je hezký a inspirativní. Technické řešení taky, ale důležitější je právě to první – myšlenka sama.
souhlasím s Karlem. nejde o kulatý rohy ale o princip řešení problému.
Ale tyhle problémy design vs úsilí přece řeší webdesigneři každý den, Mlho…
Promiň Martine, dobrý článek, jenom mám pocit že je na Zdrojáku už trochu přescukováno.
Beru to jako výbornou case study. Každý problém se dá řešit X způsoby a je prima sledovat, jak se s tím vypořádávají jiní. Osobně vůbec nevnímám, že to je nějaký konkrétní Scuk, ale některé popsané postupy považuju za velice zajímavé. Zrovna tenhle článek je hodně pěkný a užitečný: kdo si nevidí na špičku nosu, vidí v tom jen další stokrát omleté řešení kulatých rohů, kdo ale trochu přemýšlí, najde tu nádherné a praktické řešení gracefull degradation v praxi. Mně se moc líbí a určitě mi to hodně dalo. Dík.
Dlouho (mozna nikdy) jsem nepotkal tak skvele podany progressive enhancement s tak nepodlomitelnymi argumenty. Uvaha i samotna realizace je velmi chytra. Diky Martine!
To je zajímavé, za poslední týden tohle řeším už potřetí… :) Tohle není progressive enhancement (PE), ale právě naopak, příklad gracefull degradation GD): výchozí funcionalita je vytvořena pro ideální browsery, které umí kulaté rohy samy, a do kódu se přidává jako nástavba řešení pro horší browsery.
Být to PE, jde se na to přesně opačně: udělá se výchozí funcionalita, kterou zvládnou všechny browsery, a pak se tam přidává jako nástavba vylepšení pro ty lépe vybavené.
Dneska se často setkávám právě s mnoha příklady PE (prakticky všechna řešení postavená na pluginech pro jQuery a všemožné jiné JS knihovny), ale dobře udělaná GD se moc často nevidí. Proto se mi tenhle článek tolik líbí, protože tady je použita přímo ukázkově.
Martin skvěle demonstruje, že ve web designu neexistují univerzální řešení. Skutečně paráda.
Ovšem tip na vyjmutí vendor prefixů ven z hlavní definice je k nezaplacení. Dlouho jsem nemohl vymyslet rozumný způsob a tohle vypadá moc rozumně. :)
Je to pekné, ale predsa len: kopírovať aj selektor? Nestačilo by:
Jasně! Proč ne. Pro případy, kde se mění jen pravidla v rámci selektoru může být dostačující.
Kluci, tak Martinovo řešení má přeci jen chybku.. Je potřeba dávat vendor prefixy PŘED ty nevedorprefixované věci. Viz článek Chrise Coyiera. http://css-tricks.com/ordering-css3-properties/
Podle mě řešení je vyjmout i ty reálné věci a jako [FUTURE] pod to. Ale není to ideální. Máte někdo lepší nápad?
Dobrý postřeh, Honzo.
Důležité je zmínit, že řešení s odsazování „zastarávajících“ se netýká jen vendor prefixů. Koukám do CSS Scuku a převažují situace bez nich.
Příklad typické situace:
Na ten článek na CSS Tricks odkazoval už Tomáš Hellebrand a já si říkal, že musím otestovat kolik kombinací prohlížeč/CSS3 vlasnost/pořadí je takto postiženo. Chris zmiňuje kombinaci jen jednu.
Nicméně – odsazování a uvádění „zastarávajícího“ kódu za kód „stabilní“ je jen jednou částí výhody toho řešení.
Asi důležitější součástí je štítek [OBSOLETE?], pomocí kterého můžeš „zastarávající“ kód snadno dohledávat během budoucích aktualizacích webu.
Dovedu si pak příklad z článku představit takhle:
Není to tak elegantní, ale zase nepoužívám dvakrát stejný selektor jak správně psal Tiso.
Nakonec, Textmate myslím umí vytáhnout z kódu všechny části označení pomocí TODO. Určitě by ho nějaký zkušený uživatel Maca (tedy nikoliv já .-)), naučil vytáhnout i všechny [OBSOLETE?]. :-)
Píšete, že jste se rozhodli nepoužít CurvyCorners, abyste prohlížeče nezatížili další vrstvou JavaScriptu. A najednou bum ho, Modernizr. Rozhodli jste se pro tuto vrstvu JavaScriptu na základě benchmarků, a pokud ano, můžete se prosím podělit o čísla?
Nebylo to na základě benchmarků. Modernizr bychom použili vždycky pro jeho přínos, který má pro vývojáře a v důsledku i pro uživatele.
„Další vrstvou“ je CurvyCorners vzhledem k ostatním scriptům, které na Scuku používáme. Určitě jste se díval do zdrojáku, je jich dost. Proto přidání každého dalšího dost zvažujeme.
Modernizr jen jednorázově při startu během pár milisekund detekuje browser capabilities a přidá třídy pro tag body, za běhu stránky tedy už žádnou zátěž nepředstavuje.
CurvyCorners přidají do layoutu desítky DIVů a event listenerů na změny a přidání elementů, čímž zvýší zátěž CPU po celou dobu zobrazení stránky.
Ale vy jste si asi přišel jen zakřičet, že (soudím tak podle toho, že mi přijde zbytečné benchmarkovat jeden ‚rozvětvený if‘, kterým modernizr je, a stejně tak mi přijde, že nikdo, kdo ví, co dělá, by ho nenazval ‚vrstvou‘)?
Dobrý den,
přišel jsem se zeptat na věc, které jsem se kvůli své chabé znalosti problematiky nerozumněl.
Mějte se.
Jeste se podivejte na: ‚http://prirucka.ujc.cas.cz/?slovo=rozumět&Hledej=Hledej‘ Treba Vam to take diky Vasi „chabé znalosti problematiky“ pomuze.
Perfektní článek, díky Martine.
Jedna poznámka k vendor prefixům. Obecně se doporučuje dávat vendor prefixovaný vlastnosti před ty obecný (tzn. -moz-border-radius před border-radius) – viz. například http://css-tricks.com/ordering-css3-properties V uvedeném příkladě by stačilo jen přesunout „obsolete“ sekci úplně nahoru.
Jinak já kvůli CSS3 a vendor prefixům používám SCSS (http://sass-lang.com/) to mi umožní mít vendor prefixy jen na jednom jediném místě jako:
@mixin border-radius($pRadius){ -webkit-border-radius: $pRadius; -moz-border-radius: $pRadius; border-radius: $pRadius; }Pak můžu kdekoliv jednoduše použít kulaté rohy jako:
nav#categories li a { @include border-radius(5px); }Má to tu výhodu, že je to krásně přehledný (jen jeden řádek místo tří a více) a krásně se to udržuje. Až v budoucnu nebude potřeba používat např. -webkit prefix, tak ho na jednom jediném místě odstraním. Stejně snadno můžu přidat nový prefix, pokud to bude potřeba.
Sass chladně vládne, takhle mělo vypadat CSS od začátku.
Díky za doplnění, Tomáši.
Osobně SASS a spol. nemusím, mám rád věci co nejjednodušší (http://kratce.vzhurudolu.cz/post/409587540/manual-stylopisu), ale to už je jiná diskuze.
No právě kvůli jednoduchosti, kterou mi přináší, používám SASS! Tak to asi necháme na tu jinou diskusi :)
Výborný článek! Moc se mi líbí, že autor uvažuje, než do stránky hodí nějakou univerzální všeřešící knihovnu. S dovolením bych přidal svůj ryze laický pohled, ať ho můžeme zkonfrontovat :-)
Chybějící CSS3 vlastnosti vnímám z hlediska zastoupení prohlížečů jako problém čistě IE. Na druhou stranu tento prohlížeč jako jediný podporuje VML, což si troufám považovat za ověřenou a rychlou technologii, protože na ni staví Cufon. Tedy bych hledal něco, co simuluje border-radius pomocí VML a nedělá nic jiného. Pohled do zdrojového kódu CurvyCorners je pro mě odrazující, není tam zmínka o VML, zato má 55kB. (Odrazující je tedy i samotný web a přehled feature, které nechci). Vygooglil jsem totok http://code.google.com/p/curved-corner/ a zdá se, že uvedené řešení splňuje všechny požadavky. Malinké, registruje si pouze událost onresize a získám vektory namísto tahání bitmap ze serveru.
Trošku jinak bych postupoval i při úpravě stylesheetu. Opět zcela souhlasím s myšlenkou, tedy že fixy je třeba oddělit od čistého kódu. Nicméně jako srozumitelný oddělovač vnímám samotný vendor prefix (resp. behavior:url). Jejich další vyčleňování mi připadá jako hlásit, že klakson troubí :-) Samozřejmě něco úplně jiného je běžná vlastnost (např. padding) řešící konkrétní problém nějakého prohlížeče. Ale i tam jsem si svého času dělal poznámku v podobě prefixu, kterému rozuměl buď jen IE 6 resp. 7. Tedy vyčleňoval bych teprve v okamžiku, když by byl fix tvořen více vlastnostmi dohromady.
Berte prosím komentář s rezervou, CSS není můj šálek PHP.
Ale ku***práce! Tohle je můj poslední komentář na Zdroják. To je fakt úžasný, když na serveru, kde vychází články o tom, jak vycházet vstříc uživatelům, dokážou uživatele tak naat tím, že mu dorví komentář a srazí ho do jednoho řádku. Jděte s tím Texy už do**dele ******** ******.
Ku##a tu se nedá ani nadávat, vono mi to hvězdičky bolduje!
To víš, Texy! :)
Přidání názoru trpí závažnou a velmi častou chybou použitelnosti: nikde není uvedeno, jaký formát vstupu se očekává. Pod boxem je jen cosi o povolených XHTML značkách, o Texy ani zmínka. Taky nikde není uvedeno, jak by se měly psát speciální znaky jako třeba &.
Proč je ze strany Zdrojáku vždycky takové hrobové ticho, když přijde na formátování komentářů? Martine, pokud tuhle věc nemůžeš ovlivnit, tak aspoň prosím napiš, co se kua děje, nebo (ještě lépe) dej kontakt na někoho zodpovědného. Nasíráte si čtenáře úplně zbytečně.
Borku – vždy to předávám vývojářům. To je celé co s tím mohu dělat; zbytek jsou interní firemní procesy, které neovlivním. „Kontakt na někoho zodpovědného“ je představa sice dráždivá, ale neproveditelná (čti: to se nedělá). Takže: Ne, nemohu to ovlivnit víc než to ovlivňuju, tj. bugreportem a požadavkem na změnu. Ne, kontakt na vývojáře dát nemohu. Že jsou čtenáři nasíráni (a nejen tímto) a že mi podobné záležitosti ztěžují vydávání článků o použitelnosti etc. vnímám nelibě – a věř, že mou nelibost patřičná místa slyší. Ale to je tak asi všechno.
Doufám že si uvědomuješ, že nejsme na blogu, kde stačí pojebat majitele v komentářích, aby „s tím něco udělal“, a on může někam sáhnout a něco změnit…
Samozřejmě si uvědomuju, že tohle je typický boj s firemním procesem, který není nikdy jednoduchý. Skutečnost je ale taková, že se ani po mnoha měsících neděje nic, a ačkoliv to rozhodně nedávám za vinu tobě (a doufám, že ani nikdo z ostatních), nevěřím, že s tím nejde nic dělat. Chápu, že se odkaz na programátory nedává, ale oni mají nějakého šéfa, ty máš nějakého šéfa nebo prostě někde sedí někdo, kdo má pravomoc i zodpovědnost tuhle věc řešit, a právě od řešení takovýhle procesních problémů ve firmě tyhle lidi jsou. Pokud máte v bugzille už 10 měsíců jednoduchý bug report na špatné zalamování odstavců s top prioritou a programátoři na to kašlou, jejich šéf by o tom měl vědět. Pokud na to kašle jejich šéf, měl by o tom vědět jeho šéf atd. Vím, že procesy jsou někdy zkostnatělé, ale tohle je dlouhodobá ostuda Zdrojáku a musí se vyřešit.
Znovu opakuji, že tohle není vůbec nic proti tobě, chápu, že jsi v trochu nešťastné pozici a možná tě problémy s komentáři štvou víc než nás ostatní dohromady, ale tohle všechno je jen snaha podpořit tvé úsilí o nápravu a možná způsobit trochu víc hluku, aby si toho někdo všimnul. Tak mě napadá, na http://www.iinfo.cz/o-nas/vedeni-spolecnosti/ jsou kontakty na lidi z vedení, zkusím se na ně večer obrátit (Miklík + Krause?).
Logický klam: „Na druhou stranu tento prohlížeč jako jediný podporuje VML, což si troufám považovat za ověřenou a rychlou technologii, protože na ni staví Cufon.“
Ještě se v článku zapomnělo na řešení čtvrté a páté, prostě kulaté rohy nevykreslovat nebo je klasicky vykreslit skrze obrázek (což při 10MB inetu a směšné velikosti opravdu nikoho nezpomalí – to více zpomalí načtení a vykonání toho js).
Jinak hezký článek.
Ještě se v článku zapomnělo na řešení čtvrté a páté, prostě kulaté rohy nevykreslovat nebo je klasicky vykreslit skrze obrázek
Nezapomnělo. :-) Je o nich zmínka v rozhodovacím procesu.
K obrázkům – to v článku není a stojí za zmínku. Samozřejmě technicky není žádný problém použít obrázky všude, nejen v navigaci pro IE. V případě Scuku, kdy kulaté rohy zdobí velké množství prvků s různými variacemi barev, rozměrů, rámečků atd. si myslím rychle spočtete, že kodérovi raději zaplatíte za něco užitečnějšího. :-)
Nádhera. To je samý podnětný komentář. Musel jsem si ověřit URL stránky, zda jsme ještě na Zdrojáku. ;-)
Davide, Na CurvedCorner jsem buď nenarazil, nebo mě odradilo to HTC a bál jsem se výkonnostních problémů. Musíme vyzkoušet. Pro použití jen v té navigaci může sloužit dobře.
Jak píšu v odpovědi Honzovi Sládkovi – to štítkování „zastarávajících“ se netýká jen vendor prefixů. Mnohem častěji ho využívám pro oddělení situací, kdy prohlížeč nepodporuje některou z HTML5 nebo CSS3 vlastností vůbec (např. neumí placeholder) nebo třeba pro oddělení úprav nadpisů generovaných Cufónem. Ten s námi taky už dlouho nepobude. :) Proto ty „zastarávající“ ještě štítkuju jako [OBSOLETE?]. Jinak bych je za půlroku nenašel. :)
Myslenka s pouzitim css3 kulatych rohu kde to jde a jinde s pomoci modernizru pouzit obrazky je asi nejlepsi soucasne reseni.
Zkusil jsem asi 10 reseni js kulatych rohu. prvni to ma vzdy ten wow efekt. potom stavite slozitejsi sablonu a najednou zjistite ze jedno reseni nefunguje s position absolute. druhe ma problemy ze z-index, treti se „zahadne“ prestava fungovat po pridani jquery. nemluve o mensich problemech jak obcasne zdvojnasobeni paddingu, zruseni marginu apod – vse vzdy samozrejme nejlepe jen v jednom prohlizeci a jen za specifickych situaci. chvilku se to snazite reportovat obchazet, pridavat hacky ktere to opet „davaji dohromady“. nakonec proste zjistite za ty problemy to nestoji.
nicmene pokud nekdo chcete zkusit tak ze soucasnych reseni mi jako nejlepsi pripada http://css3pie.com/
pouziti „OBSOLETE“ naopak povazuji z krok vedle. nikdo nedokaze rict co bude do budoucna. jsou to tak jen odhady. navic odstraneni techto casti v pripade globalniho utrideni je stejne napovazenou protoze ne kazdy musi mit vte dobe aktualni verze prohlizecu. a ponechani nekolika „zastaralych“ css vlastnosti neni zadny problem.
pouziti „OBSOLETE“ naopak povazuji z krok vedle. nikdo nedokaze rict co bude do budoucna.
Dobře, hledím do své křišťálová koule a tvrdím, že pokud za rok bude svět světem, stane se toto:
Mohl bych pokračovat, ale nechávám si rezervu. Přecejen mohli mít Mayové pravdu. .-)