Vlákno názorů k článku
DoS zranitelnost prohlížeče Chrome a všech derivátů od radekm - To jen ukazuje, jak jsou technologie kolem webu...

Pokud za změnu specifikace považujete to, že se pro formátování klíčového slova ve specifikaci použije místo elementu var element i, pak se skutečně specifikace mění takto často.

Akorát že to nijak nesouvisí s implementací v prohlížečích.

Občas se to mění tak, že se specifikace změní podle skutečné implementace.
To je záměr. Aby specifikace nebyla teorie odtržená od reality, ale aby to bylo ve specifikaci popsané tak přesně, že každá další implementace se bude chovat stejně. Dokonce je požadováno, aby to bylo v široce používaném prohlížeči implementováno dřív, než dojde ke schválení specifikace.

> Pokud za změnu specifikace považujete to, že se pro formátování klíčového slova ve specifikaci použije místo elementu var element i, pak se skutečně specifikace mění takto často.

To ani nemusím. I bez těch "Editorial: Fix markup + wording" commitů se mění takhle často. Za poslední týden se změnila 31. října, 29. října a 28. října. A pokaždé to byly změny, co s implementací souvisí, protože mění nebo upřesňují chování.

> To je záměr. Aby specifikace nebyla teorie odtržená od reality, ale aby to bylo ve specifikaci popsané tak přesně, že každá další implementace se bude chovat stejně. Dokonce je požadováno, aby to bylo v široce používaném prohlížeči implementováno dřív, než dojde ke schválení specifikace.

To je možné, ale pak se to mění tak, že nové chování není zpětně kompatibilní se starým. Třeba se stane, že Firefox a Safari to naimplementují podle specifikace, Chrome nikoliv, ale pak se specifikace změní podle Chrome, takže nakonec to mají blbě minoritní prohlížeče.

A pokaždé to byly změny, co s implementací souvisí, protože mění nebo upřesňují chování.
Kdybyste se na ty commity podíval, jedno je změna formátování, jedno je upřesnění (které nesouvisí s implementací) a jenom jedno je upřesnění, které by se čistě teoreticky mohlo v implementaci projevit.

Třeba se stane, že Firefox a Safari to naimplementují podle specifikace, Chrome nikoliv, ale pak se specifikace změní podle Chrome, takže nakonec to mají blbě minoritní prohlížeče.
Abych vám to věřil, chtěl bych vidět příklad takového „třeba se stane“.

To by nebylo moc praktické, zahodit všechny současné weby i s tím, že obsah je přístupný i pro jiné formy konzumace, než je zobrazení, a nahradit to vykreslováním přes WebGPU. Takové pokusy už tu byly třeba s Flashem a všichni jsou rádi, že to zaniklo.

> To by nebylo moc praktické, zahodit všechny současné weby i s tím, že obsah je přístupný i pro jiné formy konzumace, než je zobrazení, a nahradit to vykreslováním přes WebGPU.

Já bych to nezahodil úplně - aplikace by to mohly normálně používat, akorát by to nebylo přímo v prohlížeči ale třeba v nějaké JS nebo WebAssembly knihovně. Tím by se značně zjednodušila implementace prohlížeče a aplikace by mohla říct, jakou verzi očekává, takže by se s updatem prohlížeče nemusely rozbít stránky, které dříve fungovaly. Nebo naopak, nové CSS vlasnosti by mohly fungovat napříč prohlížeči a ne jenom v Google Chrome, který je implementoval jako jediný.

Já bych to nezahodil úplně - aplikace by to mohly normálně používat, akorát by to nebylo přímo v prohlížeči ale třeba v nějaké JS nebo WebAssembly knihovně.
Takže věci, které se optimalizují až na dřeň, by se nově implementovaly v JavaScriptu nebo WebAssembly, aby se to pořádně zpomalilo a zabíralo ještě víc paměti.

Tím by se značně zjednodušila implementace prohlížeče
Akorát byste to, co je složité na implementaci prohlížeče, přesunul do implementace toho JavaScriptu.

takže by se s updatem prohlížeče nemusely rozbít stránky, které dříve fungovaly.
Což se reálně neděje ani teď, takže je zbytečné to řešit.

Nebo naopak, nové CSS vlasnosti by mohly fungovat napříč prohlížeči a ne jenom v Google Chrome, který je implementoval jako jediný.
Podle mne je důležité, že existuje víc vykreslovacích jader prohlížečů – a bylo by lepší, kdyby Blink dominoval méně.

Implementovat jedno vykreslovací jádro, které by používali všichni, a ještě v JavaScriptu, by byla pozoruhodná kombinace několika naprosto nesouvisejících špatných rozhodnutí. Můžu si taky něco přihodit? Já bych doporučil, aby takové jádro mělo dokumentaci a názvy proměnných, funkcí a objektů v Katalánštině.

> Takže věci, které se optimalizují až na dřeň, by se nově implementovaly v JavaScriptu nebo WebAssembly, aby se to pořádně zpomalilo a zabíralo ještě víc paměti.

