Firefox 3.5 – co nabídne nového?

22. 5. 2009 | David Kolibáč | Novinky | 10554×

Blíží se vydání nové verze (3.5) webového prohlížeče Mozilla Firefox. Co nabídne? Podrobnější nastavení soukromí, vyšší výkon při zpracovávání JavaScriptu nebo třeba novinky v oblasti HTML 5, CSS 3 a DOM.

Úvodem

Koncem dubna vyšla čtvrtá betaverze Firefoxu 3.5, používající renderovací jádro Gecko 1.9.1.

Měl jsem k dispozici Firefox 3.0.10 z repozitářů Ubuntu a noční sestavení páté betaverze Firefoxu 3.5 z repozitáře

http://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu jaunty main

a to na počítači s Ubuntu 9.04, CPU Intel Pentium M (na 1,7 GHz) a 1 GB paměti. Obě verze Firefoxu byly bez doplňků a dat z dřívějška.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042523 Ubuntu/9.04 (jaunty) Firefox/3.0.10
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b5pre) Gecko/20090515 Ubuntu/9.04 (jaunty) Shiretoko/3.5b5pre

Dále budou uvedeny některé novinky ve Firefoxu 3.5, více v poznámkách k vydání. Finální verzi lze očekávat začátkem léta.

Změny v rozhraní

Soukromí

Z uživatelského hlediska je asi nejpatrnější novinkou možnost prohlížení webových stránek ve zvláštním režimu (Private Browsing Mode), v němž se neukládají cookies, cache, historie navštívených stránek, ani nic dalšího.

Navíc byla přepracována odpovídající sekce v nastavení: Lze si nastavit, zda se má ukládat vše, případně se nemá ukládat nic, nebo si lze vybrat zvláště uchovávání historie stránek, stahování, dat zadaných do formulářů, případně cookies. Také si lze vybrat, zda má napovídání v adresním řádku fungovat na základě informací z hledání, nebo jen ze záložek.

Dialog pro rychlé odstranění uložených informací o prohlížení se také dočkal rozšíření: je možné smazat data z posledních hodin (lze si vybrat), a to v nastavitelném rozsahu.

Jiné

Pokud Firefox spadne, můžete si ve stávající verzi zvolit otevření stránek otevřených před pádem pouze při znovuspuštění prohlížeče. Nová verze přidává zvláštní stránku s uloženou relací (about:sessionrestore), takže se k ní můžete vrátit až časem.

Přibyla také zvláštní chybová stránka pro chyby certifikátů (about:certerror), jelikož ta stará mohla působit matoucím dojmem.

Dále je možné například procházet odkazy v zobrazení zdrojového kódu.

Výkon

Zrychlení vykreslování

Nový Firefox stránky vykresluje rychleji, dokáže totiž „předvídat" obsah stránky (speculative parsing).

Rychlost GUI, paměť

Zrychlení běhu programu jsem nepozoroval, běží (oproti dřívějšku, aspoň u mě) zcela plynule. Ve výchozím nastavení mi Firefox 3.0 zabral v paměti zhruba 18 MB, betaverze o osm megabajtů více, s rostoucím počtem panelů se rozdíl neměnil. Předpokládám, že do budoucna se to zlepší, ostatně v nové verzi má být spotřeba paměti nižší až o třetinu.

TraceMonkey

TraceMonkey urychluje interpreter JavaScriptu (SpiderMonkey) překladem do strojového kódu.

Obě verze Firefoxu jsem prohnal benchmarkem jednak z webu Celtic Kane Online a jednak benchmarkem SunSpider. Je vidět, že došlo k docela výraznému zrychlení.

Test/Verze 3.0.10 3.5b5pre Array object 20 ms 69 ms Date object 19 ms 43 ms Error handling 50 ms 5 ms Math object 47 ms 8 ms RegEx object 140 ms 79 ms String object 53 ms 37 ms DOM 90 ms 91 ms Ajax declarations 283 ms 258 ms Celkem 702 ms 590 ms Benchmark z Celtic Kane Online

Test/Verze 3.0.10 3.5b5pre 3d 968,4 ms 481 ms acces 1117,4 ms 463,8 ms bitops 770 ms 154,2 ms controlflow 103 ms 118,6 ms crypto 512,4 ms 266,2 ms date 634,2 ms 426,4 ms math 836,8 ms 243,6 ms regexp 478 ms 240,2 ms string 1669 ms 969,4 ms Celkem 7089,2 ms 3363,4 ms Benchmark SunSpider

HTML 5 a CSS

Audio a video

Nově jsou podporovány elementy audio a video z HTML 5. Ukázka (případ elementu audio je ekvivalentní):

<video src="http://muj.web.cz/video.ogg" autoplay>
	Váš prohlížeč nepodporuje element video.
</video>

Je také možné uvést video ve více formátech, zvolí se první podporovaný:

<video autoplay>
	<source src="http://muj.web.cz/video.ogg" type="video/ogg">
	<source src="http://muj.web.cz/video.mov">
	Váš prohlížeč nepodporuje element video.
</video>

Samozřejmě se objevily i příslušné události pro JavaScript.

Písma ke stažení

Další novinkou je možnost nabídnout v CSS použité písmo ke stažení. Webdesignérům se tedy zjednodušuje situace, co se týče kompromisu mezi kompatibilitou a použitím vlastního (atraktivního) písma - tato záležitost je již dlouho podporována v MSIE pro OpenType písma a nyní ji ovládá i Opera 10, Safari 3.1 a Firefox 3.5 (všechny pro OpenType i TrueType písma).

