Open fred-wang opened 5 years ago
(Note: This is blocking #3746 ; we need to decide how the computed font-size is calculated if in addition one of these inner divs have a script level change.)
WebKit has:
defaultFontSize:
type: int
initial: 16
onChange: setNeedsRecalcStyleInAllFrames
defaultFixedFontSize:
type: int
initial: 13
onChange: setNeedsRecalcStyleInAllFrames
and also:
bool useFixedDefaultSize() const { return familyCount() == 1 && firstFamily() == monospaceFamily; }
The rest of the relevant code is here.
The WebKit logic is therefore "if font-family
has one item and its name is monospace
then its font size get sets according to this table:"
CSS size keyword | Font size |
---|---|
xx-small |
9 |
x-small |
10 |
small |
12 |
medium |
13 |
large |
16 |
x-large |
20 |
xx-large |
26 |
-webkit-xxx-large |
39 |
Else, its font size get sets according to this table:
CSS size keyword | Font size |
---|---|
xx-small |
9 |
x-small |
10 |
small |
13 |
medium |
16 |
large |
18 |
x-large |
24 |
xx-large |
32 |
-webkit-xxx-large |
48 |
In Gecko it's a bit more complex than that and it also depends on the language group.
The default values for those user settings are here, but you can really configure it as you want.
So in Gecko this for example will still render the mono
text with 16px font-size for zh-HK
by default: data:text/html, <div style="font-family: serif">Serif <div lang="zh-HK" style="font-size: monospace">mono</div></div>
.
Other than that the logic is similar to WebKit. If there's a single generic font-family, then we get the base font-size for that generic, otherwise we use the variable
font-size (which is 16px by default). Then with that base size we apply a similar mapping to WebKit:
/cc @jfkthame
Most browsers have special legacy font-size rules for font-family: monospace
that disappear with any other font-family
declaration (even if the used font-family is the same), so it's worth separating out the main discussion from those quirks.
But that said, the presence of those quirks mean that font-size: normal
doesn't have an absolute translation to px values throughout the page.
Gecko used to have relatively complicated code to handle the case where a descendant inherited a font size or used a %
, em
, etc., font size while being different from its ancestor in terms of monospace
or not, which would try to redo the font size computation from the nearest absolute ancestor as monospace or not. I think much of that code is gone (cc @Manishearth) but I don't remember for sure.
I'd also note that a number of years ago I had a proposal for replacing these separate font size preferences for monospace
and non-monospace
with a new value of font-size-adjust
.
Gecko's defaults appear to be (at a quick skim, hopefully I didn't miss anything):
script (of tagged language or language detected from encoding) | variable size | monospace size |
---|---|---|
western, cyrillic, ar, el, he, "unicode" (undetected) | 16 | 13 on mac/win, 12 on linux/android |
ja, ko, zh-CN, zh-HK, zh-TW | 16 | 16 |
th, devanagari, tamil, armn, beng, cans, ethi, geor, gujr, guru, khmr, mlym, orya, telu, knda, sinh, tibt, math | 16 | 13 |
This is basically a dupe of https://github.com/w3c/csswg-drafts/issues/1835 . Given that Edge uses Blink now I think we should revisit this.
Note that Chrome supports language-dependent font sizes too, the functionality is just not exposed by default.
I think much of that code is gone (cc @Manishearth) but I don't remember for sure.
The code is much simpler now (it doesn't recascade), but it has the same effects. Basically, if a font-size is computed from a keyword value, including things like "50% of medium", or "2em on large" (or calc values), we store the origin of it as a keyword + calc. If the lang or family changes, we recompute the keyword for the new lang/family values and then apply the calc to get the new font size.
(The old code would walk up the tree and redo the cascade, which was complicated. Now we cascade additional state and the cascade code for font-size is slightly more complex. There may be slight behavioral differences when it comes to some edge cases with MathML scriptminsize
but you really have to try)
Note that these are tests related to #3746 ; probably some dedicated font-size/font-family tests independent from math-script-level should be written too.
Note that these are tests related to #3746 ; probably some dedicated font-size/font-family tests independent from math-script-level should be written too.
Yes they should, but I wanted those approved so people can look at them during the discussion.
A quick CodePen showing results for Japanese, Traditional Chinese, and unspecified language
In Safari and Firefox, Japanese and Chinese monospaced both end up 16px . In Chrome, Chinese does but Japanese does not.
I was wrong about Firefox's behavior and we don't get the "first generic family", but only if it's just one: https://searchfox.org/mozilla-central/rev/9eb2f739c165b4e294929f7b99fbb4d90f8a396b/servo/components/style/values/computed/font.rs#537
So it's sort-of compatible with WebKit.
The CSS Working Group just discussed Clarify how computed font-size is determined for size keyword
, and agreed to the following:
RESOLVED: Capture that font-size keywords carry an additional bit of information having some (unspecified) interaction with some font families.
RESOLVED: François does compat research on the effect of font-size keywords and generic font-families, and report back on interop.
(To help myself in my volunteering effort of providing an updated description of the Webkit/Gecko behavior, here is the last time I talked about this: https://github.com/w3c/csswg-drafts/issues/1835#issuecomment-362025870)
@FremyCompany I assigned you because that June 2019 CSSWG resolution assigned you :)
Also changing the title to CSS Fonts 4
cc @emilio @rwlbuis @bkardell @bfgeek
Spec: https://drafts.csswg.org/css-fonts-4/#font-size-prop
For example Emilio gave me this example:
The first div has size 16px and the second 13px in all browsers. font-size on them is the default "medium" value. Compare with:
Currently, the spec suggests some scale factors but maybe it should make clear that the computed font-size is determined from the computed font-family, lang, user preferences etc