To nemusí být pravda. Tím, že by ten kód byl v aplikaci, tak by se mohl lépe specializovat pro konkrétní aplikaci.

> Což se reálně neděje ani teď, takže je zbytečné to řešit.

To se děje, protože se nedrží zpětná kompatibilita.

> Akorát byste to, co je složité na implementaci prohlížeče, přesunul do implementace toho JavaScriptu.

Nebo WebAssembly. Tím by ubylo bezpečnostních problémů a nekompatibilit.

Tím, že by ten kód byl v aplikaci, tak by se mohl lépe specializovat pro konkrétní aplikaci.
Takže by dokonce každá webová stránka měla své vlastní vykreslovací jádro prohlížeče napsané v JavaScriptu. Už předchozí váš komentář byl hodně dada, ale vidím, že jste se ještě překonal.

To se děje, protože se nedrží zpětná kompatibilita.
Nesmysl. Jestli jste něco takového zaslechl od webových vývojářů, tak se bavili o době před dvaceti lety. A nešlo o zpětnou komaptibilitu.

Nebo WebAssembly. Tím by ubylo bezpečnostních problémů a nekompatibilit.
Budu optimista a budu předpokládat, že ten úbytek bezpečnostních problémů by byl po přepisu vykreslovacího jádra z C/C++/Rustu do JavaScriptu/We­bAssembly. A ne že by ze bezpečnostní problémy a nekompatibility zlepšily přechodem z JavaScriptu na WebAssembly.

Každopádně třeba takové Servo se vyvíjí už několik let, a pořád z toho není kompletně hotové vykreslovací jádro prohlížeče. A vy byste chtěl vytvořit úplně nové jádro webového prohlížeče, a to ještě pro platformu WebAssembly. Jak dlouho by to asi trvalo?

Navíc nekompatibilita vykreslovacích jader je váš virtuální problém. V praxi takový problém neexistuje. Co se řeší v praxi je nepodpora nebo částečná podpora různých Web API. Nejblíž tomu vašemu virtuálnímu světu by byla chybějící podpora některých CSS funkcionalit, to je to jediné, co by to vaše nové vykreslovací teoreticky mohlo řešit. Akorát že to málokdy opravdu vadí, obvykle to znamená jen to, že v nepodporovaném prohlížeči je něco o něco ošklivější.

> Nesmysl. Jestli jste něco takového zaslechl od webových vývojářů, tak se bavili o době před dvaceti lety. A nešlo o zpětnou komaptibilitu.

Haha. Děje se to dost často, protože ta specifikace se mění často. Už i upřesnění může znamenat ztrátu zpětné kompatibility. Příkladů za pár posledních let je hromada - třeba Chrome odebral Mutation events, nebo vlastnosti selectionStart a selectionEnd přestaly existovat na některých inputech.

> Budu optimista a budu předpokládat, že ten úbytek bezpečnostních problémů by byl po přepisu vykreslovacího jádra z C/C++/Rustu do JavaScriptu/We­bAssembly. A ne že by ze bezpečnostní problémy a nekompatibility zlepšily přechodem z JavaScriptu na WebAssembly.

O přepis vůbec nejde. Jde o to, že by to běželo v sandboxu na úrovni aplikace. Teď to běží na úrovni prohlížeče.

> A vy byste chtěl vytvořit úplně nové jádro webového prohlížeče, a to ještě pro platformu WebAssembly.

Neřekl jsem úplně nové. Stačí upravit existující, aby používalo WebGPU API (+ nějaké API pro přístupnost) a přeložit ho pomocí Emscripten.

vlastnosti selectionStart a selectionEnd přestaly existovat na některých inputech
Ve které verzi specifikace byly na více inputech, než dnes?

Stačí upravit existující, aby používalo WebGPU API (+ nějaké API pro přístupnost) a přeložit ho pomocí Emscripten.
:-D

> Ve které verzi specifikace byly na více inputech, než dnes?

Určitě to bylo méně než 20 let, o kterých jste mluvil. Tipl bych tak 15.

Jestli to bylo v nějakém draftu v roce 2010, tak je to celkem jedno, protože specifikace HTML5 byla vydána až v roce 2014.

Takže věci, které se optimalizují až na dřeň, by se nově implementovaly v JavaScriptu nebo WebAssembly, aby se to pořádně zpomalilo a zabíralo ještě víc paměti.
Byl bych mnohem radši, kdyby nebyly tak optimalisované - třeba by vedlo k jejich méně častému používání.
Vyloženě mi vadí, že k zobrazení informací ve stylu text a obrázky občas potřebuji vysoce optimalisované knihovny pro přehrávání videa, zvuky, složité efekty, apod.

Překrývající věci jsou zpravidla kvůli zpětné kompatibilitě – s novým API lze dělat víc, než se starým, ale to staré zůstane kvůli zpětné kompatibilitě. Menší API se stejnou funkcionalitou by vůbec ničemu nepomohlo.