@font-face {
	font-family: "Moje Pismo";
	src: url("http://muj.web.cz/pismo.ttf");
}
body {
	font-family: "Moje Pismo";
}

Další novinky

Samozřejmě přibylo více věcí, například:

• podpora více selektorů z CSS 3
• detailní výběr stylopisů podle výstupního média (Media queries), například podle rozlišení nebo podpory barev
• javascriptové API pro rozpoznávání aktuální polohy dle IP - může být použito třeba ve vyhledávačích služeb pro relevantnější výsledky
• v základu je povolena korekce barev ICC
• přednačítání DNS (DNS prefetching) pro plynulejší prohlížení webu při používání mobilního připojení
• podpora formátu Ogg
• lepší podpora pro drag'n'drop ve webových aplikacích (dle HTML 5)
• lokální ukládání dat webových aplikací (dle HTML 5), z čehož vyplývá možnost provozu online aplikací offline
• integrace podpory pro JSON do DOM
• podpora více vláken ve webových aplikacích
• … (https://developer.mozilla.org/En/Firefox_3.5_for_developers)

       

Komentáře

Náš administrátor shledal tento komentář závadným.

Vulgární

Zobrazit komentář

[Vin]

To může člověk dělat i teď.

[Vesmir]

chtěl bych, aby mi ti milí vývojáři přidali dalších 10cvaknutí myší při vstupu na stránku s nepodepsaným certifikátem - to mě totiž děsně baví

taky si rozhodně nikdy nechci přesunout osobní data jako třeba oblíbené nikam jinam než do dokument&settings - to mi rozhodně nedovolte a když tak jedině ať se hrabu v about:config, na tom ujíždím

v linuxu mi rozhodně nedávejte na backspace "stránku zpět" ať si mám s čim hrát

když už se vám povedlo smotat dohromady historii zpět a v před, nešlo by ještě místo dvou tlačítek dát jenom jedno, víc stejně nepotřebuji, nebo víte co, dejte ho pryč úplně

a ta práce se záložkami - jak mi ff vždycky inteligentně nabídne pro novou záložku nějakou podsekci a zaručeně tu co nechci, no holt stále mně udržuje ve střehu a nutí klikat

 

 

[default]

Mě by spíš bavilo to neustálý překonfigurovávání proxy serverů podle toho, do který sítě se zrovna připojuji.

[petr_p]

Na to ne nejlepší lék rozjet si proxy na localhostu, tam nasměrovat všechny aplikace a přepínat jenom nastavení této místní proxy (třeba háčkem z DHCP klienta).

[default]

Ještě lepší! Opravdu unikátní přístup. Jen co je pravda.

OS X má tak zvané Locations, které přesně toto řeší. Všechny aplikace krom Firefoxu se umí podle aktuální location nakonfigurovat, tak já budu kvůli Firefoxu něco programovat a ladit. Zrovna já.

[petr_p]

Programů, co na nějaké Locations dlabou, bude mnohem více než těch pár prográmků, co používají knihovny od Apple.

Mimochodem v linuxovém portu Firefoxu je možnost respektovat proměnnou prostředí http_proxy schovaná pod názvem „Systémové nastavení proxy serverů v systému“. V Mac OS X to nefunguje?

[default]

Příloha:

• Snapshot 2009-05-29 09-25-30.tiff (124172 bytů)

Proměnné prostředí a OS X? Tato vychytávka je samozřejmě podporována, ale řeší se přes plist soubor a musí se kvůli jeho změně člověk alespoň "přehlásit". Co se týče Systémové nastavení proxy serverů v systému, tak tomu nerozumím. Přikládám dialog, který mám k dispozici.

Předem upozorňuji, že volba s názvem Auto-detect proxy settings for this network možná něco detekuje, ale proxy servery rozhodně ne.

[petr_p]

Proměnné prostředí a OS X?

To byl příklad z Linuxu. Pokud v Mac OS X existuje jediný zprávný způsob – locations, tak bych čekal, že jej Firefox bude používat.

musí se kvůli jeho změně člověk alespoň "přehlásit"

Jistě, kopírování prostředí při fork(2) je jednorázová věc.

Co se týče Systémové nastavení proxy serverů v systému, tak tomu nerozumím. Přikládám dialog, který mám k dispozici.

Aha, v Linuxu tam je ještě jedna volba navíc, ta, kterou vy tam nemáte.

Každopádně poškáldete mozilláckou Bugzillu. Třeba najdete řešení.

[default]

Každopádně poškáldete mozilláckou Bugzillu. Třeba najdete řešení.

To jsem udělal. Těch bug tam mají tolik, že jsem raisnul novou a hoši ji promptně zavřeli, že se prý jedná o duplikát. Je fajn, že aspoň někomu se chce ty duplikáty dohledávat.

[Filip Jirsák]

chtěl bych, aby mi ti milí vývojáři přidali dalších 10cvaknutí myší při vstupu na stránku s nepodepsaným certifikátem - to mě totiž děsně baví

A ještě by mohli úplně odstranit to zaškrtávátko, které jako výchozí hodnotu nabízí přidání certifikátu mezi důvěryhodné. Když je ten certifikát tak nebezpečný, že se kvůli němu musí uživatel uklikat, tak je přece jasné, že má být automaticky přidán mezi důvěryhodné, ne?

[Petr Tomeš]

A dal jste námět do Bugzilly? Doporučuji přečíst dva vysvětlující příspěvky v blozích vývojářů Firefoxu k certifikátům. Firefox 3 používá několik set milionů uživatelů a žádná tragédie ani konec světa se nekonají.

[Filip Jirsák]

Nedal. Mám lepší věci na práci, než nechat si vysvětlovat, že miliardy uživatelů to tak chtějí…

[Petr Tomeš]

Tak to si nemusíte ani vzdychat na fórech a dělat ty lepší věci na práci, máte-li tedy nějaké.

[Jirka K.]

Inu, pane Tomeši, jednak mám dojem, že vzdychání na fórech je částí jejich legitimního významu .

A druhak a hlavně, ten příspěvek má smysl v tom, že nás ostatní upozornil na přetrvávající vlastnost FF, kterou já osobně pokládám taky za dost pitomou - způsob zacházení s certifikáty a bezpečnostními funkcemi s nimi spjatými.Takže dík p. Jirsákovi za hlasité "vzdychání" zde na fóru.

Mimochodem, ani já jsem své připomínky do Bugzilly nedal, neumím anglicky tak dobře, aby mi to bylo co platný, zrovna tak, jako vaše odkazy na vysvětlující příspěvky. Nezapomeňte prosím, že ne každý tu anglinu ovládá .

A k věcnému obsahu výhrad - mě nejde o to, že bych zacházení FF s certifikáty pokládal za málo bezpečné. Ne, ale pokládám ho za otravné a pitomé. Mě osobně při mém způsobu práce se sítí většinou použití certifikátů nijak nechrání, ale zato mě občas docela dost otravuje. Uvítal bych kdyby tyto a podobné módní bezpečnostní funkce bylo možno jednoduše konfigurovat a zejména jednoduše vypínat. 

[Petr Tomeš]

Kdyby to lidé opravdu tak hodně chtěli nebo jim to vadilo, upozornili by na to během betaverzí Firefoxu 3 atd. Žádné takové velké ovace jako vy s panem Jirsákem nebyly, podíl Firefoxu (3) neustále roste, takže možná to bude v další verzi provedeno trochu lépe, ale taková tragédie to určitě nebyla.

[Filip Jirsák]

Pokud budeme měřit kvalitu prohlížeče počtem uživatelů, je bezkonkurenčně nejlepší MSIE.

Dávat ty certifikáty do Bugzilly je podle mne marné, protože to takhle někdo zmrvil evidentně schválně – tedy ne že by záměrem bylo to poškodit, ale záměrem bylo, aby to fungovalo takhle, tedy program se chová podle zadání, ale špatně je už to samotné zadání. No a je asi marné vysvětlovat někomu v Bugzille, že když dám uživateli za sebou asi 3 dialogy, kde musí potvrdit, že opravdu souhlasí se vším, nemůžu do posledního dialogu dát zaškrtávátko "zapamatovat navždy" ve výchozím stavu zaškrtnuté, čímž popřu ty 3 předchozí dialogy.

[default]

dám uživateli za sebou asi 3 dialogy, kde musí potvrdit, že opravdu souhlasí se vším, nemůžu do posledního dialogu dát zaškrtávátko "zapamatovat navždy" ve výchozím stavu zaškrtnuté, čímž popřu ty 3 předchozí dialogy.

Nuhehe. Právě jsem pochopil, proč podíl Firefoxu (3) tolik roste.

[Petr Tomeš]

Už jste ten idiotský argument o počtu uživatelů psával mockrát. Ale to nelze, neboť Firefox si dritvá většina lidí vybrala, protože ho chtějí (je lepší) a stávající jim ani nejde odisntalovat, a tržní podíl mu roste víc než všem ostatním prohlížečům dohromady, a podíl IE dlouhodobě klesá.

[Filip Jirsák]

Ale to nelze, neboť Firefox si dritvá většina lidí vybrala

Ke zbytku je zbytečné cokoliv psát, ale aspoň k tomuhle: když správce sítě (nebo třeba firemní politika) rozhodne, že jediný povolený prohlížeč je prohlížeč XY, nedá se moc mluvit o tom, že to uživatelé chtějí. A koncovým prohlížečem může být jak Firefox, tak MSIE (ostatní prohlížeče asi jen zřídka).

[Petr Tomeš]

Ale už to rozhodnutí je volba nějaké zodpovědné osoby. V časech, kdy měl IE 95 % trhu a velké množství stránek a aplikací jinde ani nefungovalo (nebo špatně), prakticky žádná reálná alternativa nebyla. To je tak jednodcuhý důvod, že byste ho mohl pochopit i vy, pane Jirsáku.

[Filip Jirsák]

Ale úplně stejné rozhodnutí zodpovědné osoby je pak ponechat MSIE. A MSIE má největší podíl uživatelů, počet uživatelů je přímo úměrný kvalitě prohlížeče, tedy MSIE je nejkvalitnější prohlížeč. Q.E.D.

[Petr Tomeš]

Samotní užvatelé i zodpovědné osoby přecházejí k Firefoxu. V ČR a Evropě už Firefox už Internet Explorer pomalu předbíhá. Určitě jsou vážné důvody, proč lidé od IE utíkají a proč přibývají nejvíce k Firefoxu, přestože si mohou vybrat z ostatních. Opera, Chrome i Safari se propagují docela dost už dlouho, píše se o nich taky dost...

[Fluttershy, yay!]

...a podíl WebKitu prý roste rychleji než v případě Gecka. A WebKit je IMHO výrazně lepší.

[Grunt]

A WebKit je IMHO výrazně lepší.

Ale no ták.

[Fluttershy, yay!]

Ale už to rozhodnutí je volba nějaké zodpovědné osoby.

Ano, měl jsem možnost potkat několik lidí, kteří zavedli na poměrně velké množství počítačů Internet Explorer 7, respektive Firefox 2 --- jejich rozhodnutí byla značně problematická (jeden tomu hovno rozuměl, poradil se s externí MS-friendly firmou a nyní trpí stovky uživatelů; jiný byl zase nadšencem ohledně Firefoxu a to neuvážené rozhodnutí mělo negativní následky). Prostě to musí dělat někdo, kdo má rozum a přehled v oboru.

[Nicky726]

chtěl bych, aby mi ti milí vývojáři přidali dalších 10cvaknutí myší při vstupu na stránku s nepodepsaným certifikátem - to mě totiž děsně baví

Jop, to mám taky děsně rád. Nejlepší to je ve škole, kde na některých učebnách FF nemá přístup ke své historii a člověk si musí všechny ty výjimky naklikat znovu.

[Petr Tomeš]

Což je spíše vada na vaší škole, že ubírá z hodnoty Firefoxu.

[Filip Jirsák]

Nový Firefox stránky vykresluje rychleji, dokáže totiž „předvídat" obsah stránky (speculative parsing).

No to bude dílo. Už teď Firefox problémy, když musí v nevhodném místě přerušit parsování kvůli čekání na data. Teď si ten zdroják ještě začne domýšlet...

[cronin]

Moja skusenost je, ze kedykolvek, ked pocitac zacne rozmyslat, nedopadne to vobec dobre.

[Petr Tomeš]

A nějaký konkrétní argument? Těžko by zařadily novinku tak, aby to pracovalo čtvrt miliardě uživatelů Firefoxu hůře než předtím, to spíše naopak.

 

[Filip Jirsák]

Beru zpět, ta chyba, kterou jsem myslel, byla po 7 letech opravena. To bych měl tu verzi 3.5 nějak oslavit…

[Petr Tomeš]

No vidíte to. V každém softwaru jsou nějaké chyby už od prvopočátků. Chápu, že některé mohou někdy vadit, ale odkládat kvůli nim vydání jinak poměrně dobrého produktu donekonečna je horší řešení.

[=^..^= AmigaPower®]

Jak ten speculative parsing vůbec funguje? Jaký to bude mít vliv na frame, iframe a table?

[Andrej Herceg]

Prehliadač spracováva html dovtedy, dokým nenarazí na script tag. V spracovávaní nasledujúcich značiek nepokračuje až kým sa ten skript nestiahne, nespracuje a nevykoná, keďže ten javaskript môže vložiť ďalší html kód (prípadne niečo ako <!--).

Ten skript oveľa častejšie zásadným spôsobom neovplyvňuje html kód, takže môže byť výhodné spracovávať nasledujúce značky aj s tým vedomím, že sa tá práca bude musieť, po vykonaní toho skriptu, opakovať.

[Filip Jirsák]

Takže jinými slovy to ignoruje atribut defer? Hlavně že se MSIE vyčítá, že se snaží být chytřejší, než autor webu. Takže FF už také…

[=^..^= AmigaPower®]

MSIE je "zlo" né prohlížeč, abych optimizoval web pro IE, musel bych navýšit obsah kódu minimálně o 30% !!! Proto na to seru a optimizuju pouze to co je nejvíc rozhozený, případně nepřečtitelný (podpora průhlednosti PNG v IE, to je teprv dílo...).

[Petr Tomeš]

Ve svém zápalu jste také klidně mohl zmínit totéž u WebKitu...

[Filip Jirsák]

Podle té Bugzilly to stejně dělá i MSIE 8… Web se evidentně vydal tím směrem, že se prohlížeče pokusí co nejrychleji zchroustat libovolné smetí, které se k nim dostane, místo aby se tlačilo na tvůrce webů, aby psali kód pořádně.

[=^..^= AmigaPower®]

...místo aby se tlačilo na tvůrce webů, aby psali kód pořádně.

...tak to prrrrr...

...u IE můžete psát kód jak chcete podle standardů a co? A hovno! Ignorujou standardy! 6, 7 i 8!

[default]

Zkoušel jsi Microsoft® Standard™?

[default]

A když si představím, že takovejhle balast má bejt run-time pro aplikace… No, jsem rád, že dělám "jen" s databází Oracle a s Javou jen na úrovni Java SE.

[Ladicek]

Když budou tvůrci webů dělat věci pořádně, nějak to pomůže rychlosti zpracování v prohlížeči? Spekulativní parsování je něco jako spekulativní provádění instrukcí procesorem – obvykle to pomůže, a pokud se zrovna spletu, tak to holt udělám znova. A princip be strict in what you send, but generous in what you receive se zdaleka nepoužívá jenom na webu.

[Petr Tomeš]

Pan Jirsák žije v naivní představě, že v době, kdy je drtivá většina webů nevalidních a používá různé obezličky, že se od nich najednou upustí. Kdo chce, dělá weby podle standardů a ladí pro IE už dávno. Kdo nechce, nepřinutí ho ani sympatická myšlenka.

[default]

Já myslím, že jsi jen příspěvek pana Jirsáka nepochopil.

[Filip Jirsák]

Já nežiju v představě, že od toho autoři webů upustí jen tak sami od sebe – právě naopak, musí se nějak dozvědět, že něco dělají špatně. A to se mohou dozvědět třeba z rozšíření prohlížeče (Web Developer Toolbar apod.) nebo od autorů prohlížeče. Kdyby se prohlížeče přizpůsobovaly každé hlouposti, ještě se všude používá tabulkový layout a prohlížeče se předhánějí v tom, kdo rychleji rozparsuje a zobrazí deset vnořených tabulek…

[Filip Jirsák]

Ano, třeba zrovna v tomto případě zrychlí. Když uvedou u skriptu atribut defer, prohlížeč bude vědět, že ve skriptu není žádné document.write() a může klidně dál parsovat dokument a skript nahrávat na pozadí. Když tam ten atribut není, měl by to být pro prohlížeč signál, že musí s parsováním dokumentu počkat na to, až doběhne skript.

A princip be strict in what you send, but generous in what you receive se zdaleka nepoužívá jenom na webu.

On se ten princip ale na webu nepoužívá – tam se používá pouze ta druhá část.

[Ladicek]

Ne že bych něco tušil o atributu defer, ale jeho nepřítomnost znamená zákaz spekulace? Připomíná mi to Céčkové modifikátory inline nebo register – v dnešní době je překladač chytřejší než programátor, takže se může zařídit líp. Stejně tak prohlížeč má důvod pokračovat v parsování i při nepřítomnosti defer, protože s největší pravděpodobností na žádné document.write stejně nenarazí. Ten atribut je zbytečný a nedivím se, že ho nejspíš skoro nikdo nezná.

A ano, prohlížeče se typicky snaží pouze tolerovat co nejširší spektrum vstupů. To má ten důvod, že většinou žádné výstupy neprodukují Je fakt, že třeba při odesílání formulářů jsou dodnes občas problémy s kódováním a některé prohlížeče (všichni víme, o kom mluvím) tady žalostně selhávají ve striktnosti výstupů, ale to má i historické důvody. Zpětná kompatibilita byla vždycky prevít.

[Filip Jirsák]

Ne že bych něco tušil o atributu defer, ale jeho nepřítomnost znamená zákaz spekulace?

Ten atribut znamená, že příslušný skript neobsahuje žádné konstrukce, které by měnily přímo zdrojový kód stránky. Nešťastné je, že existuje pouze tato varianta, a nepřítomnost atributu znamená opak – skript zdroják mění. Lepší by bylo mít tři stavy – mění, nemění a nevím/neurčeno. Ale bylo by od autorů prohlížečů mnohem užitečnější domluvit se na nějakém „nestandardním“ atributu, který tohle bude řešit, a ne zavádět do prohlížeče vlastnost, která (byť jen s velmi malou pravděpodobností) způsobí problémy – a autor stránek ji nemůže vypnout.

Připomíná mi to Céčkové modifikátory inline nebo register – v dnešní době je překladač chytřejší než programátor, takže se může zařídit líp. Stejně tak prohlížeč má důvod pokračovat v parsování i při nepřítomnosti defer, protože s největší pravděpodobností na žádné document.write stejně nenarazí. Ten atribut je zbytečný a nedivím se, že ho nejspíš skoro nikdo nezná.

Jenže i v tom Céčku má programátor možnost kompilátoru říct, že to má být opravdu tak, jak napíše, ne? Jenže tuhle možnost u prohlížečů autor nemá. Může třeba napsat takový kód, že ve skriptu udělá document.write("<!--") a do takto vzniklého komentáře si „schová“ třeba odkazy na plná rozlišení obrázků. Kdo má vypnutý JS, ten je uvidí rovnou, kdo jej má zapnutý, tomu se natáhnou až na požádání. Jenže spekulativní parsování způsobí, že se natáhnou stejně hned. A šlo by vymyslet i horší případ, kdy nejde jenom o to, že se nějaká data tahají zbytečně, ale třeba se špatně odešlou nějaká data na server.

Kdyby těm prohlížečům alespoň bylo možné říci, že tenhle skript opravdu odložit nemůžou (nějaké no-defer). Sice by ten prohlížeč porušoval standardy, ale alespoň by se s tím dalo něco dělat. Dnes ty prohlížeče ale klidně poruší standardy, neumožní autorovi s tím nic udělat a ještě to vydávají za přednost.

A ano, prohlížeče se typicky snaží pouze tolerovat co nejširší spektrum vstupů. To má ten důvod, že většinou žádné výstupy neprodukují

Tam, kde je nějaký vstup, musí být také nějaký předchozí výstup. A tím výstupem samozřejmě není produkt prohlížeče, ale produkt autora webu – ten se stává vstupem pro prohlížeč. A tam vůbec neplatí to pravidlo být striktní v tom, co produkuju na výstupu. A prohlížeče v tomhle HTML kodéry ještě podporují, místo aby je vedly k psaní pořádného kódu. Ale řežou si tím větev sami pod sebou – tahle stále větší podpora smetí v HTML může mít jediný možný závěr.

[Ladicek]

Myslím, že tohle jsou hodně velká zvěrstva. Ano, web je plný zvěrstev

Pokud vím, dnes se píše tak, že JavaScript, který modifikuje obsah stránky, se stejně spouští až když je celá stránka zpracována. Tedy by bylo lze narvat všude defer, což je na hlavu. Nějaké no-defer, o kterém mluvíte, by se asi v extrémních případech hodilo, ale optimistická strategie zpracování mi tady přijde jako jasná volba.

Souhlasím s tím, že lidi na výstupu příliš striktní nejsou. Teda vůbec. To pravidlo se dá aplikovat jenom na programy; před nějakými desíti lety pravda ty různé FrontPage příliš rozumný kód negenerovaly, ale co jsem slyšel, dnešní nástroje jsou na tom mnohem líp. Lidský faktor, jako v Černobylu

[Filip Jirsák]

Pokud vím, dnes se píše tak, že JavaScript, který modifikuje obsah stránky, se stejně spouští až když je celá stránka zpracována. Tedy by bylo lze narvat všude defer, což je na hlavu.

Podívejte se třeba jen na reklamní kódy vkládané na Abíčku, kolikrát tam najdete document.write.

Souhlasím s tím, že lidi na výstupu příliš striktní nejsou. Teda vůbec. To pravidlo se dá aplikovat jenom na programy; před nějakými desíti lety pravda ty různé FrontPage příliš rozumný kód negenerovaly, ale co jsem slyšel, dnešní nástroje jsou na tom mnohem líp. Lidský faktor, jako v Černobylu

To je nesmyslné rozdělení – vždycky někde za tím programem je člověk. Problém je v tom, že prohlížeče se ohánějí umělými testy a předhánějí se, který prohlížeč rychleji v JavaScriptu spočítá π, místo aby do vývojářských nástrojů prohlížeče doplnili vedle „Validate HTML“ také „Validate JavaScript“ a podobné věci.

[Ladicek]

Jo, znám jeden reklamní systém, který myslím generuje document.write, který generuje document.write Je to hnůj. Ale taky je to ten poslední JavaScript, na kterém závisí správné fungování stránky (teda když si odmyslím, jak pomalu se to někdy natahuje ). Reklama vkládaná do stránky má obvykle předem známé rozměry, takže se s tím dá pracovat.

Souhlasím s nesmyslností javascriptových benchmarků, a protože mám něco do činění s jednou aplikací napsanou v GWT, vím dobře, že ta manipulace s DOMem, kterou jste zmiňoval výše (nebo to byl někdo jiný?), je ve výsledku mnohem důležitější. Ale právě do této oblasti optimalizací spekulativní parsování patří.

Že jsou vývojářské nástroje pro web na těžce nedostatečné úrovni, s tím nemůžu než souhlasit. Ale řekl bych, že tvůrci prohlížečů si to uvědomují – aspoň na loňském DevDayi chlapci z Googlu jasně řekli, že komfort při psaní desktopové aplikace je o poznání vyšší než při psaní aplikace webové. Já osobně taky považuji web jako aplikační platformu za bestii triumphans, ale to vítězství je v duchu unixové tradice worse is better už teď nepochybné.

[Petr Tomeš]

Bug 364315 – Speculatively load referenced files while "real" parsing is blocked on a <script src=> load

[Lukáš Zapletal]

Díky za recenzi.

Jen poznámka k té paměti: ...zabíral 18 MB a s rostoucím počtem panelů se neměnil. To je trošku zavádějící, prázdné panely samozřejmě nezaberou téměř nic, složité stránky plné obrázků a jiných věcí pochopitelně už nějakou tu paměť zaberou. A rozhodně to nebude 18 MB + 1 MB, ale 18 MB + desítky až stovky

[Fluttershy, yay!]

Pardon, blbě jsem to napsal: samozřejmě se obsazení paměti měnilo, ale neměnil se rozdíl mezi FF 3.0 a 3.5.

[pj]

je vice nez zrejme, ze vyvoj ztraci dech

[Petr Tomeš]

Je více než zřejmé, že je tomu právě naopak.

 

[Fluttershy, yay!]

Zvyšování výkonu (hlavně JavaScriptu), nasazování podpory pro HTML 5, CSS 3 a přidávání záležitostí pro DOM, kopírování novinek v Google Chrome... ještě něco?

[Petr Tomeš]

Ano.

[Martin]

Co třeba zařídit, aby FF každý den nespadnul

nebo aby v youtube nezatěžovala 4 vide 2GHz CPU na 100%...

 

 

možná by to lidi přivítali víc než nový inteligentní hovnocuc

[Andrej Herceg]

S tým flash sa budeš musieť obrátiť na Adobe. ;)

