Visa reservtext direkt när läsarna behöver orden för att använda en sida. Välj tillfällig dold text endast för ett litet, motiverat element som är beroende av ett visst teckensnitt. För en sida som du underhåller på en Mac förklarar den här guiden hur du väljer en policy och testar dess effekt på textflödet.

Vad förändras egentligen medan ett teckensnitt laddas?

Ett reservteckensnitt återger samma text med ett annat typsnitt medan det begärda teckensnittet inte är tillgängligt. Tillfälligt dold text motsvarar teckensnittsladdningens blockeringsperiod: webbläsaren lägger ut ett osynligt reservteckensnitt. Laddningstidslinjen börjar när webbläsaren först försöker använda det nedladdningsbara teckensnittet. MDN:s referens för font-display förklarar dessa steg.

Den skillnaden spelar roll när du granskar en sida. En tom rubrik visar inte att dess slutliga dimensioner har reserverats. Webbläsaren använder fortfarande reservlayout under blockeringsperioden; att dölja bokstäverna fastställer inte det nedladdade teckensnittets slutliga radbrytningar. Bedöm synlighet och layoutstabilitet var för sig.

Den relevanta inställningen är deskriptorn font-display i en @font-face-regel. Den hör till definitionen av teckensnittet, inte till en vanlig styckeväljare. Det här är ett val när du skapar sidan: använd stilmallen eller teckensnittsinställningarna som finns för sidan du underhåller. MDN dokumenterar var font-display gäller.

Vilket font-display-värde passar läsarens uppgift?

Bestäm två saker innan du redigerar: om orden ska visas snabbt i ett annat teckensnitt och om det är acceptabelt att ersätta det senare. Följande tabell översätter de dokumenterade laddningsperioderna till val för en abstrakt offentlig sida. MDN:s värdedefinitioner beskriver beteendet bakom dem.

Värde När teckensnittet inte är tillgängligt Möjlighet att ersätta reservteckensnittet Lämplig utgångspunkt
swap Extremt kort blockering, sedan synligt reservteckensnitt Obegränsad bytesperiod En kort rubrik där det avsedda typsnittet spelar roll
fallback Extremt kort blockering, sedan synligt reservteckensnitt Kort bytesperiod Läsningstext där en tidig ändring är acceptabel
optional Extremt kort blockering Ingen bytesperiod Text där det är viktigast att behålla det först synliga teckensnittet
block Osynligt reservteckensnitt under en kort blockeringsperiod, sedan synligt reservteckensnitt Obegränsad bytesperiod Ett litet element med ett specifikt teckensnittsberoende
auto Webbläsarvald policy Webbläsarvald policy Att godta webbläsarens standardbeteende

Det här är policykategorier, inte exakta tidsgränser som du kan ställa in. W3C:s aktuella arbetsutkast till CSS Fonts Level 4 rekommenderar typiska varaktigheter men tillåter uttryckligen variationer mellan webbläsare. Det begränsar också block till små textstycken där det specifika teckensnittet krävs för användbarheten. Att enbart föredra en viss rubrikstil är ett svagt skäl till att låta den vara tom. W3C: Styrning av teckensnittsvisning per teckensnitt.

För en syntetisk sida med rubriken ”Exempelsamling”, navigeringen ”Avsnitt ett” och flera stycken kan du börja med att överväga fallback för läsningstext. Överväg swap för den korta rubriken om det är viktigt att typsnittet används till slut. Välj optional när det är viktigast att behålla den första synliga återgivningen. Rekommendationerna tillämpar de dokumenterade policyerna på läsarens uppgift; de är inte uppmätta resultat.

Använd ett beslutsstöd för synlighet och omflöde