To máte pravdu. Teď už je to tak složité, že už to nikdo správně nenaimplementuje. Je potřeba to celé zahodit a začít znovu. S tím, že ty původní aplikace by nad novým API mohly běžet tím způsobem, co jsem popsal.

Navíc hodně aplikací vlastně vůbec nezajímá přímo HTML nebo DOM - používají nějakou knihovnu (třeba React), která to nějak použije za ně. Tudíž těmto lidem by bylo jedno, zda ten React bude pracovat s DOMem nebo s něčím efektivnějším.

Pořád vymýšlíte, jak něco úplně předělat, ale proč byste to předělával? Co byste tím získal?

Jednodušší implementaci - prohlížeč by dokázal implementovat tým pár lidí, možná dokonce jeden člověk. Možná by pak mohlo existovat více prohlížečů s různými jádry. A věřím, že i lepší bezpečnost a vyšší spolehlivost.

Vždyť by nad tím pořád musela existovat ta vrstva emulující HTML a DOM. To by nebylo na implementaci jednodušší, nýbrž složitější.

HTML a DOM by mohly být nezávislé na prohlížeči. Některé aplikace, třeba ty v Reactu, by je ani nepotřebovaly - mohly by přímo krmit layout engine (který by také mohl být nezávislý na prohlížeči).

Jako že by SDL3 mohlo nahradit browser API?

Toto je prostě hodně naivní porovnání, sorry.

> Toto je prostě hodně naivní porovnání, sorry.

A existuje i nějaký argument proč?

A existuje i nějaký argument proč?
Ty argumenty vyžadují alespoň vzdáleně tušit co je web, co prohlížeč dělá, jaká poskytuje API, jak se takový prohlížeč programuje. Když tohle netušíte, ty argumenty nevidíte – i když už tady v diskusi zazněly.

1. 11. 2025, 19:55 editováno autorem komentáře

A proč byste to, co dělá prohlížeč, nemohl udělat přes API SDL3? Co vám tam chybí?

Mohl, teoreticky. Ale nic dobrého by to nepřineslo, jenom obrovské náklady a komplikace.

A proč byste to, co dělá prohlížeč, nemohl udělat přes API SDL3? Co vám tam chybí?

To je pokus o vtip? Vždyť SDL3 neumí ani vykreslit text...

Dál už bych nechtěl pokračovat. Toto je úplně nesmyslná diskuze.

> To je pokus o vtip? Vždyť SDL3 neumí ani vykreslit text...

To přeci nemusí být součást prohlížeče - může to být na úrovni Reactu apod. Point je, že to nad SDL 3 API snadno implementujete. A výše jsem i popsal jak.

může to být na úrovni Reactu
React ovšem pracuje s DOMem.

Point je, že to nad SDL 3 API snadno implementujete.
To, co ovšem stále nechápete, je to, že nad SDL 3 API se snadno implementuje drobná část vykreslovacího jádra prohlížeče, kterou už ovšem mají prohlížeče dávno vyřešenou. Takže přepisem byste vůbec nic nezískal.

> To, co ovšem stále nechápete, je to, že nad SDL 3 API se snadno implementuje drobná část vykreslovacího jádra prohlížeče, kterou už ovšem mají prohlížeče dávno vyřešenou. Takže přepisem byste vůbec nic nezískal.

Já bych tam implementoval prakticky všechno - od parsování HTML, CSS, přes DOM a layout engine až po vykreslování. To znamená velkou část. A získal bych menší prohlížeč, kde je menší prostor pro bezpečnostní chyby a je jednodušší jej implementovat.

Krom toho to vyřešené stále nemají, protože jsou v tom stále chyby nebo se to stále mění.

Nezískal byste menší prohlížeč, který je jednodušší implementovat. Tím, že napíšete nový prohlížeč s pomocí jiné technologie, nedocílíte toho, že by byl prohlížeč menší nebo jednodušší na implementaci.

Chyby jsou ve všem a mění se to tak, že se přidávají nové funkce – protože je po nich poptávka. Z prohlížečů se holt stal systém pro spouštění aplikací, takže je poptávka po rozšiřování funkcionality pro ty aplikace.

> Z prohlížečů se holt stal systém pro spouštění aplikací, takže je poptávka po rozšiřování funkcionality pro ty aplikace.

Ano, souhlasím. Klasické HTML pak může být jedna z těch aplikací, už nemusí být součástí prohlížeče. Konkrétně třeba u Chrome by se mohl odstranit celý Blink a Skia - čímž by se Chrome zjednodušil a zmenšil o několik milionů řádků kódu.

Navíc Skia pro WebAssembly už existuje, teď se přepisuje pro WebGPU - pro použití ve Flutteru, který by běžel v prohlížeči. Takže část té práce je už hotová.

Tím, že kód přesunete jinam, se nezmenší a nezjednoduší.