Vlákno názorů k článku
Microsoft, Google a Mozilla budou spolupracovat na ladění kompatibility prohlížečů od martinpoljak - Jakožto webový vývojář mohu sice konstatovat, že je...

Jakožto webový vývojář mohu sice konstatovat, že je to fajn, ale ještě víc fajn by bylo, kdyby tihle tři donutili ke spolupráci Apple. Protože hlavní problém je Safari.

Jak se to ale rychle změnilo, že? Nejdřív to byl Internet Explorer, pak ještě ve dvojici s Edge, a najednou prakticky během pár měsíců přešel Černý Petr k Safari. Kdo by to byl před pár lety řekl – zvlášť když Safari je vlastně otec Chrome a Edge. Ale prostě se aktualizuje pomalu…

Vlastně je to ale velká pochvala pro Firefox (Gecko). Protože Safari, Chrome (a Edge) vychází ze stejného základu, přesto se Gecko mezi ně dokáže vklínit, že je sice, horší než Blink, ale lepší než WebKit.

A otcem Safari je KDE, resp. jeho technologie KHTML a KJS.

Ano, ale to se naštěstí téhle soutěže už neúčastní, proto jsem o něm nepsal. Jinak by měl IE „pokořitele“ ještě v době před svou klinickou smrtí.

Tak Webkit je fork KHTML a Blink je fork Webkit.

Gecko je možná lepší než WEBKIT, ale na tom sejde, když je úděsně pomalej při dlouhodobém využívání (má potřebu pořád hrabat do cache a tam mu to trvá) tím ovšem Webkit zase nažene...

Díváte se na to z pohledu uživatele. Z pohledu vývojáře musím nefunkčnost ve WebKitu řešit, že je prohlížeč uživatele pomalý při dlouhodobém využívání mne jako vývojáře netrápí.

Reálně je Safari opravdu problém. Ještě ani ne tak na macOS, tam se dají lidé směřovat na Chrome/ Firefox apod. ale na iOS si člověk nevybere.

Upřímně ale v OrgPadu i trochu kvůli tomu co děláme v podstatě implementujeme skoro všechno, co by mohl dělat browser znova a to, co browser už dělá, musíme často opravovat, protože ani to nefunguje často zcela správně. Tuhle třeba kombinace ReactJS + Chrome, když změníme class, tak na chvilku prvek zmizí z DOM, takže se vyvolá onmouseover/ onmouseout a další podobné eventy i když to není záměr. Ve Firefoxu to funguje správně, v Safari jsou jiné chyby, protože tam se zase CSS transformace chovají jinak. No je to prostě peklo.

Nakonec tedy řešíme v celé aplikaci třeba myš kompletně sami a počítáme, nad jakým prvkem zrovna je. To znamená v podstatě počítat věci jako z-height a zohlednit tak větší prvek apod.

Jinak včera jsme v OrgPadu dali ven fyzikální animace (pružiny) pomocí výpočtů diferenciálních rovnic v JS a nasypání do keyframů v CSS transformaci. Zatím je tohle aktivní na https://orgpad.com/list nad náhledy OrgStránek. Je to o hodně rychlejší (v tomto případě to není až tak relevantní, ale jinde to bude podstatné) než simulace v React Motion, protože to nejen jde kolem velkých částí Reactu, ale CSS ještě potom řeší browser efektivněji. Postupně se React Motion úplně zbavíme, ale pár dní to ještě bude trvat.

Jak jsem psal dříve, ty fyzikální animace mohly být v CSS + nějaké rozumné API na ovládání těchto animací/ časování a knihovny jako React Motion by byly +- nepotřebné. Takhle jsou na většině webu, Androidu apod. animace buď ošklivé protože nepůsobí přirozeně nebo pomalé, protože se počítají neefektivně simulací a promítají neefektivně do prohlížeče.

Eh, on se na iOS nedá nainstalovat jiný browser, než integrovaný Safari? Je to pak vlastně ještě smartphone?

Dá, ale ten prohlížeč musí používat systémové jádro Safari.