Utvärdera varje textroll separat. En navigeringsetikett och ett stycke kan använda samma familj, men deras layoutbegränsningar skiljer sig åt. Den användbara frågan är om ett teckensnittsbyte hindrar någon från att fortsätta uppgiften eller bara ändrar utseendet.

  1. Läs sidan med reservteckensnittet. Kan någon förstå ”Avsnitt ett”, identifiera rubriken och läsa styckena? Om ja är synligt reservteckensnitt en fungerande utgångspunkt.
  2. Observera teckensnittsbytet. Får rubriken en extra rad? Radbryts etiketterna? Flyttas nästa stycke?
  3. Välj ett godtagbart tidsfönster för bytet. Använd swap när ett sent byte fortfarande är acceptabelt, fallback när bara ett tidigt byte är önskvärt, eller optional när det första synliga teckensnittet bör ligga kvar.
  4. Kräv ett konkret skäl till att texten är tom. Innan du väljer block, identifiera vad som blir oanvändbart med reservteckensnittet och varför beroendet inte kan tas bort.

Anta till exempel att ”Exempelsamling” ryms på en rad med reservteckensnittet men tar två rader med det nedladdade teckensnittet. Om rubriken har en hypotetisk radhöjd på 40 pixlar bidrar den extra raden med 40 pixlar till höjden, förutsatt att avståndet är oförändrat. Innehållet nedanför kan flyttas i motsvarande grad. Det här är illustrativa indata, inte webbläsarmätningar.

Tillfällig dold text löser inte den skillnaden. De praktiska alternativen är att få reservteckensnittet att matcha bättre, justera layouten efter testning eller välja en policy som undviker ett sent byte. Enligt beteendet för optional i W3C:s aktuella utkast får det valfria teckensnittet inte ersätta reservteckensnittet under sidans livstid när reservtexten väl har visats. W3C:s definition av optional.

Så tillämpar och testar du valet på en Mac

Använd en sida vars stilmall du kan redigera och där det befintliga webbteckensnittet redan laddas som det ska. Behåll den faktiska referensen till teckensnittsfilen; du behöver varken ladda ned ett nytt teckensnitt eller använda en ersättningsresurs för den här jämförelsen.

Leta reda på den relevanta @font-face-deklarationen i sidans källstilmall eller i den konfiguration för teckensnitt som stöds. Ställ in dess deskriptor font-display på det värde du vill prova, till exempel font-display: fallback;. Granska de övriga deklarationerna för vikter och stilar så att testet omfattar de teckensnitt som sidan faktiskt begär. Deskriptorns placering visas i MDN:s exempel på font-display.

Öppna DevTools i Chrome på din Mac genom att trycka på Command + Option + I. Du kan också högerklicka på måltexten och välja Inspect; panelen Elements visar den tillämpade CSS-koden under Styles. Chromes anvisningar för att öppna DevTools beskriver båda sätten.

Gör följande jämförelse efter varje ändring av stilmallen. Behåll samma fönsterbredd och zoomnivå så att du kan koppla skillnaderna till teckensnittsladdningspolicyn.

  1. Öppna Network, aktivera Disable cache, välj en långsammare förinställning i menyn Throttling och ladda om sidan. Använd filtret Font för att fokusera på teckensnittsbegäranden.
  2. Håll uppsikt över rubriken, navigeringen och början av stycket. Anteckna om texten först är tom, visas med reservteckensnitt och senare får andra radbrytningar.
  3. Om övergången går för snabbt för att inspekteras aktiverar du Capture screenshots i inställningarna för panelen Network och laddar om sidan för att granska laddningsförloppet.
  4. Inaktivera begränsningen och avmarkera Disable cache. Ladda om sidan igen för att jämföra ett återbesök under normala förhållanden. Referensen för Chromes Network-funktioner dokumenterar de här kontrollerna.

Testa separat hur sidan fungerar när teckensnittet inte är tillgängligt. Högerklicka på den faktiska teckensnittsbegäran i Network och välj Block request, och ladda sedan om sidan. Chrome visar det matchande mönstret under Request conditions. Kontrollera att orden blir läsbara och att sidan förblir användbar med reservteckensnittet. Ta bort eller inaktivera testmönstret efteråt. Chromes dokumentation om Request conditions förklarar hur du blockerar begäranden och identifierar blockerade begäranden.

Granska sidan även i Safari om det ingår i den Mac-miljö där du tänker surfa. Se Chrome-testet som belägg för hur webbläsaren återger sidan, inte som bevis för att tidsförloppet är identiskt i andra webbläsare: specifikationen tillåter skillnader mellan webbläsare. Spara en kort jämförelseanteckning med webbläsaren, värdet du provade, den inledande synligheten och de observerade radbrytningarna.

