Názory k článku
Chrome / Chromium 103 přináší API Local Font Access
-
BuldrZlatý podporovatelNaštěstí stále existuje možnost volby a tedy doufat, že Brave, Vivaldi ... nic podobného nepřevezme.
-
Aky to ma realny vynam? Pre ake aplikacie je to urcene? Pisu ze:
Font enumeration helps:
Improving styling options for user-generated content.
Matching fonts declared by existing content.Okrem spomenuteho, si viem si predstavit ze aplikacie typu Google Docs budu pristupovat k lokalnym fontom, aj ked by som ten dokument radsej nikomu neposielal.
Mi to pride take nejake zbytocne cele. Ci? Nechajme bokom teorie o tom, ze potrebuju dalsi nastroj ako sledovat uzivatelov, tych maju aj teraz dostatok.
-
No, nevím - proč by měl prohlížeč lustrovat moje nedodělané obskurní soukromé fonty? To snad ani vůbec nechci...
A obsah stránky se má načítat "postupně podle potřeby", ne, aby to nejdřív čekalo na načtení stránek či vykonání nějakého scriptu - vždyť pak reálně hrozí, že nepůjde-li nějaký inicializační script (třeba že je zablokovaný, na blacklistu na proxy, atd...), nenačte se ta stránka vůbec.Čili se ptám: dá se to někde v nastavení vypnout?
-
L.Stříbrný podporovatel
To font API je evidentně pro webové aplikace, co nějak víc pracují s textem, píšou tam i, že to poskytuje přístup přímo ke tabulce znaků toho fontu, což předtím nešlo. Nebude to asi nic extra používaného. A vyžaduje to povolení uživatele, takže pokud se za svoje fonty stydíš, tak mu ho prostě nedáš.
No a s tou 103 jsi to špatně pochopil, to je způsob, jak dát prohlížeči napřed (na začátku zpracování requestu) vědět (některé) resources, které stránka bude potřebovat, aby si je mohl začít natahovat do cache a stránka se pak zobrazila rychleji.
-
msmucrBronzový podporovatel
Neviděl bych to s tím novým font API tak paranoidně. Výchozí nastavení v Chrome 103 je takové, že když si to konkrétní web vyžádá, tak se to normálně zeptá. Jako třeba u přístupu k lokáním souborům nebo audio zařízení.
Hlavní použití bude podle mě pro webové aplikace, co slouží třeba pro výrobu nějaké grafiky, diagramů, mockupů... Jako je třeba teď Photopea, Vectr, Figma atp.
Tam by s tím teď mohla přibýt možnost použít uživatelské fonty rovnou z počítače, aniž by se předtím musely nahrávat do cloudových úložišť. -
L.Stříbrný podporovatel
A není lepší do toho klienta dodělat korektní handling 1xx odpovědí, než dodělávat nějaký header na vypnutí?
-
Ako koncept sa mi tie lokálne fonty páčia. Mal som jeden čas na pihole vyblokované google fonts a kto neskúsil, nezažije koľko stránok sa na ne spolieha - google fonts nie sú len písmenká. Sú to často šípky, ikonky v menu, stavové indikátory, veci, ktoré vo fallback fonte, ktorý browser má neexistujú. Keďže predpokladám, že google svoje fonty používa podobne ako FB svoje pixely, ďakujem neprosím.
Keby bola možnosť si tieto fonty doinštalovať lokálne a tak ich využívať, podľa možnosti nejak bezpečne a súkromne, bolo by to fajn. Verím, že dobrý prehliadač by vedel ten fingerprinting nejak obmedzovať, robia to už aj teraz. -
Filip JirsákStříbrný podporovatelHTTP/2 PUSH se zavrhlo, že to prý prohlížeče neumí používat. Tak se vymyslí HTTP status 103, který se má použít k tomu samému, jako PUSH, akorát je to podstatně omezenější. Zdá se, že tady jde vývoj také po spirále, akorát s každou otáčkou je to horší a horší.
-
L.Stříbrný podporovatel
Ano, to je zdroj dokazující, že nemáš pravdu. Díky ;-)
Abych to rozebral:
1) HTTP PUSH nebyl zavržen proto, že by ho prohlížeče "neuměly používat". Oni to uměly. Neuměly ho používat servery / uživatelé. (Část "Motivation" krom posledního odstavce.)
2) Druhým argumentem bylo, že jeho implementace v prohlížeči je poměrně komplikovaná a nákladní na údržbu, což je u nepoužívané featury docela nepříjemné. (Poslední odstavec části "Motivation")
3) V tom postu autor doporučuje jako lepší řešení používat <link rel="preload" />.Tedy přesně to, co dělají ty Early hints a o čem ty tvrdíš, že je to horší. (Část "Alternative implementation suggestion for web developers")
-
Filip JirsákStříbrný podporovatel
Chrome HTTP PUSH neumí používat, údajně z důvodu, že je to implementačně náročné a nákladné na údržbu. Chrome je prohlížeč. Jestli by to servery používaly správně nebylo možné zjistit, protože to Chrome zařízl dřív, než by mohly vzniknout implementace v serverových aplikacích. Ono totiž nemá smysl implementovat to dřív, než to podporují prohlížeče. Pak se to začne používat experimentálně v malých instalacích – a pak už to Chrome zařízl.
<link rel="preload" /> je horší řešení, protože funguje jenom pro HTML; čeká se do doby, než se příslušná část rozparsuje; server musí modifikovat HTML, když to chce použít; lze to použít pouze na začátku stránky; nelze poslat další informace, na základě kterých by se prohlížeč rozhodl, zda zdroj potřebuje; nelze jednotlivé požadavky prioritizovat. Early hints řeší první tři body, ale neřeší zbytek. Hlavní problém je v tom, že řízení přenosu se ze serveru přenáší na klienta, který ale vůbec netuší, která data má server k dispozici a může je posílat. Takže server čeká na data z databáze a mohl by mezi tím začít posílat styly, ale prohlížeč rozhodne, že je lepší nestahovat nic, počkat si na HTML a teprve pak začít posílat styly. Pak server dostane data z databáze a mohl by začít posílat HTML, ale prohlížeč se rozhodne, že místo toho raději bude stahovat obrázek, který se stejně bude moci zobrazit až po té, co dorazí to HTML.
-
L.Stříbrný podporovatel
Píšeš hrozný bláboly. Stává se ti to často?
V době, kdy se HTTP PUSH zavrhl ho Chrome používat uměl. Neuměly ho používat servery. Ve standardu byl pět let. Třeba Nginx ho uměl od začátku 2018, Chrome zhruba stejně dlouho. Tedy dva a půl roku to lidi mohli používal. Nepoužívali.
Zbytek je takový zmatek, že se v tom nedá pořádně vyznat, co vlastně tvrdíš. Každopádně:
1) Early hints se dají používat i mimo HTML, stačí, aby klient uměl interpretovat <link /> z té 103 odpovědi. Ten ale klidně může vést třeba na JSON a hlavní odpověď serveru po hintech bude taky JSON.
2) Ty early hints se posílají právě proto, aby klient věděl, jaká data bude potřebovat a mohl si je stáhnout předem. V drtivé většině případů jsou to statické soubory, které má server k dispozici jaksi pořád, ale i kdyby nebyly, tak prohlížeč prostě pošle request a až to bude, tak to bude.
3) Zdá se mi to, nebo opravdu netušíš, že jak klient tak server umí vyřizovat požadavky paralelně? Protože jinak nevím, jak si vykládat "místo toho [HTML] raději bude stahovat obrázek".
-
Filip JirsákStříbrný podporovatel
Jako bláboly vám to připadá proto, že netušíte nic o těch technologiích.
HTTP PUSH není určen pro server servírující statický obsah nebo proxy, ale aplikační server. Ten totiž doopravdy ví, co bude prohlížeč v následující chvíli potřebovat. Nginx to v drtivé většině případů vědět nemůže, protože vidí jenom data, která mu poslal aplikační server, ale neví, co bude dál. Takže nginx se tu budoucí potřebu dozví až těsně před tím, než se to dozví prohlížeč (kdyby nginx analyzoval procházející komunikaci).
Na to, aby se to začalo reálně na internetu používat, by bylo potřeba, aby se to naučily redakční systémy, JAMstack generátory apod. Ty zase potřebují, aby to uměl jejich middleware – Express, Netlify/Vercel apod. A ty zase většinou potřebují, aby to uměl proxy server, který reálně komunikuje s prohlížečem. Takže to, že to uměl nginx, bylo v pořádku. Ale neznamenalo to, že se to začne objevovat na internetu. Znamenalo to, že se to může implementovat do druhé vrstvy softwaru, a až to bude v ní, začne se to implementovat do třetí vrstvy – a teprve pak se to může začít implementovat do koncových aplikací a nasazovat na internetu. A tohle prostě nějakou dobu trvá – kdyby se stejně kriticky přistupovalo k HTTP/2, musela by se dávno zaříznout i podpora HTTP/2 (a tam přitom k tomu, aby to bylo vidět na internetu, stačilo implementovat jen jednu vrstvu, tedy nginx a podobné).
Ad 1) Ano, psal jsem, že tohle nešlo použít, když se preload informace předávaly v HTML elementu link, s Early hints už to jde.
Ad 2) Ano, a přesně k tomu samému se dalo použít i HTTP PUSH. Jenže HTTP PUSH se dalo použít třeba také v případě, že redakčnímu systému konečně přišla odpověď z databáze, jaké články se mají zobrazit, a on tak mohl prohlížeči nabídnout obrázky k článkům, které bude potřebovat. To s Early hints nejde, protože ty se posílají na začátku přenosu.
Ad 3) Na rozdíl od vás tuším, že tohle celé přednačítání se dělá proto, že linka mezi prohlížečem a serverem není nekonečně tlustá. Takže když server tlačí linkou HTML maximální rychlostí, nemůže vedle toho ještě posílat obrázek, ani když klient i server chtějí.
Tohle je úplně stejný princip, jako když QoS na lince (omezování šířky pásma) děláte až za úzkým místem. Ano, jde to, často je lepší, než když QoS nemáte vůbec a máte problematický provoz. Ale pořád je daleko lepší ten provoz řídit před tím úzkým hrdlem. Protože tam víte, co všechno se snažíte tím úzkým hrdlem procpat a můžete to seřadit tak, aby byl výsledek co nejlepší.
A tohle je přesně to, co může dělat webový server ale ne prohlížeč. Protože server ví, že teď ještě nemá data z databáze pro HTML, tak mezi tím může posílat CSS. Pak data z DB dorazí, tak pozastaví zasílání CSS a maximální rychlostí odešle HTML. Prohlížeč tyhle informace nemá, neví, že teď bude server čekat na nějaký zdroj a teď už data má a může začít posílat HTML, které je důležitější než CSS nebo obrázek.
ČLÁNKY DO MAILU