Re: [csswg-drafts] [css-font-loading] Browsers disagree on what it means for a FontFace object to be "CSS-connected", and what effect does it have. (#5707)

The CSS Working Group just discussed `[css-font-loading] Browsers disagree on what it means for a FontFace object to be "CSS-connected", and what effect does it have.`, and agreed to the following:

* `RESOLVED: Change css-connected by css created bool where it cannot be unset until removed from a document`
* `RESOLVED: Have it throw an error`
* `RESOLVED: have document.fonts.add when called with css create fontface object throw an error`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-font-loading] Browsers disagree on what it means for a FontFace object to be "CSS-connected", and what effect does it have.<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/5707<br>
&lt;dael> emilio: Browser behave really oddly. Spec-wise spec says FontFace object once the rule is removed you should be able to use like it's not css-connected. A bit messy, browsers don't impl to the letter. Simplier would be if fontface created for a css rule it is concidered css-created. Then impl and spec are simplier<br>
&lt;dael> emilio: Given behavior is all over the place and it's an edge case it would be nice to simplify<br>
&lt;leaverou> fantasai: 1em evaluated against font-size refers to the *parent* font-size, so there's no conflict there. That's *why* we'd evaluate ems against font-size, to avoid that sort of thing<br>
&lt;dael> TabAtkins: What imacts does ti have on the connection between properties if we just make a flag for css-created<br>
&lt;dael> emilio: afaict is chrome and ff don't allow change of descriptor of fontface object. Per spec it's 2-way mapping. I think FF and Chrome don't impl. I don't see an issue with 2-way mapping as is.<br>
&lt;dael> TabAtkins: If keeping the connection I'm unclear what the change is<br>
&lt;fantasai> leaverou, I think it would be super unexpected if you evaluated em against font-size, unless all of the if clause lengths evaluate against the parent or something<br>
&lt;fantasai> s/font-size/parent font-size/<br>
&lt;dael> emilio: Per spec once you removet he rule from the style sheet, even though om wrapper for rule exists, the fontface object is diconnected from it. Means a lot of functions that need to check for css connection need to also update stylesheets and other expensive stuff<br>
&lt;fantasai> leaverou, and in that case, seems a lot less useful?<br>
&lt;dael> TabAtkins: So if you move a cssom fontface object into another stylesheet in another document so it shows in a different fontface set would that make 1 more object<br>
&lt;dael> emilio: afaict you can't do that. cssom method is strings so you need to stringify<br>
&lt;leaverou> fantasai: then the other options are: a) it evaluates differently per property, so you have partial application b) it evaluates against another property, e.g. width, so you have a cycle in font-size.<br>
&lt;dael> TabAtkins: Okay. If purely when an om rule is created it gets a corresponding object and that's a permanent connection I'm okay with that. Simplication. Fine with me<br>
&lt;Rossen_> q?<br>
&lt;dael> emilio: I think so too<br>
&lt;dael> Rossen_: Other opinions?<br>
&lt;dael> Rossen_: Summary?<br>
&lt;dael> emilio: Proposed: Change css-connected by css created bool where it cannot be unset until removed frmo a document<br>
&lt;fantasai> leaverou, sure I recognize those are bad... but also, it seems to me that the use cases would want to evaluate against the element itself<br>
&lt;dael> Rossen_: Objecitons?<br>
&lt;dael> RESOLVED: Change css-connected by css created bool where it cannot be unset until removed from a document<br>
&lt;dael> emilio: Another issue in this. That was changing definition. Now what happens to document.fonts.add with that object<br>
&lt;fantasai> leaverou, if that's not the case and evaluating the parent font size is useful and expected, great, but if not, then making it implementable isn't actually solving the problem<br>
&lt;dael> emilio: It's in the same issue, but needs different resolution<br>
&lt;dael> emilio: it's when it's from a rule created in another document. I think blink does nothing. Spec says throw which is what gecko does. Doesn't match WK or blink. Happy to use either, both are reasonable.<br>
&lt;dael> emilio: It does nothing if called on same document which is odd. I think easiest is follow blink<br>
&lt;dael> TabAtkins: Meaning it doesn't get added to set?<br>
&lt;dael> emilio: Right<br>
&lt;dael> TabAtkins: No opinion on throw or ignore. Whichever<br>
&lt;dael> emilio: I don't care either. Throw to do nothing is a bit easier for use. Doing nothing to throwing may break. No strong opinion. Whatever gets faster interop<br>
&lt;dael> TabAtkins: Seems rare to do this. I suspect we could move to throw and I would prefer because it's an error. Do we have an issue to fix in chrome?<br>
&lt;dael> emilio: I'm okay change to throw<br>
&lt;dael> TabAtkins: I'll try that and talk to Rune. If not we'll come back<br>
&lt;dael> Rossen_: With my TAG hat I'd argue strongly for throwing. There's a pretty clear guidance on this pattern. Should do most observable. Let's not have silent error. I agree with prop<br>
&lt;dael> Rossen_: Objections?<br>
&lt;dael> RESOLVED: Have it throw an error<br>
&lt;dael> RESOLVED: have document.fonts.add when called with css create fontface object throw an error<br>
&lt;leaverou> fantasai: If you look at the use cases wrt WC, none of them really seems to need ems. We just need to define what happens when someone uses it that way. I agree that parent is not that useful, but not sure the alternatives are better. I'm hoping there might be a 4th alternative we haven't considered, but I think the top priority would be to make sure that either the entire @if is applied or none of it, even if some values become less useful in<br>
&lt;leaverou>  conditions.<br>
</details>


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 16 December 2020 17:49:56 UTC