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