[cezz]

Tu mi neda nenapisat vlastnu skusenost. FF mi bezi vkuse aj niekolko tyzdnov (normalneho pouzivania), medzitym (z principu akym Mac OS X aplikacie zvyknu fungovat) FF nevypinam a browser nepada. Urcite nie kazdy den. A ak aj padne, vzdy na stranke, ktora vo velkom pouziva flash - kazdoapdne naozaj vynimocne raz za dva-tri tyzdne.. Cize mozno skus pozriet smerom k adobe. (vypni na chvilu plugin, ako sa zmeni stabilita) 

[Grunt]

Co třeba zařídit, aby FF každý den nespadnul

A co třeba si zjistit souvislost mezi knihovnou libflashplayer.so a prohlížečem?

nebo aby v youtube nezatěžovala 4 vide 2GHz CPU na 100%...

Jednoduchá rada: Nepouštěj současně vide čtyři, ale jen jedno.

[Zdeněk Štěpánek]

Tam zas nekdo premejslel kolenem, proc jsou probuh ty moznosti pro vymazani historie ve skrollovacim okynku....

[pushkin]

Příloha:

• ff.png (51857 bytů)

+1

Osobně mi připadá, že Firefox 3.5 nemá nárok ani na číslo verze 3.1. V nastavení není problém ukládání čehokoliv zakázat už teď. Obnova relace - vlastnost, kterou ná Opera od verze 6 (možná ještě dříve, ale to jsem ji ještě nepoužíval). Procházení odkazů ze zrojového kódu je pak vyloženě významná vlastnost pro změnu číslování o 0.4.

