Ich hoffe, Sie haben diesen Titel laut mit Ihrer besten Seinfeld-Stimme vorgelesen.
Eine aktuelle Frage in unseren Foren hat mich darauf aufmerksam gemacht, dass es mehr Eigenschaften gibt, die zu @font-face hinzugefügt werden können, als die üblichen Verdächtigen font-family und src. Was ist der Sinn davon? Warum sollte man andere Schriftartendeklarationen dort festlegen?
Ich bin es gewohnt, @font-face im Wesentlichen so zu schreiben:
@font-face {
font-family: "My Custom Font";
src: url("path/to-font-file.woff2");
}
Aber die Spezifikation enthält tatsächlich mehr Deskriptoren
@font-face {
font-family: <family-name>;
src: <url>;
unicode-range: <urange>;
font-variant: normal | [ <east-asian-variant-values> || <east-asian-width-values> || ruby ];
font-feature-settings: normal | <feature-tag-value>;
font-stretch: normal | ultra-condensed | extra-condensed | condensed | semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded;
font-weight: normal | bold | bolder | lighter | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900;
font-style: normal | italic | oblique;
}
Das wirst du oft sehen, wenn du von Schriftartendiensten generierten @font-face-Code betrachtest.
Sie sind die Torwächter!
Das ist eine Analogie, mit der du über @font-face-Deklarationsblöcke nachdenken kannst. Die Schriftart wird heruntergeladen und verwendet, wenn sie die Torwächter passiert.
font-family ist der offensichtliche. Du deklarierst eine neue Schriftfamilie, die verwendet werden soll, daher muss jedes Element, das diese Schriftart verwenden möchte, eine passende haben.
@font-face {
/* Gatekeeper: font-family on another element must match this to be used. */
font-family: 'Open Sans';
src: url(my-font.woff2) format('woff2');
}
body {
/* Match! */
font-family: 'Open Sans';
}
h1, h2 {
/* No match */
font-family: 'Different Font';
}
Sie sind (meistens) alle Torwächter
Mit Ausnahme von font-variant und font-feature-settings können alle Eigenschaften als Filter verwendet werden, die den Browser anweisen, die Schriftdateien herunterzuladen und zu verwenden, wenn die Werte übereinstimmen.
@font-face {
/* Only download and use if element matches this font-family */
font-family: 'My Font';
/* Only download and use if element matches this font-style */
font-style: italic;
/* Only download and use if element matches this font-weight */
font-weight: 700;
src: url(my-bold-and-italic-font.woff2) format('woff2');
/* Only download and use if these characters are used */
unicode-range: U+0460-052F, U+20B4, U+2DE0-2DFF, U+A640-A69F;
}
Vielleicht ist eine Diagrammdarstellung hilfreich

So etwas wie Apstract Class …
Interessant, ich kannte
font-weight&font-style, aber nichtunicode-range. Bin froh, davon zu erfahren. Zeit zum Optimieren!Danke Geoff. Hat mir geholfen!
Mann. Ich habe nie so darüber nachgedacht. Es lädt also nur herunter, wenn es übereinstimmt? Ich werde damit experimentieren müssen. Danke!
Sieht aus, als würde das Bandbreite sparen!
Mein Kommentar hier. Ich bin cool, weil ich immer nur Terminalschriften benutze.
Ich habe es noch nie aus dieser Perspektive gesehen und wusste definitiv nicht, dass es das Laden von Schriftarten beeinflusst. Gut zu wissen, danke.
Ich verwende die Schriftartattribute sehr oft und war daher überrascht, dass du nicht den offensichtlicheren Aspekt erwähnt hast: Es erlaubt dir einfach, verschiedene
font-weights undfont-styles derselben Schriftart unter Verwendung derselbenfont-family-Deklaration zu verwenden (was meiner Meinung nach die Art und Weise ist, wie Schriftarten in CSS verwendet werden sollen).Anstatt also den gesamten Schriftstapel in der Eigenschaft „font-family“ meines CSS ersetzen zu müssen, kann ich einfach den
font-weightaufboldändern und die gleichefont-familyweiter verwenden. Es hilft auch, viele kryptische Schriftartnamen wie „MyFontBld“ und „MyFontBldCnIt“ zu vermeiden.Das dachte ich auch. Beim Testen stellte sich jedoch heraus, dass der Browser eine Schriftart, die nicht die richtig gestylten Glyphen hat, nicht formatieren kann. Zum Beispiel kannst du
font-style: italic;auf@font-facesetzen, aber das wird nicht an das Element weitergegeben, wenn die Schriftdatei keine kursiven Zeichen enthält: http://codepen.io/team/css-tricks/pen/YqVeErDasselbe gilt für Systemdateien, selbst mit den richtigen Stilen: http://codepen.io/team/css-tricks/pen/wGdyNN
@Geoff, soweit ich das verstehe, setzen
font-weightundfont-styleinnerhalb einer@font-face-Deklaration keine Seitenstile; stattdessen assoziieren sie eine Schriftdatei mit einem bestimmten Stil. Im Wesentlichen heißt es: „Dies ist die normale Strichstärke, normale Schrift. Dies ist die normale Strichstärke, kursive Schrift. Dies ist die fette Strichstärke, normale Schrift“, usw.Wenn also ein Element – sagen wir, ein
<em>– einen bestimmten Anzeigetyp anfordert, sagt der Browser: „Oh, du willst kursiv? OK, das ist die Datei, die ich dafür verwenden sollte.“Dein erstes Beispiel funktioniert, wenn ich die Zeile
font-style: italiczurh1-Deklaration hinzufüge – weil das Element jetzt nach einer fetten, kursiven Schrift fragt, wird die richtige Schriftdatei angezeigt: http://codepen.io/smcginnis/pen/eZGZvP?editors=1100 (Entschuldigung für die Farbänderung, das Rot tat meinen Augen weh).In deinem zweiten Beispiel ist der Name Arial keiner Schriftdatei zugeordnet, daher tut der
@font-face-Block eigentlich nichts. Innerhalb des@font-face-Blocks verhält sich diefont-family-Eigenschaft anders als innerhalb eines Selektorblocks; hier setzt sie nicht die Schriftart, sondern sagt nur: „Wenn dieser Schriftname angefordert wird, suche hier nach der Schriftdatei“. Wenn du die Zeilesrc: local("Arial");* hinzufügst, funktioniert sie für jedes Kindelement, das nach kursiv fragt. http://codepen.io/smcginnis/pen/EKwKoz?editors=1100Wenn ich den Artikel noch einmal lese, scheint es, dass du das bereits weißt, und vielleicht warst du dir nur nicht sicher, was Nils sagte. Aber ich dachte, es wäre erwähnenswert, falls jemand anderes die Informationen benötigt.
* Ich habe es in meinem Fork tatsächlich zu Georgia geändert, damit du sehen kannst, dass, obwohl die
h1mit Arial gerendert wird, was sie anfordert, dieemdarin mit der tatsächlichen Schriftdatei gerendert wird, die der@font-face-Block ihr für Arial 700 Italic zuweist. Ich musste auch die CSS-Reset-Funktion aus beiden Forks entfernen, da sie das Standardgewicht und den Standardstil der Elemente durcheinander brachte.Yep, wir sind total auf derselben Wellenlänge, Kumpel. :)
Für besseres Coding und besseres Lesen denke ich, dass die Angabe desselben Schriftartnamens mit unterschiedlichem Schriftstil und unterschiedlicher Schriftstärke besser funktioniert.
Also,
Ich sagte Coding im Sinne von CSS als Coding. Ich fühle mich wie beim Coden…