Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-fonts] Clarify how the computed font-size is determined for size keyword #3906

Open
fred-wang opened this issue May 10, 2019 · 13 comments

Comments

Projects
None yet
@fred-wang
Copy link

commented May 10, 2019

cc @emilio @rwlbuis @bkardell @bfgeek

Spec: https://drafts.csswg.org/css-fonts-4/#font-size-prop

For example Emilio gave me this example:

  <div style="font-family: serif">Serif <div style="font-family: monospace">mono</div></div>

The first div has size 16px and the second 13px in all browsers. font-size on them is the default "medium" value. Compare with:

  <div style="font-size: 16px"><div style="font-family: serif">Serif <div style="font-family: monospace">mono</div></div></div>

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

@fred-wang

This comment has been minimized.

Copy link
Author

commented May 10, 2019

(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.)

@litherum

This comment has been minimized.

Copy link
Contributor

commented May 10, 2019

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
@emilio

This comment has been minimized.

Copy link
Collaborator

commented May 10, 2019

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:

https://searchfox.org/mozilla-central/rev/b9da45f63cb567244933c77b2c7e827a057d3f9b/servo/components/style/values/specified/font.rs#728

/cc @jfkthame

@AmeliaBR

This comment has been minimized.

Copy link
Contributor

commented May 10, 2019

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.

@dbaron

This comment has been minimized.

Copy link
Member

commented Jun 2, 2019

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
@Manishearth

This comment has been minimized.

Copy link
Contributor

commented Jun 2, 2019

This is basically a dupe of #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)

fred-wang added a commit to web-platform-tests/wpt that referenced this issue Jun 3, 2019

Add a tentative reftest to check how math-script-level and font-famil…
…y interacts on font-size change. This is related to w3c/csswg-drafts#3906

svgeesus added a commit to web-platform-tests/wpt that referenced this issue Jun 4, 2019

Add new tests for CSS properties math-style and math-script-level (#1…
…7100)

* Add tests for new CSS property math-style.

* Add tests for CSS property math-script-level

* Add tests using scaling factors from the MATH table.

* Improve coverage of math-script-level-004:
- Test scaling without MATH font.
- Test scaling up and down.
- Test all transitions between levels -3, -1, 0, 1, 2, 3, 5.

* Add tests to check issue #3739 and interaction with script-level.

* Add a tentative reftest to check how math-script-level and font-family interacts on font-size change. This is related to w3c/csswg-drafts#3906
@svgeesus

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2019

@fred-wang

This comment has been minimized.

Copy link
Author

commented Jun 4, 2019

Tests now on WPT

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.

@svgeesus

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2019

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.

@svgeesus

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2019

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.

@emilio

This comment has been minimized.

Copy link
Collaborator

commented Jun 4, 2019

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.

@litherum litherum added the Needs Edits label Jun 4, 2019