[Vláďa]

A co třeba integrovaná podpora přehrávání videa a audia v Ogg Theora/Vorbis? A co zcela nový JavaScript engine výrazně zvyšující rychlost? To jsou podle mě celkem zásadní vlastnosti.

[Petr Tomeš]

Přesně tak, novinek je hodně a z hlediska číslování i objemu jsou přinejmenším srovnatelné s konkurenčními prohlížeči (IE, Opera, Chrome...).

[Jirka]

To jakože mám kvůli "porno módu" neustále měnit nastavení? No ták.

Mně se FF 3.5 líbí. Rychlejší interpret JS je dneska třeba jako sůl a jak jsem pochopil, tak jde o nový kód, takže 3.5 chápu. Jo kdyby to bylo rovnou o major verzi, tak bych s tím měl asi problém, ale tohle je vyloženě dělání bouře ve sklenici vody.

[Filip Jirsák]

Rychlejší interpret JS je dneska třeba jako sůl

Není. Pro AJAXové obludy je potřeba rychlá manipulace s DOMem, samotný interpret JavaScriptu není to nejkritičtější místo. Jistě, každé zrychlení dobré, ale interpret JS dnes není to hlavní.

[Petr Tomeš]

To je moc dobře, že jste to zmínil. Každý může přesvědčit, že Firefox/Gecko manipuluje s DOMem nejrychleji.

