-
Notifications
You must be signed in to change notification settings - Fork 790
Expand file tree
/
Copy pathOverview.bs
More file actions
1335 lines (1115 loc) · 60.6 KB
/
Overview.bs
File metadata and controls
1335 lines (1115 loc) · 60.6 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<pre class='metadata'>
Title: CSS Fonts Module Level 4
Shortname: css-fonts
Level: 4
Status: ED
Work Status: Exploring
Group: CSSWG
ED: https://drafts.csswg.org/css-fonts-4/
Editor: John Daggett, Invited Expert, https://twitter.com/nattokirai
Editor: Myles C. Maxfield, Apple Inc., mmaxfield@apple.com
Abstract: This specification defines modifications to the existing <a href="https://drafts.csswg.org/css-fonts-3/">CSS Fonts 3</a> specification along with additional experimental features.
Ignored Terms: font-palette, <named-palette-color>
</pre>
<script type="text/javascript" src="http://use.typekit.com/xon2bky.js"></script>
<script type="text/javascript">try{Typekit.load();}catch(e){}</scr
4B92
ipt>
<style>
body, th, td, h1, h2, h3, h4, h5, h6 {
font-family: "myriad-pro", sans-serif !important;
}
a.self-link {
opacity: 0.1;
}
.touch a.self-link {
opacity: 0.5;
}
a.self-link:hover {
color: black;
opacity: 1;
background-color: transparent;
}
.advisement {
margin-top: 4em;
text-align: left;
}
</style>
<pre class="link-defaults">
spec:css-color-4; type:property; text:color
</pre>
<p class="advisement"><strong>This document contains ideas and
experiments that may or may not end up in the final version of a CSS
Fonts specification. Implementors are encouraged to ask about the status
of a particular feature listed here on the <code>www-style</code>
mailing list.</strong></p>
<h2 id="introduction">Introduction</h2>
<p>The CSS3 Fonts specification ([[!CSS-FONTS-3]]) describes the basic
controls CSS provides for selecting and using fonts within documents.
The ideas here are additions or modifications to the properties and
rules defined in CSS3 Fonts.</p>
Issue: Please note that OpenType/TrueType variation font support
is still in intial stages of specification and implementation. Please
comment on any bugs in this spec at <a href="https://github.com/w3c/csswg-drafts/issues">
https://github.com/w3c/csswg-drafts/issues</a>. Also, please note that this
spec is incomplete and only includes some of the text from <a href="https://www.w3.org/TR/css-fonts-3/">
https://www.w3.org/TR/css-fonts-3/</a>.
<p></p>
<h2 id="basic-font-props">Basic Font Properties</h2>
<p>The particular font face used to render a character is determined by
the font family and other font properties that apply to a given element.
This structure allows settings to be varied independent of each
other.</p>
<h3 id="font-family-prop">Font family: the 'font-family' property</h3>
Issue: Import from level 3
<h3 id="font-weight-prop">Font weight: the 'font-weight' property</h3>
<pre class="propdef">
Name: font-weight
Value: normal | bold | bolder | lighter | <<number>>
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: n/a
Computed value: numeric weight value (see description)
Media: visual
</pre>
The 'font-weight' property specifies the weight of glyphs in the font, their degree of blackness or stroke thickness.
Values have the following meanings:
<dl dfn-for=font-weight dfn-type=value>
<dt id="font-weight-numeric-values"><dfn><<number>></dfn></dt>
<dd>
These values form an ordered sequence, where each number indicates a weight that is
at least as dark as its predecessor. Only values between 1 - 999 are valid, and all other values are treated as parse errors. Certain numeric values correspond to the commonly used weight names below (Note that a font may internally provide its own mappings, but those mappings within the font are disregarded):
<ul>
<li>100 - Thin</li>
<li>200 - Extra Light (Ultra Light)</li>
<li>300 - Light</li>
<li>400 - Normal</li>
<li>500 - Medium</li>
<li>600 - Semi Bold (Demi Bold)</li>
<li>700 - Bold</li>
<li>800 - Extra Bold (Ultra Bold)</li>
<li>900 - Black (Heavy)</li>
</ul>
</dd>
<dt><dfn>normal</dfn></dt>
<dd>
Same as '400'.
</dd>
<dt><dfn>bold</dfn></dt>
<dd>
Same as '700'.
</dd>
<dt><dfn>bolder</dfn></dt>
<dd>
Specifies a bolder weight than the inherited value.
</dd>
<dt><dfn>lighter</dfn></dt>
<dd>
Specifies a lighter weight than the inherited value.
</dd>
</dl>
Font formats that use a scale other than a nine-step scale should map
their scale onto the CSS scale so that 400 roughly corresponds with a
face that would be labeled as Regular, Book, Roman and 700 roughly
matches a face that would be labeled as Bold. Or weights may be
inferred from the style names, ones that correspond roughly with the
scale above. The scale is relative, so a face with a larger weight value
must never appear lighter. If style names are used to infer weights,
care should be taken to handle variations in style names across locales.
Quite often there are only a few weights available for a particular
font family. When a weight is specified for which no face exists, a
face with a nearby weight is used. In general, bold weights map to faces
with heavier weights and light weights map to faces with lighter weights
(see the <a href="#font-matching-algorithm">font matching section
below</a> for a precise definition). The examples here illustrate which
face is used for different weights, grey indicates a face for that
weight does not exist so a face with a nearby weight is used:
<div class="figure"><img alt="weight mappings for a family with 400, 700 and 900 weights" src="optimaweights.png" /><p class="caption">Weight mappings for a font family with 400, 700 and 900 weight faces</p></div>
<div class="figure"><img alt="weight mappings for a family with 300, 600 weights" src="hiraginoweights.png" /><p class="caption">Weight mappings for a font family with 300 and 600 weight faces</p></div>
Most user agents model a font as having a particular weight which often corresponds to one of the numbers in the nine-step scale mentioned <a href="#font-weight-numeric-values">above</a>.
While this is true of most fonts, some fonts may be configurable so as to
support a range of weights. In this situation, the user agent uses a face
with a weight as close as possible to the weight requested (see the
<a href="#font-matching-algorithm">font matching section below</a> for the
precise algorithm). In particular, a user agent using a font which supports
a range of weights should behave the same as if a font is present at each
individual weight in the range. For TrueType / OpenType fonts which use variations, the "wght"
variation is used to implement varying weights. Fractional weights are
valid.
Although the practice is not well-loved by typographers, bold faces are often
synthesized by user agents for faces that lack actual bold faces. For
the purposes of style matching, these faces must be treated as if they
exist within the family. Authors can explicitly avoid this behavior
by using the 'font-synthesis' property.
Specified values of 'bolder' and 'lighter' indicate weights
relative to the weight of the parent element. The computed weight is
calculated based on the inherited 'font-weight' value using the chart
below.
<table id="bolderlighter" class="data" summary="Bolder/lighter mappings">
<thead>
<tr>
<th>Inherited value</th>
<th>bolder</th>
<th>lighter</th>
</tr>
</thead>
<tbody>
<tr><th>- 99</th><td>400</td><td>No change</td></tr>
<tr><th>100 - 349</th><td>400</td><td>100</td></tr>
<tr><th>350 - 549</th><td>700</td><td>100</td></tr>
<tr><th>550 - 749</th><td>900</td><td>400</td></tr>
<tr><th>750 - 899</th><td>900</td><td>700</td></tr>
<tr><th>900 -</th><td>No change</td><td>700</td></tr>
</tbody>
</table>
The table above is equivalent to selecting the next relative bolder or lighter face,
given a font family containing normal and bold faces along with a thin and a heavy face.
Authors who desire finer control over the exact weight values used for a given element
may use numerical values instead of relative weights.
<h3 id="font-stretch-prop">Font width: the 'font-stretch' property</h3>
<pre class="propdef">
Name: font-stretch
Value: normal | ultra-condensed | extra-condensed | condensed | semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded | <<percentage>>
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: Not resolved.
Computed value: numeric weight value (see description)
Media: visual
Animatable: As <<number>>
</pre>
The 'font-stretch' property selects a normal,
condensed, or expanded face from a font family. Absolute keyword values are aliased to
have the following meaning (Note that a font may internally provide its own mappings, but those mappings within the font are disregarded):
<table id="stretchmappings" class="data" summary="font-stretch numeric mappings">
<thead>
<tr>
<th>Absolute keyword value</th>
<th>Numeric value</th>
</tr>
</thead>
<tbody>
<tr><th>ultra-condensed</th><th>50%</th></tr>
<tr><th>extra-condensed</th><th>62.5%</th></tr>
<tr><th>condensed</th><th>75%</th></tr>
<tr><th>semi-condensed</th><th>87.5%</th></tr>
<tr><th>normal</th><th>100%</th></tr>
<tr><th>semi-expanded</th><th>112.5%</th></tr>
<tr><th>expanded</th><th>125%</th></tr>
<tr><th>extra-expanded</th><th>150%</th></tr>
<tr><th>ultra-expanded</th><th>200%</th></tr>
</tbody>
</table>
Negative values are not allowed and are treated as parse errors.
When a face does not exist
for a given width, values less than 100% map to a narrower face,
otherwise a wider face. Conversely, values greater than or equal to 100% map to a wider
face, otherwise a narrower face. Some fonts may support a range of stretch
values; if the requested stretch value is not available in the font, the
closest supported value should be used, using the same mapping rules (see the
<a href="#font-matching-algorithm">font matching section below</a> for the
precise algorithm). For TrueType / OpenType fonts which use variations, the "wdth"
variation is used to implement varying widths. The figure below shows how nine
font-stretch property settings affect font matching for font family
containing a variety of discrete widths. Grey indicates a width for which no
face exists and a different width is substituted:
<div class="figure"><img alt="width mappings for a family with condensed, normal and expanded faces" src="universwidths.png" /><p class="caption">Width mappings for a font family with condensed, normal and expanded width faces</p></div>
<h3 id="font-style-prop">Font style: the 'font-style' property</h3>
<pre class="propdef">
Name: font-style
Value: normal | italic | oblique <<angle>>?
Initial: normal
Applies to: all elements
Inherited: yes
Percentages: n/a
Computed value: As specified
Media: visual
Animatable: If both "from" and "to" values are "oblique", then yes, as an <<angle>>. Otherwise, no.
</pre>
The 'font-style' property allows
italic or oblique faces to be selected. Italic forms are generally cursive in nature while oblique faces are
typically sloped versions of the regular face. Oblique faces can be simulated by artificially sloping the
glyphs of the regular face. Compare the artificially sloped renderings of Palatino "a" and Baskerville "N"
in grey with the actual italic versions:
<div class="figure"><img alt="artificial sloping vs. real italics" src="realvsfakeitalics.png" /><p class="caption">Artificial sloping versus real italics</p></div>
Values have the following meanings:
<dl dfn-for=font-style dfn-type=value>
<dt><dfn>normal</dfn></dt>
<dd>
Matches against a face that is classified as a normal face, one that is neither italic or obliqued. This represents an oblique value of "0".
</dd>
<dt><dfn>italic</dfn></dt>
<dd>
Matches against a font that is labeled as an oblique face, or an italic face if one is not.
</dd>
<dt><dfn>oblique <<angle>>?</dfn></dt>
<dd>
Controls matching against an oblique face. The lack of a number represents an angle of "20deg". Values less than or equal to -90deg or values greater than or equal to 90deg are invalid and are treated as parse errors. (Note that a font may internally provide its own mapping for "oblique", but that mapping within the font is disregarded)
</dd>
</dl>
Some font families may contain only zero or one italic or oblique face, while yet other
families may contain multiple oblique faces with varying
angles. The font matching routine will select a font to use which
is closest to the requested angle. In general, for a requested angle greater
or equal to 20deg, larger angles are prefered; otherwise, smaller
angles are preferred (see the
<a href="#font-matching-algorithm">font matching section below</a> for
the precise algorithm). Fractional and negative values are accepted, but values
less than or equal to -90 as well as values greater than or equal to 90 are not
allowed and are treated as parse errors.
For TrueType / OpenType fonts which use variations, the "slnt"
variation is used to implement oblique values, and the "ital" variation with a value of "1"
is used to implement the italic values. The meaning of a
negative value for "oblique" is to slope the text in the opposite
direction. If no italic or oblique face is available, oblique faces can be
synthesized by rendering non-obliqued faces with an artificial
obliquing operation. The use of these artificially obliqued faces
can be disabled using the 'font-synthesis' property. The details
of the obliquing operation are not explicitly defined.
<p class="note">Authors should also be aware that synthesized
approaches may not be suitable for scripts like Cyrillic, where italic
forms are very different in shape. It is always better to use an actual
italic font rather than rely on a synthetic version.</p>
<!-- resolution on the "undefined" nature of synthetics: https://www.w3.org/2013/06/06-css-minutes.html#item03 -->
Many scripts lack the tradition of mixing a cursive form within
text rendered with a normal face. Chinese, Japanese and Korean fonts
almost always lack italic or oblique faces. Fonts that support a
mixture of scripts will sometimes omit specific scripts such as Arabic
from the set of glyphs supported in the italic face. User agents
should be careful about making <em>character map</em> assumptions across
faces when implementing support for <em>system font fallback</em>.
<h3 id="font-size-prop">Font size: the 'font-size' property</h3>
Issue: Import from level 3
<h2 id="font-resources">Font Resources</h
348C
2>
<h3 id="src-desc">Font reference: the 'src' descriptor</h3>
<pre class='descdef mq'>
Name: src
Value: [ <<url>> [ format( <<string>> # )]? | <<font-face-name>> ] #
For: @font-face
Initial: N/A
</pre>
This descriptor specifies the resource containing font data. It is
required for the <code>@font-face</code> rule to be valid. Its value
is a prioritized, comma-separated list of external references or
locally-installed font face names. When a font is needed the user
agent iterates over the set of references listed, using the first one
it can successfully activate. Activation of a font involves downloading
the file or reading it from disk, parsing it, and perhaps additional user-agent-dependent steps.
Fonts containing invalid data or local
font faces that are not found are ignored and the user agent loads the
next font in the list.
As with other URLs in CSS, the URL may be relative, in which case it
is resolved relative to the location of the style sheet containing the
<code>@font-face</code> rule. In
the case of SVG fonts, the URL points to an element within a document
containing SVG font definitions. If the element reference is omitted,
a reference to the first defined font is implied. Similarly, font
container formats that can contain more than one font must load one
and only one of the fonts for a given <code>@font-face</code> rule. Fragment
identifiers are used to indicate which font to load. If a container
format lacks a defined fragment identifier scheme, implementations
should use a simple 1-based indexing scheme (e.g. "font-collection#1"
for the first font, "font-collection#2" for the second font).
<pre>
src: url(fonts/simple.woff); /* load simple.woff relative to stylesheet location */
src: url(/fonts/simple.woff); /* load simple.woff from absolute location */
src: url(fonts.svg#simple); /* load SVG font with id 'simple' */
</pre>
External references consist of a URL, followed by an optional hint
describing the format of the font resource referenced by that URL. The
format hint contains a comma-separated list of format strings that
denote well-known font formats. Conformant user agents must skip
downloading a font resource if the format hints indicate only
unsupported or unknown font formats. If no format hints are supplied,
the user agent should download the font resource.
<pre>
/* load WOFF font if possible, otherwise use OpenType font */
@font-face {
font-family: bodytext;
src: url(ideal-sans-serif.woff) format("woff"),
url(basic-sans-serif.ttf) format("opentype");
}
</pre>
<p>Format strings defined by this specification:
</p>
<table class="data" id="fontformats">
<thead>
<tr>
<th>String</th>
<th>Font Format</th>
<th>Common extensions</th>
</tr>
</thead>
<tbody>
<tr>
<th>"woff"</th>
<td><a href="https://www.w3.org/TR/WOFF/">WOFF (Web Open Font Format)</a></td>
<td>.woff</td>
</tr>
<tr>
<th>"truetype"</th>
<td><a href="https://www.microsoft.com/typography/otspec/default.htm">TrueType</a></td>
<td>.ttf</td>
</tr>
<tr>
<th>"opentype"</th>
<td><a href="https://www.microsoft.com/typography/otspec/default.htm">OpenType</a></td>
<td>.ttf, .otf</td>
</tr>
<tr>
<th>"embedded-opentype"</th>
<td><a href="https://www.w3.org/Submission/2008/SUBM-EOT-20080305/">Embedded OpenType</a></td>
<td>.eot</td>
</tr>
<tr>
<th>"svg"</th>
<td><a href="https://www.w3.org/TR/SVG/fonts.html">SVG Font</a></td>
<td>.svg, .svgz</td>
</tr>
<tr>
<th>"woff-variations"</th>
<td><a href="https://www.w3.org/TR/WOFF/">WOFF (Web Open Font Format) with associated variations support</a></td>
<td>.woff</td>
</tr>
<tr>
<th>"truetype-variations"</th>
<td><a href="https://www.microsoft.com/typography/otspec/default.htm">TrueType with associated variations support</a></td>
<td>.ttf</td>
</tr>
<tr>
<th>"opentype-variations"</th>
<td><a href="https://www.microsoft.com/typography/otspec/default.htm">OpenType with associated variations support</a></td>
<td>.ttf, .otf</td>
</tr>
</tbody>
</table>
Given the overlap in common usage between TrueType and OpenType, the
format hints "truetype" and "opentype" must be considered as synonymous;
a format hint of "opentype" does not imply that the font contains
Postscript CFF style glyph data or that it contains OpenType layout
information (see <a href="#platform-props-to-css">Appendix A</a> for more background on this).
A value of "woff-variations", "truetype-variations", or "opentype-variations" imply support
of the "woff", "truetype", or "opentype" formats respectively along with additional support for
font variations. Web authors can specify this format to indicate that variation support is required
for correct rendering of a font. This mechanism can be used for gracefully falling back to an
ancillary font when variation support is not present.
When authors would prefer to use a locally available
copy of a given font and download it if it's not, <code>local()</code>
can be used. The locally-installed 'font-face-name'
argument to <code>local()</code> is a format-specific string that
uniquely identifies a single font face within a larger family. The
syntax for a 'font-face-name' is a unique font face
name enclosed by "local(" and ")". The name can optionally be
enclosed in quotes. If unquoted, the unquoted font family name
processing conventions apply; the name must be a sequence of
identifiers separated by <a href="https://www.w3.org/TR/css3-syntax/#whitespace">whitespace</a>
which is converted to a string by joining the identifiers together
separated by a single space.
<pre>
/* regular face of Gentium */
@font-face {
font-family: MyGentium;
src: local(Gentium), /* use locally available Gentium */
url(Gentium.woff); /* otherwise, download it */
}
</pre>
For OpenType and TrueType fonts, this string is used to match only
the Postscript name or the full font name in the name table of locally
available fonts. Which type of name is used varies by platform and
font, so authors should include both of these names to assure proper
matching across platforms. Platform substitutions for a given font
name must not be used.
<pre>
/* bold face of Gentium */
@font-face {
font-family: MyGentium;
src: local(Gentium Bold), /* full font name */
local(Gentium-Bold), /* Postscript name */
url(GentiumBold.woff); /* otherwise, download it */
font-weight: bold;
}
</pre>
Just as a <code>@font-face</code> rule specifies the characteristics of a single font
within a family, the unique name used with <code>local()</code> specifies a single
font, not an entire font family. Defined in terms of
OpenType font data, the Postscript name is found in the font's
<a href="https://www.microsoft.com/typography/otspec/name.htm">name table</a>,
in the name record with nameID = 6 (see
[[!OPENTYPE]] for more details). The Postscript name is the commonly
used key for all fonts on OSX and for Postscript CFF fonts under
Windows. The full font name (nameID = 4) is used as a unique key for
fonts with TrueType glyphs on Windows.
For OpenType fonts with multiple localizations of the full font name, the US
English version is used (language ID = 0x409 for Windows and language ID = 0 for Macintosh)
or the first localization
when a US English full font name is not available (the OpenType
specification recommends that <a
href="https://www.microsoft.com/typography/otspec/recom.htm">all fonts
minimally include US English names</a>). User agents that also match
other full font names, e.g. matching the Dutch name when the current
system locale is set to Dutch, are considered non-conformant. This is
done not to prefer English but to avoid matching inconsistencies across
font versions and OS localizations, since font style names (e.g. "Bold")
are frequently localized into many languages and the set of
localizations available varies widely across platform and font version.
User agents that match a concatenation of family name (nameID = 1) with
style name (nameID = 2) are considered non-conformant.
This also allows for referencing faces that belong to larger
families that cannot otherwise be referenced.
<div class="example">
<p>Use a local font or reference an SVG font in another document:</p>
<pre>
@font-face {
font-family: Headline;
src: local(Futura-Medium),
url(fonts.svg#MyGeometricModern) format("svg");
}
</pre>
<p>Create an alias for local Japanese fonts on different platforms:</p>
<pre>
@font-face {
font-family: jpgothic;
src: local(HiraKakuPro-W3), local(Meiryo), local(IPAPGothic);
}
</pre>
<p>Reference a font face that cannot be matched within a larger family:</p>
<pre>
@font-face {
font-family: Hoefler Text Ornaments;
/* has the same font properties as Hoefler Text Regular */
src: local(HoeflerText-Ornaments);
}
</pre>
<p>Since localized fullnames never match, a document with the header
style rules below would always render using the default serif font, regardless
whether a particular system locale parameter is set to Finnish or not:</p>
<pre>
@font-face {
font-family: SectionHeader;
src: local("Arial Lihavoitu"); /* Finnish fullname for Arial Bold, should fail */
font-weight: bold;
}
h2 { font-family: SectionHeader, serif; }
</pre>
<p>A conformant user agent would never load the font 'gentium.eot' in the
example below, since it is included in the first definition of the 'src' descriptor
which is overridden by the second definition in the same <code>@font-face</code> rule:</p>
<pre>
@font-face {
font-family: MainText;
src: url(gentium.eot); /* for use with older user agents */
src: local("Gentium"), url(gentium.woff); /* Overrides src definition */
}
</pre>
</div>
<h3 id="font-prop-desc">Font property descriptors: the 'font-style', 'font-weight', and 'font-stretch' descriptors</h3>
<pre class='descdef mq'>
Name: font-style
Value: normal | italic | oblique [ <<angle>> | <<angle>>-<<angle>> ] ?
For: @font-face
Initial: normal
</pre>
<pre class='descdef mq'>
Name: font-weight
Value: normal | bold | [ <<number>> | <<number>>-<<number>> ]
For: @font-face
Initial: normal
</pre>
<pre class='descdef mq'>
Name: font-stretch
Value: normal | ultra-condensed | extra-condensed | condensed | semi-condensed |
semi-expanded | expanded | extra-expanded | ultra-expanded | [ <<percentage>> | <<percentage>>-<<percentage>> ]
For: @font-face
Initial: normal
</pre>
These descriptors define the characteristics of a font face and are
used in the process of matching styles to specific faces. For a font
family defined with several <code>@font-face</code> rules, user agents can either
download all faces in the family or use these descriptors to selectively
download font faces that match actual styles used in document. The
meaning of the values for these descriptors are the same as those for the corresponding
font properties except that relative keywords are not allowed, 'bolder' and
'lighter'. If these descriptors are omitted, initial
values are assumed. If specified values are out of range of the accepted values
of the property of the same name, the descriptor is treated as a parse error.
Ranges are accepted in these three descriptors in place of a single value. Where a single
value is specified, it has the same meaning as a range with identical startpoint and
endpoint. User agents may swap the computed value of the startpoint and endpoint of the range
in order to forbid decreasing ranges. Both endpoints are inclusive.
The ranges are used in the <a href="#font-matching-algorithm">Font Matching Algorithm</a> below.
The value for these font face style attributes is used in place of
the style implied by the underlying font data. This allows authors to
combine faces in flexible combinations, even in situations where the
original font data was arranged differently. User agents that implement
synthetic bolding and obliquing must only apply synthetic styling in
cases where the font descriptors imply this is needed, rather than based
on the style attributes implied by the font data.
<div class="example">
<p>The font descriptors defined in this section are used for selecting a font
from within the set of fonts defined by <code>@font-face</code> rules for
a given family.</p>
<p>Consider a family containing a single, regular face:</p>
<pre>
@font-face {
font-family: BaskervilleSimple;
src: url(baskerville-regular.woff);
}
</pre>
<p>Unstyled text would display using the regular face defined in the
<code>@font-face</code> rule:</p>
<div class="figure"><img alt="regular face display" src="fiddlesticks-regular.png" width="373" /></div>
<p>However, italic text would display in most user agents using synthetically
obliqued glyphs from the regular face, since a separate italic face is not defined:</p>
<div class="figure"><img alt="synthetic italics display" src="fiddlesticks-synitalics.png" width="373" /></div>
<p>Now consider a family for which an actual italic face is defined:</p>
<pre>
@font-face {
font-family: BaskervilleFull;
src: url(baskerville-regular.woff);
}
@font-face {
font-family: BaskervilleFull;
src: url(baskerville-italic.woff);
font-style: italic;
}
</pre>
<p>The second <code>@font-face</code> rule defines the font resource
<code>baskerville-italic.woff</code> to have style attributes of
normal weight, normal stretch and italic style. When displaying italic
text, the user agent will use this font, since it's the closest
match for italic text. Thus, the text will display using glyphs
designed by a type designer rather than using synthetically obliqued
glyphs from the regular face:</p>
<div class="figure"><img alt="real italics display" src="fiddlesticks-italics.png" width="373" /></div>
<p>See the section on <a href="#font-style-matching">font matching</a>
for more complete details of the process used to select a particular
face within a font family.</p>
</div>
<h2 id="font-matching-algorithm">Font Matching Algorithm</h2>
The algorithm below describes how fonts are associated with
individual runs of text. For each character in the run a font
family is chosen and a particular font face is selected
containing a glyph for that character.
<h3 id="font-family-casing">Case sensitivity of font family names</h3>
As part of the font matching algorithm outlined below, user agents must
match font family names used in style rules with actual font family names
contained in fonts available in a given environment or with font family names defined in
<code>@font-face</code> rules. User agents must match these names case
insensitively, using the "Default Caseless Matching" algorithm outlined
in the Unicode specification [[!UNICODE]]. This algorithm is detailed
in section 3.13 entitled "Default Case Algorithms". Specifically, the
algorithm must be applied without normalizing the strings involved and
without applying any language-specific tailorings. The case folding
method specified by this algorithm uses the case mappings with status field
"C" or "F" in the CaseFolding.txt file of the Unicode Character Database.
<p class="note">
For authors this means that font family names are matched case
insensitively, whether those names exist in a platform font or
in the <code>@font-face</code> rules contained in a stylesheet.
Authors should take care to ensure that names use a character sequence
consistent with the actual font family name, particularly when using
combining characters such as diacritical marks. For example, a family
name that contains an uppercase A (U+0041) followed by a combining
ring (U+030A) will <strong>not</strong> match a name that looks
identical but which uses the precomposed lowercase a-ring character
(U+00E5) instead of the combining sequence.</p>
<p class="note">
Implementors should take care to verify that a given caseless string comparison
implementation uses this precise algorithm and not assume that a given
platform string matching routine follows it, as many of these have
locale-specific behavior or use some level of string normalization.</p>
<h3 id="font-style-matching">Matching font styles</h3>
The procedure for choosing a font for a given character in a run of
text consists of iterating over the font families named by the 'font-family' property, selecting
a font face with the appropriate style based on other font properties
and then determining whether a glyph exists for the given character.
This is done using the <dfn>character map</dfn> of the font, data
which maps characters to the default glyph for that character. A font
is considered to <dfn>support</dfn> a given character if (1) the
character is contained in the font's <em>character map</em> and (2) if
required by the containing script, shaping information is available
for that character.
Some legacy fonts may include a given character
in the <em>character map</em> but lack the shaping information (e.g.
<a href="https://www.microsoft.com/typography/otspec/ttochap1.htm">OpenType layout tables</a> or
<a href="https://scripts.sil.org/cms/scripts/page.php?site_id=projects&item_id=graphite_techAbout">Graphite tables</a>)
necessary for correctly rendering text runs containing that character.
Codepoint sequences consisting of a base character followed by a
sequence of combining characters are treated slightly differently, see
the section on <a href="#cluster-matching">cluster matching</a>
below.
For this procedure, the <dfn>default face</dfn> for a given font
family is defined to be the face that would be selected if all font
style properties were set to their initial value.
<ol id="fontmatchingalg">
<li>Using the computed font property values for a given element,
the user agent starts with the first family name
specified by the 'font-family' property.
</li>
<li>If the family name is a generic family keyword, the user agent
looks up the appropriate font family name to be used. User
agents may choose the generic font family to use based on the
language of the containing element or the Unicode range of the
character.
</li>
<li>For other family names, the user agent attempts to find the
family name among fonts defined via <code>@font-face</code> rules and then
among available system fonts, matching names with a
<a href="#font-family-casing">case-insensitive comparison</a> as outlined
in the section above.
On systems containing fonts with multiple localized font family
names, user agents must match any of these names independent of the
underlying system locale or platform API used. If the font
resources defined for a given face in an <code>@font-face</code> rule are either
not available or contain invalid font data, then the face should be
treated as not present in the family. If no faces are present for a
family defined via <code>@font-face</code> rules, the family should be treated as
missing; matching a platform font with the same name must not occur
in this case.
</li>
<li>If a font family match occurs, the user agent assembles the set
of font faces in that family and then narrows the set to a single
face using other font properties in the order given below. Fonts may
present in this group which can support a range of
'font-stretch', 'font-style', or 'font-weight' properties. In
this case, the algorithm proceeds as if each supported combination of
values are a unique font in the set. If such a font is ultimately
selected by this algorithm, particular values for
'font-stretch', 'font-style', and 'font-weight' must be applied
before any layout or rendering occurs. The application of these values
must be applied in the <a href="#apply-font-matching-variations">Apply
font matching variations</a> step detailed in
<a href="#font-feature-variation-resolution">Font Feature and Variation
Resolution</a>.
A group
of faces defined via <code>@font-face</code> rules with identical font
descriptor values but differing 'unicode-range' values are considered to be
a single <dfn>composite face</dfn> for this step:
<ol id="fontstylematchingalg">
<li>'font-stretch' is tried first. If a font
does not have any concept of varying strengths of stretch values, its stretch value
is mapped according table in the <a href="#stretchmappings">property definition</a>.
If the matching set includes faces with width values
containing the 'font-stretch' desired value, faces with other width
values are removed from the matching set. If there is no face
which contains the desired value, a stretch value is chosen using the rules below:
<ul>
<li>If the desired stretch value is less than 100, stretch values below the
desired stretch value are checked in descending order followed by
stretch values above the desired stretch value in ascending order until a
match is found.</li>
<li>Otherwise, stretch values above the
desired stretch value are checked in ascending order followed by
stretch values below the desired stretch value in descending order until a
match is found.</li>
</ul>
Once the
closest matching width has been determined by this process,
faces with widths which do not include this determined width are removed from the matching set.
</li>
<li>'font-style' is tried next.
If the value of 'font-style' is 'italic', italic faces are
checked first, then oblique, then normal faces. If the value
is 'oblique', oblique faces are checked first, then italic
faces and then normal faces. If the value is 'normal',
normal faces are checked first, then oblique faces, then
italic faces. When checking oblique faces, an oblique angle is chosen using the rules below:
<ul>
<li>If the desired oblique angle is greater than or equal to 0deg and less than 20deg, oblique angles below the
desired oblique angle are checked in descending order until 0deg or a negative value is reached. Next, oblique angles above the
desired oblique angle are checked in ascending order.</li>
<li>If the desired oblique angle is greater than or equal to 20deg, oblique angles greater than
the desired oblique angle are checked in ascending order. Next, oblique angles less than or equal to 20deg
are checked in descending order until 0deg or a negative value is reached.
<li>Otherwise, the same steps as above are performed, substituting negative values for the positive ones above.</li>
</ul>
During this operation, if an oblique font does not have any concept of varying oblique angles, it is assumed to have an angle of 20deg.
If the search for a normal or italic face successfully determined a font, faces with other style values are excluded
from the matching set. Otherwise, if the search for an oblique face successfully determined a font, fonts with oblique angles which do not include
this determined angle are excluded from the matching set. User agents are permitted to
distinguish between italic and oblique faces within platform
font families but this is not required, so all
italic or oblique faces may be treated as italic faces or oblique faces with an angle of 20deg. However, within font
families defined via <code>@font-face</code> rules, italic and oblique
faces must be distinguished using the value of the
'font-style' descriptor.
For families that lack any italic or oblique faces, users agents
may create artificial oblique faces, if this is permitted by the
value of the 'font-synthesis' property.
</li>
<li>'font-weight' is matched
next. If a font
does not have any concept of varying strengths of weights, its weight
is mapped according list in the <a href="#font-weight-numeric-values">property definition</a>.
If bolder/lighter relative weights are used, the
effective weight is calculated based on the inherited weight
value, as described in the definition of the 'font-weight'
property. Given the desired weight and the weight ranges of faces
in the matching set after the steps above, if the desired
weight is available inside the weight range of a font in the matching set, then that face matches. Otherwise, a weight
is chosen using the rules below:
<ul>
<li>If the desired weight is 400, 500 is checked first and then
the rule for desired weights less than 450 is used.</li>
<li>If the desired weight is 500, 400 is checked first and then
the rule for desired weights less than 450 is used.</li>
<li>If the desired weight is less than 450, weights below the
desired weight are checked in descending order followed by
weights above the desired weight in ascending order until a
match is found.</li>
<li>If the desired weight is greater than or equal to 450 and not
equal to 500, weights above the
desired weight are checked in ascending order followed by
weights below the desired weight in descending order until a
match is found.</li>
</ul>
Once the closest matching weight has been determined by this process,
faces with weights which do not include this determined width are removed from the matching set.
</li>
<li>'font-size' must be
matched within a UA-dependent margin of tolerance. (Typically, sizes
for scalable fonts are rounded to the nearest whole pixel, while the
tolerance for bitmapped fonts could be as large as 20%.) Further
computations, e.g., by 'em' values in other properties, are based on
the 'font-size' value that
is used, not the one that is specified.
</li>
</ol>
Note that more than one font may be remaining in the matching set after performing
the above steps. If so, the user agent must choose a single font from
the matching set and continue these steps with it. The choice of which
font to choose may differ between multiple user agents and multiple operating
system platforms; however, it must not differ between two elements in the same document.
</li>
<li><p>If the matched face is defined via <code>@font-face</code>
rules, user agents must use the procedure below to select a single
font:
<ol>
<li>If the font resource has not been loaded and the range of
characters defined by the 'unicode-range' descriptor value
includes the character in question, load the font.</li>
<li>After downloading, if the <em>effective character map</em>
supports the character in question, select that font.</li>
</ol>
<p>When the matched face is a <em>composite face</em>, user agents must use
the procedure above on each of the faces in the <em>composite face</em> in
reverse order of <code>@font-face</code> rule definition.</p>
<p>While the download occurs, user agents may either wait until the
font is downloaded or render once with substituted font metrics and
render again once the font is downloaded.</p>
</li>
<li><p>If no matching face exists or the matched face does not contain
a glyph for the character to be rendered, the next family name is
selected and the previous three steps repeated. Glyphs from other
faces in the family are not considered. The only exception is that
user agents may optionally substitute a synthetically obliqued version of the
<em>default face</em> if that face supports a given glyph and synthesis
of these faces is permitted by the value of the 'font-synthesis' property.
For example, a synthetic italic version of the regular face may be used if the
italic face doesn't support glyphs for Arabic.</p>
<!-- resolution on the above: http://lists.w3.org/Archives/Public/www-style/2012Nov/0292.html -->
<li>If there are no more font families to be evaluated and no matching
face has been found, then the user agent performs a <dfn>system font
fallback</dfn> procedure to find the best match for the character to be
rendered. The result of this procedure may vary across user agents.
</li>
<li>If a particular character cannot be displayed using any
font, the user agent should indicate by some means that a
character is not being displayed, displaying either a
symbolic representation of the missing glyph (e.g. using a <a
href="https://en.wikipedia.org/wiki/Last_resort_font">Last
Resort Font</a>) or using the missing character glyph from
a default font.
</li>
</ol>
<p>Optimizations of this process are allowed provided that an
implementation behaves as if the algorithm had been followed exactly.
Matching occurs in a well-defined order to ensure that the results are
as consistent as possible across user agents, given an identical set
of available fonts and rendering technology.</p>
<p>The <dfn>first available font</dfn>, used in the definition of
<a href="https://www.w3.org/TR/css3-values/#font-relative-lengths"><em>font-relative lengths</em></a>
such as 'ex' and 'ch', is defined to be the first available font that
would match any character given font families in the 'font-family'
list (or a user agent's default font if none are available).</p>
<h3 id="cluster-matching">Cluster matching</h3>
Issue: Import from level 3
<h2 id="font-feature-variation-resolution">Font Feature and Variation Resolution</h3>
As described in the previous section, font features and variations can be enabled
in a variety of ways, either via the use of 'font-variant',
'font-feature-settings', 'font'
'font-variation-settings' in a style rule or within an <code>@font-face</code> rule.
The resolution order for the union of these settings is defined below.
Features defined via CSS properties are applied on top of layout engine
default features.
<h3 id="default-features">Default features</h3>
For OpenType fonts, user agents must enable the default features defined
in the OpenType documentation for a given script and writing mode. Required ligatures,
common ligatures and contextual forms must be enabled by default
(OpenType features: <span class="tag">rlig, liga, clig, calt</span>),
along with localized forms (OpenType feature: <span class="tag">locl</span>),
and features required for proper display of composed characters and marks
(OpenType features: <span class="tag">ccmp, mark, mkmk</span>). These features
must always be enabled, even when the value of the
'font-variant' and 'font-feature-settings' properties is 'normal'.
Individual features are only disabled when explicitly overridden by the author, as when
'font-variant-ligatures' is set to 'no-common-ligatures'.
For handling complex scripts such as
<a href="https://www.microsoft.com/typography/otfntdev/arabicot/features.aspx">Arabic</a>,
<a href="https://www.microsoft.com/typography/otfntdev/mongolot/features.htm">Mongolian</a> or
<a href="https://www.microsoft.com/typography/otfntdev/devanot/features.aspx">Devanagari</a>
additional features are required. For upright text within vertical text runs, vertical
alternates (OpenType feature: <span class="tag">vert</span>) must be enabled.</p>