@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented Jun 4, 2019

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.
The full IRC log of that discussion <TabAtkins> Topic: Clarify how computed font-size is determined for size keyword
<astearns> github: https://github.com//issues/3906
<fantasai> ACTION myles Add a note about the font-size: 0px vs min font-size web-compat issue
<trackbot> Created ACTION-879 - Add a note about the font-size: 0px vs min font-size web-compat issue [on Myles Maxfield - due 2019-06-11].
<TabAtkins> myles: I don't think we can get rid of the fact that monospace is special, for webcompat
<TabAtkins> chris: So this is really about the fact that Courier looks too big.
<TabAtkins> chris: And browsers also noticed that CJK fonts can look too big at 16px by default
<TabAtkins> emilio: in gecko we do this based on the generic family specified.
<TabAtkins> myles: So "a, b, serif" gets a different font size than "a, b, monospace"
<TabAtkins> dbaron: Yes, because of the assumption that those fonts are probably monospace as well
<TabAtkins> fremy: As I recall that's not what was implemented by browsers...
<TabAtkins> myles: In WK, we only adjust if you say *only* "monospace"
<TabAtkins> myles: So using font-family to dictate font-size is fundamnetally broken, we all agree
<TabAtkins> [we all agree]
<TabAtkins> myles: So the question is if we shoudl write down exactly how it's broken. it sounds like everyone does it differently
<TabAtkins> dbaron: Given there's incompatibility, there's maybe room to improve this
<fantasai> [emilio describes some details of how this works]
<TabAtkins> dbaron: AT one point I had part of a plan to replace with with font-size-adjust
<TabAtkins> dbaron: Probably not web-compatible, but maybe... Would require new values.
<TabAtkins> fremy: Last I recall Edge didn't do any adjustments, but at some point we got a bug and added new UA rules that only targeted elements that get monospace by default. We don't apply it to the *monospace value* tho.
<fantasai> TabAtkins: We should capture in the property that extra bit of information captured about whether size was specified as a size
<fantasai> TabAtkins: because browsers seem to do something special in that case
<fantasai> AmeliaBR: Keywords are a bit vague anyway
<fantasai> TabAtkins: No flexibility in that they convert to a <length>
<fantasai> TabAtkins: You honor a <length> as a <length>
<fantasai> TabAtkins: But that's not how browsers work
<fantasai> TabAtkins: We might need to keep it underdefined, but at least that there's some thing special going on
<fantasai> fremy: We have interop, so let's spec that
<fantasai> TabAtkins: OK, but let's capture there's something
<fantasai> emilio: Gecko code... when you have multiple families, we behave like WebKit
<fantasai> emilio: Yay interop!
<fantasai> AmeliaBR: so weird behavior, but cross-browser consistent
<fantasai> chris: So how are we resolving?
<TabAtkins> dbaron: The thing this was solving is really a use-case for font-size-adjust
<fantasai> dbaron: Like to say that the thing this was soliving is a use case for font-size-adjust
<TabAtkins> dbaron: I'd like to encourage the negine that doesn't ipmlement f-s-a to do that.
<fantasai> dbaron: Would like engine that doesn't implement font-size-adjust that doesn't implement it to fix it
<fantasai> dbaron: It's ugly because it's designed to be compatible with its non-existence
<fantasai> dbaron: It's a way of saying "i want to specify font-size in terms of x-height instead of font-size"
<chris> https://developer.mozilla.org/en-US/docs/Web/CSS/font-size-adjust#Browser_compatibility
<TabAtkins> astearns: So it sound slike proposal is to acknowledge reality in font-size property that it makes font-sizes strange.
<TabAtkins> astearns: And at minimum capture "it's strange" in the spec.
<dbaron> oh, actually, font-size-adjust may be behind the experimental web platform features flag in Chrome...
<fantasai> TabAtkins: Let's capture that keywords come with extra bit of info
<fantasai> TabAtkins: And also investigate if there's compat, andif so spec that
<fantasai> myles_: sgtm
<TabAtkins> astearns: Is there someone volunteering to do the investigation?
<TabAtkins> fremy: I volunteer.
<TabAtkins> astearns: proposal: acknowledge reality that font-size keywords have some weirdness with particular generic font families.
<TabAtkins> RESOLVED: Capture that font-size keywords carry an additional bit of information having some (unspecified) interaction with some font families.
<TabAtkins> astearns: Second is to deputize françois to try and capture what the weirdness is
<TabAtkins> RESOLVED: François does compat research on the effect of font-size keywords and generic font-families, and report back on interop.
@FremyCompany

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2019

(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: #1835 (comment))

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jun 19, 2019

Bug 1555718 [wpt PR 17100] - Add new tests for CSS properties math-st…
…yle and math-script-level , a=testonly

Automatic update from web-platform-tests
Add new tests for CSS properties math-style and math-script-level  (#17100)

* Add tests for new CSS property math-style.

* Add tests for CSS property math-script-level

* Add tests using scaling factors from the MATH table.

* Improve coverage of math-script-level-004:
- Test scaling without MATH font.
- Test scaling up and down.
- Test all transitions between levels -3, -1, 0, 1, 2, 3, 5.

* Add tests to check issue #3739 and interaction with script-level.

* Add a tentative reftest to check how math-script-level and font-family interacts on font-size change. This is related to w3c/csswg-drafts#3906

--

wp5At-commits: 90d09993c72864735e76cf4d5f152436273ffdcd
wpt-pr: 17100

xeonchen pushed a commit to xeonchen/gecko that referenced this issue Jun 19, 2019

Bug 1555718 [wpt PR 17100] - Add new tests for CSS properties math-st…
…yle and math-script-level , a=testonly

Automatic update from web-platform-tests
Add new tests for CSS properties math-style and math-script-level  (#17100)

* Add tests for new CSS property math-style.

* Add tests for CSS property math-script-level

* Add tests using scaling factors from the MATH table.

* Improve coverage of math-script-level-004:
- Test scaling without MATH font.
- Test scaling up and down.
- Test all transitions between levels -3, -1, 0, 1, 2, 3, 5.

* Add tests to check issue #3739 and interaction with script-level.

* Add a tentative reftest to check how math-script-level and font-family interacts on font-size change. This is related to w3c/csswg-drafts#3906

--

wp5At-commits: 90d09993c72864735e76cf4d5f152436273ffdcd
wpt-pr: 17100
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.