[Jirka]

Proc tedy zrovna v clanku zmineny test DOMu zadne zrychleni oproti 3.0 neprinesl?

[Petr Tomeš]

Protože to není moc spolehlivý a komplexní test jako ten, který jsem právě odkázal.

[Jirka]

A podle ceho se to pozna?

Vuci tomu odkazovanemu mam metodologicke vyhrady... Vubec nezohlednuje, ktera z testovanych operacich se provadeji hodne casto a ktera velmi zridka.

[Petr Tomeš]

Tak je tam podrobně rozepsané, co se přesně testuje, a lze to snadno porovnat s jinými prohlížeči nebo jinými verzemi téhož prohlížeče. Metodika je známka. Tvůrci Dromaeo postupně vylepšují a jsou otevření připomínkám. Celtic testy jsou zkostnatělé a žádná spolupráce ani vývoj tam neprobíhají už léta.

Další čtení:

http://ejohn.org/blog/javascript-benchmark-quality/

http://ejohn.org/blog/accuracy-of-javascript-time/

http://ejohn.org/blog/element-traversal-api/

[Integral]

vazne? neni nahodou cely (nebo velka cast) firefox napsan v jazyce XUL+JS?

[Marek Bernát]

Hm, celý nie. V prvom rade totiž treba interpreter pre ten XUL + JS jazyk a ten asi niekto musel najprv napísať v C/C++. Ale veľká časť určite, zvlášť ak niekto používa dosť rozšírení.

