Re: [csswg-drafts] [css-fonts] Clarify how the computed font-size is determined for size keyword (#3906)

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.`

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


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3906#issuecomment-498793666 using your GitHub account

Received on Tuesday, 4 June 2019 18:42:19 UTC