Vad gör jag om synligt reservteckensnitt ändrar layouten för mycket?

Börja med den faktiska texten och den tillgängliga bredden. Jämför korta etiketter, den längsta rubriken och några rader från styckena. Ett reservteckensnitt som visuellt liknar webbteckensnittet kan ändå ha andra teckenbredder och ge andra radbrytningar.

För bättre matchning skalar size-adjust en teckensnittsuppsättnings konturer och mått, inklusive teckenbredder. MDN visar hur du definierar en lokal reservuppsättning och justerar den så att den bättre matchar ett primärt webbteckensnitt. Ta fram en lämplig procentsats för just ditt teckensnittspar; procentsatsen i ett dokumentations­exempel är inte en universell inställning. MDN: size-adjust.

Kontrollera de vertikala måtten separat. Deskriptorn ascent-override styr måttet ovanför baslinjen som används när radrutor läggs ut, men MDN anger för närvarande att stödet är begränsat. Se justeringen som en förbättring och behåll en läsbar reservlayout i webbläsare som inte stöder den. MDN: ascent-override.

Låt webbläsaren hantera textsättningen. Försök inte stabilisera en rubrik genom att ersätta eller mäta varje tecken separat. CSS-matchning av teckensnitt hanterar grafemkluster särskilt, till exempel en grundbokstav med ett kombinerande tecken. Granska fullständiga etiketter och rader i den faktiska layouten. W3C: Klustermatchning.

Ändrar förinläsning eller ett bibliotek för teckensnittsladdning beslutet?

Förinläsning påverkar hur resurser upptäcks. WHATWG:s HTML-standard definierar preload som att en resurs som förväntas behövas vid den aktuella navigeringen hämtas och cachelagras i förväg. Det väljer inte din font-display-policy. Överväg det först efter att du har valt ett godtagbart synligt beteende; tidigare hämtning ersätter inte beslutet om vad som ska hända när teckensnittet fortfarande är otillgängligt. WHATWG: Länktypen preload.

För vanlig sidtext börjar du med CSS. Om ett befintligt projekt använder Font Face Observer returnerar dess dokumenterade metod load() ett löfte som uppfylls när teckensnittet laddas och avvisas om laddningen misslyckas. Familjenamnet och den valfria beskrivningen av vikt, stil och bredd ska matcha det begärda teckensnittet. Biblioteket beskriver också hur du anger lämplig testtext om dess standardtecken saknas i teckensnittet. Dokumentation för Font Face Observer.

En lyckad återanropsfunktion från biblioteket signalerar att laddningen är klar; det är fortfarande din applikation som avgör vad som visas. Om anpassad logik döljer text ska du ange en felhantering som återställer läsbar reservtext. Annars kan ett misslyckat försök lämna applikationens döljningsregel aktiv. Det här är en rekommendation för implementationen som bygger på bibliotekets dokumenterade förlopp för lyckad och misslyckad laddning.

Det inbyggda API:et har en liknande avgränsning. document.fonts.ready uppfylls när laddnings- och layoutåtgärderna för de teckensnitt som används är klara; den uppsättningen kan skilja sig från alla deklarerade teckensnitt, inklusive valfria teckensnitt som inte hann användas. Därför bevisar den inte att varje avsett teckensnitt är synligt. MDN: Document-egenskapen fonts.

På samma sätt väljer textargumentet som kan anges till document.fonts.load() matchande teckensnitt via deras Unicode-intervall; det kontrollerar inte täckningen för enskilda tecken. Att laddningen är klar och att hela exemplet återges korrekt är två separata kontroller. MDN: Metoden FontFaceSet load().

Välj policy genom att granska samma sida vid långsam laddning, när teckensnittet inte är tillgängligt och vid upprepade laddningar. Se till att vanliga ord förblir läsbara, bestäm uttryckligen om ett sent byte är acceptabelt och godta tillfällig dold text endast där ett litet element har ett påvisat teckensnittsberoende. Resultatet ska göra det möjligt för någon att bekvämt fortsätta läsa ”Exempelsamling” under alla testade förhållanden.

Källor