[Integral]

jasne. interpret je urcite v necem jinem, i xpcom komponenty, ktere se ve ff hojne pouzivaji jsou snad psany v necem jinem. ja jsem spis reagoval na komentar, ze interpret js neni kriticke misto, protoze si myslim, ze je :)

[Filip Jirsák]

Jenže i tam nejvíc zdržuje manipulace s DOMem. Když tam máte deset příkazů – různé podmínky, přiřazení a výpočty – a na jedenáctém řádku se výsledek toho kódu má promítnout do DOMu, a například vložit nějaký element, bude ta jedenáctá operace trvat třeba 100× dýl, než těch předchozích deset dohromady. Takže zrychlit těch prvních deset operací o 50 % je ve výsledku takřka k ničemu.

[Grunt]

FireFox je v tom repositáři na co?

[Grunt]

Ach jo. FireFox 3.6 jsem chtěl napsat.

[Grunt]

Přílohy:

• Basics.png (12840 bytů)
• Minor Tweaks.png (13055 bytů)
• Under the Hood.png (17928 bytů)

Sakra, nevím co s FF3.6 udělali, ale při načítání stránek to švihá pomalu stejně rychle jako Chromium.

Příloha - Taková menší blbost, které jsem si všiml u dnešního Buildu Chromia. Dodělali stabilní verzi Chrome pod Windows, tak se asi plně začali věnovat důležitým věcem u Chromiu pod Linuxem.

