- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Aug 2021 16:46:02 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `aliasing display-legacy at parse-time`, and agreed to the following: * `RESOLVED: these values compute to each other and thus serialize as "shortest most backwards-compatible" which is the older keywrods` * `RESOLVED: serialize specified value of display using keywords specified` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: aliasing display-legacy at parse-time<br> <fantasai> ScribeNick: fantasai<br> <fantasai> github: https://drafts.csswg.org/css-backgrounds-3/spread-radius<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5575#issuecomment-893899115<br> <fantasai> TabAtkins: Awhile ago, Oriol brought up that we have the short display values like inline-block, inline-table, etc.<br> <fantasai> TabAtkins: after attempt of splitting display property and then re-unifying<br> <fantasai> TabAtkins: we have two-keyword values<br> <fantasai> TabAtkins: question was whether these two ways of writing the same value should be canonicalized at parse time or some other time<br> <fantasai> TabAtkins: Argument for canonicalizing at parse time is that code written before these values were valid, might be expecting inline-foo pattern<br> <fantasai> TabAtkins: if author writes 'inline flow-root' for some reason, that code wont correctly respond<br> <fantasai> TabAtkins: counter-argument is that it can be confusing when we return something different from what author wrote, especially for specified values<br> <fantasai> TabAtkins: and code written in the past will continue to work, just not with the new syntax<br> <fantasai> TabAtkins: and that code wouldn't work for new display values in any case<br> <fantasai> TabAtkins: fantasai and I come down on the side of not canonicalizing at specified-value time<br> <fantasai> TabAtkins: It doesn't create Web-compat issues<br> <emilio> q+<br> <fantasai> TabAtkins: and it lets authors work in the syntax they specified<br> <fantasai> emilio: is proposal to canonicalize at computed value time?<br> <fantasai> fantasai: Don't we have a requirement for shortest-serialization for getComputedStyle?<br> <fantasai> TabAtkins: separate question<br> <fantasai> emilio: It's very easy to check for one and not the other<br> <fantasai> emilio: I think it's better to canonicalize at parse time<br> <fantasai> TabAtkins: It sounds like you're saying that canonicalize to happen at some point, and while prefer at specified value but ok if only at computed value?<br> <fantasai> iank_: Not concerned about Web compat?<br> <fantasai> emilio: I am, but figure they're accounted for?<br> <fantasai> iank_: I don't think anyone's done research on this<br> <fantasai> iank_: If Firefox implements this and it breaks or doesn't break a bunch of sites...<br> <fantasai> TabAtkins: not canonicalizing can't have Web-compat impact, because legacy code written with inline-block will still return inline-block<br> <fantasai> TabAtkins: New code written against old libraries would not work maybe, but that's not compat<br> <fantasai> emilio: Firefox has shipped the new syntax for awhile now<br> <fantasai> emilio: so could have compat<br> <fantasai> emilio: I don't think it's super useful not to canonicalize<br> <fantasai> emilio: useful for authors that write JS code and browsers<br> <fantasai> astearns: I suspect whether or not we canonicalize at parse time is much less web compat concern than if we do it at computed-value time<br> <fantasai> astearns: but there's argument of if computed-value is simplified, might be simpler to do it at parse time<br> <fantasai> iank_: whether we do it at parse time...<br> <fantasai> TabAtkins: fwiw, I agree that at computed value time they should be canonicalized, because they are in effect the same value, and shortest serialization would require it<br> <fantasai> iank_: Are we ok with backing out if there's a compat problem?<br> <fantasai> emilio: this proposed resolution is the behavior of the only existing implementation<br> <fantasai> TabAtkins: yeah, so this is completely web-compatible if anything can be<br> <fantasai> fantasai: The existing rule is "shortest most backwards-compatible serialization"<br> <fantasai> astearns: So want to be clear that they're the same<br> <fantasai> RESOLVED: these values compute to each other and thus serialize as "shortest most backwards-compatible" which is the older keywrods<br> <fantasai> TabAtkins: 2 objections to canonicalizing at parse time<br> <fantasai> TabAtkins: First, specified value should reflect what the author spadi<br> <fantasai> TabAtkins: if put .style="inline flow-root" should get that back when request it<br> <fantasai> TabAtkins: Also, canonicalizing back out would make it harder to split back out into two longhands<br> <fantasai> emilio: I don't see why<br> <fantasai> fantasai: when teaching CSS, Jen and Rachel have found the split keyword syntax useful for explaining the difference between inner and outer display roles<br> <jensimmons> yup to useful for teaching. Once they are in every single browser everywhere, I expect developers to start using them exclusively. (AKA, 2027?)<br> <fantasai> fantasai: If they disappear from the OM as soon as they're inputted, that creates a strong bias against using them, they're not so real anymore<br> <fantasai> [missed exchange]<br> <fantasai> emilio: I don't feel super-strongly, can compromise at computed-value time<br> <fantasai> emilio: I think it's weird one way or the other<br> <fantasai> emilio: computed value of 'display' is more looked-up than specified value<br> <fantasai> TabAtkins: in general specified values aren't looked at too much anyway, unless looking at value of style attribute<br> <fantasai> emilio: I don't see this as super useful, but if fantasai disagrees, it's OK I trust her<br> <astearns> ack emilio<br> <fantasai> jensimmons: I haven't been completely following, but +1 to what fantasai said<br> <fantasai> jensimmons: about the syntax of inner and outer is super useful<br> <fantasai> jensimmons: teaching now, and later once all browser support it, will likely switch to it<br> <fantasai> emilio: but if we serialize into old syntax, doesn't seem so useful?<br> <fantasai> emilio: serializing the old value increases time to adoption, while serilizing the new value which is nicer, but...<br> <fantasai> astearns: I do agree with Tab's first point, that we do try to keep the serialization of specified values as close to what author inputted as possible<br> <fantasai> astearns: and sounds like Emilio is OK with that, and didn't hear concerns about having specified vs computed being different<br> <fantasai> astearns: so proposed resolution is that for specified values we serialize as written<br> <fantasai> astearns: and for ocmputed value, we canonicalize<br> <fantasai> emilio: not quite as written, if you write "inline flow"... do you want to serialize to "inline"?<br> <fantasai> emilio: nevermind<br> <fantasai> emilio: sounds OK<br> <fantasai> jensimmons: Not sure what issue is, but if this affects what appears in the computed panel in devtools, idea of browsers saying "I took old value for you and put it into the new style" that would be a good thing<br> <fantasai> emilio: The computed panel, you can put whatever there. Doesn't affect specified.<br> <fantasai> jensimmons: I think what happens in parsing engine, nobody knows, doesn't matter to authors<br> <fantasai> astearns: So can we resolve?<br> <fantasai> RESOLVED: serialize specified value of display using keywords specified<br> <bradk> +1<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5575#issuecomment-901267267 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 August 2021 16:46:04 UTC