Tedy zmínky, spíš bych to nazval únik informací.
Jedná se o adresu http://www.hixie.ch/tests/evil/acid/004/, kam si Ian Hickson začal psát své poznámky ohledně testu Acid4. Někdo ji objevil a zveřejnil na Ajaxian.com. Docela by mne zajímalo, kde to objevili, protože tohle mým zdrojům zcela uniklo.
Následné informace proto berte s rezervou, a jen pro ty opravdu zvědavé (a ty, co se nestydí nakukovat do soukromých poznámek). Vy ostatní honem huš pryč!
Acid4 bude převážně vizuální test bez výrazného skriptování. Zaměří se na SVG, CSS a míchání jmenných prostorů, hlavní dokument pravděpodobně bude XML soubor s SVG kořenovou značkou.Ian se v Acid4 tedy nejpíš zaměří na XHTML a další XML formáty.
Na jeho vznik si podle všeho ještě pár let počkáme:
Práce na Acid4 začne jakmile budou existovat buildy tří ze čtyř hlavních renderovacích jader, které testem projdou a bude ukončen a oznámen, až výrobci čtyř renderovacích jader oznámí, že opravili chyby nalezené v Acid3 (to může nastat mnohem dřív než se tato jádra skutečně dostanou do prohlížečů).Pozn.: V první větě je zřejmě myšleno "jakmile 3 jádra projdou Acid3 testem", ačkoliv z přesné formulace vyplývá "jakmile 3 jádra projdou Acid4 testem", což nezní moc pravděpodobně.
A bez zajímavosti není ani seznam bodů, kterých se Ian chce u Acid4 vyvarovat (vychází zřejmě z některých kritik testu Acid3).
Poučení z Acid3Toliko z poznámek člověka, jenž se pomalu ale jistě řadí mezi lidi, kteří nejvíce ovlivnili vývoj Webu a webových prohlížečů.
- nezahrnovat minoritní chyby
- nevyžadovat testy od jiných, psát všechny testy sám
- zjišťovat feedback již od začátku od (t=0) bodu, jak veřejně, tak osobně od konkrétních lidí
- zjišťovat feedback, které věci testovat
- nevystavovat test v prvních fázích, aby se zabránilo lidem v odkazování, zatímco se řeší, co se má vlastně testovat
- nezahrnovat do testu výkonností složku (ačkoliv jako zvláštní soutěž je to možné, pokud všichni odsouhlasí, že je to fér)
- ať se jedná o pěkný obrázek
Je zajímavé, že se Ian, ačkoliv se veřejně nebojí vyjadřovat svou skepsi k XHTML, v testu Acid4 zabývá právě XML.
Já Iana trochu podezřívám, že se snaží vše načasovat, aby test, který bude vytvářet po tom, tedy Acid5, mohl vyjít společně s HTML5 specifikací a testovat tak HTML5 a XHTML5. Potom není s podivem, že se mezi tím věnuje XML. Na HTML není do té doby moc co dalšího testovat.
"nezahrnovat do testu výkonností složku (ačkoliv jako zvláštní soutěž je to možné, pokud všichni odsouhlasí, že je to fér)"
OdpovědětVymazathm a já čekal, že Acid4 bude právě zaměřen na rychlost. SVG je hezké, ale když už i v Opeře je svg pomalé a brutálně zatěžuje CPU tak by se nad tou rychlostí v browserech měli pozastavit. A to si všichni vysnívají ty krásné "web apps", ale kde je ten výkon? Podívejte se na Flash a pak okamžitě zahrňte "speed test" do Acid4 (hixie na webu speed testy má). (btw speed testem nemyslim blbůstky jako ten sunspider bo jak se to ... ale komplexní testy renderování a zpracovávání dokumetu)
Právě výkon JavaScriptu a webových aplikací se za poslední rok zvýšil snad ve všech prohlížečích opravdu výrazně, na to bych si nestěžoval.
OdpovědětVymazatSVG se zrychlí, pokud se stane pro výrobce komerčně zajímavé (což zatím není), k tomu není zapotřebí žádná jiná motivace.
Zvýšil? Ne že by ne, ale ke komfortu 'aplikací' to má daleko.
OdpovědětVymazatf.e.
http://www.unwieldy.net/moocirclepack/demo/json.html
Firefox ačkoliv "zrychlili" js-engine je prostě pomalý, přesně vystihující "svižnost" dnešních web apps. Opera ok. Nepřál bych vám vidět něco podobného ve Flashi, protože by to bylo až okouzlující :)
No asi je to jen moje zbožné přání aby prohlížeče byly rychlejší, možná se dočkám až s hw akcelerací..
[ http://my.opera.com/core/blog/ ]
Neřeším, nač čekat když už je tu flash.
Pro upřesnění, to demo knihovny Moocirclepack používá canvas, nikoliv SVG. V Internet Exploreru je to pomalé, protože je musí být celý canvas emulovaný.
OdpovědětVymazatNo, že to používá SVG sem neměl ani páru a MSIE jsem k tomu ani nepustil ;-) Šlo mně spíš o demonstraci rychlosti a byl to první článek na který jsem si vzpomněl.
OdpovědětVymazatKdyž jsem se bavil o SVG tak jsem měl na mysli http://dev.opera.com/articles/view/opera-9-5-the-next-generation-of-web-s/#svg
Konkrétně ta spirála a ty svg filtry. Oboje se už při scrollování trhá a značně to vytěžuje cpu. To stejné lze říci o menu u svg filtrů. I když teď mluvím spíše o Opeře, pač ve firefoxu filtry nevalí a text ve spirále nejde označit. hm
SVG spirála: jak jsem už psal, jakmile to bude komerčně zajímavé, zrychlí se to. Zatím to asi nemá moc velkou prioritu.
OdpovědětVymazatNo když už se maká na HTML5 (nemám šajnu jak na tom Fx je, ale tuším, že na tom maká), tak bych čekal podporu SVG. Prostě web-dopředu a ne vývoj typu "MSIE to nemá/nepodporuje/nebude podporovat" = malá priorita.
OdpovědětVymazatAle to je asi blbost pač na CSS3 taky makají. A to taky není 'komerčně zajímavé' nebo je?
Nezapomeňte rozlišit mezi implementací a optimalizací implementace. To druhé se vyplatí až ve chvíli, kdy nastává reálné nasazení na Webu. Což je případ právě toho SVG, které se bez podpory v IE širokého nasazení nedočká.
OdpovědětVymazatU HTML5 a CSS3 probíhá ta první implementační fáze, často za dohody s W3C, protože tam zpětnou vazbu od implementátorů potřebují (a bez minimálně dvou implementací každého bodu specifikace ani specifikaci vydat nesmí).
Souhlasím, ale jak někdo může začít něco používat když je to "nepoužitelné" (pomalé)..moc to řeším, nechám to nějak 'vyvinout' ;)
OdpovědětVymazat