[Petr Tomeš]

Podle mých testů před půl měsícem byla rychlost Firefoxu 3.6 většinou rychlejší jen v řádů jednotek procent. Dělal jsi benchmark nebo je to pocit z reálného prohlížení stránek? Kdyžtak budu muset zkusit znovu.

[Grunt]

Prostě napíšu adresu, buch do ENTERu a stránka okamžitě bez čekání naskočí stejně tak jak je tomu v Chromiu. Mám tu k dispozici ještě distribuční Epiphany slinkované se starým xulrunnerem a je to viditelný rozdíl. Pro jistotu zkusím přeložit Epiphany s tou novou (beta)verzí xulrunneru.

[Petr Tomeš]

Mně ty stránky naskočí skoro okamžitě už i ve Firefoxu 3 a ve Firefoxu 3.5 je to většinou jen malý zlomek sekundy.

[Vin]

Srovnáváš na Windows nebo na Linuxu?

[Petr Tomeš]

Windows. Vím, že u Linuxu to bylo trochu pomalejší, takže pokud se to zrychlilo i tam, tak je to dobře,

[miso]

 

pomalu stejně rychle

 

 

[Grunt]

Funguje někomu video tag ve FF?

[Andrej Herceg]

Skúšal som odkazy, ktoré sú na tejto stránke a fungujú mi.

[Grunt]

Sakra, proč já vždycky musím dostat ten rozbitý?

[Petr Tomeš]

Oznam chybu.

[Andrej Herceg]

Skúšal si aj najnovšiu verziu z ich ftp (tú som skúšal pred chvíľkou a aj tá mi funguje)?

[Grunt]

Už(moje chyba). Ježiš, první video ve video tagu a taková kravina. Co to v tom Novellu fetují za zelené svinstvo? Jinak je ten tag úplná paráda a absolutně jsem to nečekal. Už to jenom dostat na YouTube.

[xsubway]

já to taky nečekal ... ten tag je tak jednoduchý .. a to video tak ... no škoda, že v něm nehraje Ernie a Bert ... a že ten linux je v tom klipu takový, nó ... gumový

[bob]

Tu je na tom IE a Opera lepsie:

www.w3schools.com/tags/att_col_align.asp

[Petr Tomeš]

Chtěl bych upozornit i na vylepšování kvality Theora kodeku.

[Grunt]

Zatím prosímtě na nic neupozorňuj. Aspoň do té doby než to opraví.

[Grunt]

Přílohy:

• 883-theora.png (635957 bytů)
• 883-thusnelda.png (579234 bytů)
• 2347-theora.png (459845 bytů)
• 2347-thusnelda.png (383813 bytů)
• 2449-theora.png (526465 bytů)
• 2449-thusnelda.png (646396 bytů)

Ještě ať nejsem obviněn že porovnávám dva různé kodeky tak dodávám pár obrázků Theory 1.0 a aktuální revize Thusneldy z SVN.

[Petr Tomeš]

Takže chceš popřít, že v tom článku nejsou popsána vylepšení a další vývoj? To si to jako vymyslely z prstu? Určitě tam nějaká vylepšení jsou, někde třeba zase moc ne, ale já spíš upozorňoval na to, že současný stav určitě nezůstane napořád...

 

[Grunt]

Přílohy:

• 1520-theora.png (160014 bytů)
• 1520-thusnelda.png (179625 bytů)
• 2190-theora.png (283996 bytů)
• 2190-thusnelda.png (302148 bytů)

Takže chceš popřít, že v tom článku nejsou popsána vylepšení a další vývoj?

Ne, ne. To samozřejmě ne. V klidných částech je obraz nepopřetelně ostřejší(viz. příloha). Dokonce jsem stejný trailer přibližně ve stejném čase jako mají na obrazcích zkoušel a můžu to jen potvrdit. Jen říkám, že vše není jen černé a bílé. Prostě takové to freshmousovské rýpnutí. Prostě není dobré na to upozorňovat v tuto dobu, protože by se toho mohl nějaký trol chytnout. Ono přímé porovnávání také není nic moc, protože já beru jen čistě nijak neoptimalizovanou Thusneldu, která se dá ladit velkou spoustou parametrů(viz. Matrixovskou sérii) a ještě v ní není implementováno dost funkcionality.

současný stav určitě nezůstane napořád...

Určitě ne. Náprava byla přislíbena. SVN se hýbe každý den.

[Grunt]

Ale ať nežeru:

Theora:
BENCHMARKs: VC:  61.828s VO:   0.024s A:   0.000s Sys:   1.674s =   63.527s
BENCHMARK%: VC: 97.3269% VO:  0.0382% A:  0.0000% Sys:  2.6349% = 100.0000%

Thusnelda:
BENCHMARKs: VC:  53.300s VO:   0.022s A:   0.000s Sys:   1.600s =   54.922s
BENCHMARK%: VC: 97.0475% VO:  0.0396% A:  0.0000% Sys:  2.9130% = 100.0000%

U kódování je rozdíl ještě patrnější.

[Petr Tomeš]

Nějak těm číslům nerozumím.

[Grunt]

Znamená to, že video o délce 150.48 sekund to přehraje za 61 sekund u Theory a 53 sekund u Thusneldy při zatížení procesoru na 100% o 800Mhz na jednom jádře. Tedy u toho vzorku zrychlení o 14%. Zatím nic moc ale je slíbeno zrychlení 1.5x - 4x. Už tak je Theora bezkonkurenčně nejrychlejší kodek(pro srovnán třeba H.264 je jednou tak pomalejší, o ostatních radši ani nemluvím) a pokud se jim to podaří ještě zrychlit… Už bude scházet jenom implementace pro počítání s celými čísly(Vorbis už jednu takovou má) a budu si moct pouštět full HD videa na digitálních hodinkách a nebo na mikrovlnce.

Ještě časy enkódování:

Theora:
real    37m54.701s
user    35m41.386s
sys     0m7.468s

Thusnelda:
real    31m7.201s
user    28m55.748s
sys     0m7.572s

[Petr Tomeš]

Děkuju za vysvětlení.

[petr_p]

Kde se z toho vašeho výpisu pozná, že video má délku 150,48 s?

[Grunt]

nikde. Důležitý je prostě rozdíl 61.828s a 53.300s.