W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2021

Re: [csswg-drafts] [css-variables-1] Custom properties and serialization (#5685)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 29 Jul 2021 22:40:48 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-889506743-1627598447-sysbot+gh@w3.org>
The CSS Working Group just discussed `Custom properties and serialization`, and agreed to the following:

* `RESOLVED: computed value preserves specified value (accept proposed spec)`
* `RESOLVED: registered properties same as normal property (whatever that ends up being)`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: Custom properties and serialization<br>
&lt;fantasai> scribenick: fantasai<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/5685<br>
&lt;fantasai> TabAtkins: question about precise details of earlier resolution about serialization of custom properties<br>
&lt;fantasai> TabAtkins: previously resolved to serialize back exactly as specified<br>
&lt;fantasai> TabAtkins: to avoid compat issues<br>
&lt;fantasai> TabAtkins: where authors would put content into custom properties that wasn't properly parseable with CSS rules<br>
&lt;fantasai> TabAtkins: so if re-emitted with normal CSS normalization, changes content<br>
&lt;fantasai> TabAtkins: e.g. UUIDs sometimes interpreted as scinot<br>
&lt;fantasai> TabAtkins: Question also is, does this apply to computed values/<br>
&lt;fantasai> TabAtkins: In issue, it's reasonably interop that computed values are also preserved as specified<br>
&lt;fantasai> TabAtkins: except that var() functions are substituted<br>
&lt;TabAtkins>     --y: /* baz */;<br>
&lt;TabAtkins>     --x: /* foo */ var(--y) /* bar */;<br>
&lt;fantasai> TabAtkins: Here serialization of --x is three comments in a row<br>
&lt;fantasai> TabAtkins: I've put this in the spec<br>
&lt;fantasai> TabAtkins: Want to make sure rest of group agrees<br>
&lt;emilio> q+<br>
&lt;fantasai> TabAtkins: also side issues, wrt non-custom properties containing var()s<br>
&lt;fantasai> TabAtkins: whether those preserved or not<br>
&lt;fantasai> TabAtkins: and then registered properties<br>
&lt;fantasai> TabAtkins: Wrt computed value of custom properties, though, is that preserved exactly aside from var() substitution?<br>
&lt;Rossen_> q?<br>
&lt;fantasai> astearns: cycles?<br>
&lt;fantasai> TabAtkins: handled separately<br>
&lt;fantasai> emilio: We resolved recently that white space is trimmed<br>
&lt;fantasai> TabAtkins: yes<br>
&lt;fantasai> TabAtkins: by syntax sspec<br>
&lt;fantasai> emilio: aside from that, the rest should be preserved<br>
&lt;Rossen_> ack emilio<br>
&lt;TabAtkins> spec text: https://drafts.csswg.org/css-variables/#serializing-custom-props<br>
&lt;TabAtkins> fantasai: If we're not preserving in computed values it won't inherit correctly; you could munge in serialization but why would you if you ahve to preserve it anyway<br>
&lt;fantasai> TabAtkins: Unless objections, can resolve?<br>
&lt;fantasai> RESOLVED: computed value preserves specified value (accept proposed spec)<br>
&lt;TabAtkins>   color: /* bah */ var(--x);<br>
&lt;fantasai> TabAtkins: Next part is non-custom properties using var()<br>
&lt;fantasai> TabAtkins: Here's an example. Normal serialization rules of color wouldn't preserve comment<br>
&lt;fantasai> TabAtkins: Does this need to be preserved as well? Gecko does, but I don't think Chrome does<br>
&lt;fantasai> TabAtkins: Chrome serializes this as var(--x)<br>
&lt;fantasai> emilio: if it doesn't then what does it do?<br>
&lt;fantasai> Rossen_: probably all comments are dropped for perf<br>
&lt;fantasai> Rossen_: only tokens are kept<br>
&lt;fantasai> Rossen_: would have to go back and specify serialization<br>
&lt;fantasai> emilio: when talking with chrome about this, they don't keep original serialization but the list of tokens that was parsed, and probably they dropped comments<br>
&lt;fantasai> emilio: when serializing need to be careful, insert comments in some cases to preserve tokenization<br>
&lt;fantasai> emilio: in Gecko we preserve<br>
&lt;fantasai> emilio: input as-is<br>
&lt;fantasai> emilio: same rules as custom properties<br>
&lt;fantasai> emilio: we do trim white space<br>
&lt;fantasai> emilio: other than that we keep the whole input as-is<br>
&lt;fantasai> TabAtkins: that doesn't seem to apply when there's not a var()<br>
&lt;fantasai> TabAtkins: only do it when there's a var()?<br>
&lt;heycam> I think it makes sense for this to wkr the same way as custom props themselves<br>
&lt;fantasai> emilio: that and environment variables yes<br>
&lt;heycam> s/wkr/work/<br>
&lt;Rossen_> ack fantasai<br>
&lt;Zakim> fantasai, you wanted to ask why would you want to<br>
&lt;fantasai> fantasai: so I don't undersatnd<br>
&lt;fantasai> fantasai: in the example, if you use red instead of var(), the comment doesn't get serialized<br>
&lt;fantasai> fantasai: why would it get serialized if you replace red with var()?<br>
&lt;fantasai> fantasai: I would find that surprising<br>
&lt;fantasai> emilio: because you need to substitute first in order to tokenize (???)<br>
&lt;fantasai> emilio: if you red there, you know the exact syntax<br>
&lt;fantasai> emilio: keywords in colors are special, we do preserve that in specified value<br>
&lt;fantasai> emilio: we keep an rgba value<br>
&lt;fantasai> emilio: and keep the ident for legacy reasons<br>
&lt;fantasai> TabAtkins: she's saying that, for any other normal property, when you serialize, you serialize out the ?? value<br>
&lt;fantasai> TabAtkins: no direct relation to what author put in<br>
&lt;fantasai> TabAtkins: it's unclear why you're referencing substitution as a reason to keep comments<br>
&lt;fantasai> TabAtkins: this is pre-substitution<br>
&lt;fantasai> TabAtkins: post-substitution<br>
&lt;fantasai> TabAtkins: ...<br>
&lt;fantasai> emilio: other than actual values, we have uncomputed values which are strings<br>
&lt;fantasai> emilio: we could keep lists of tokens, but is kind of tricky<br>
&lt;fantasai> emilio: but if we define something other than what author put in, need to define how to serialize<br>
&lt;fantasai> fantasai: still don't understand why keeping the comment<br>
&lt;fantasai> emilio: if using actual color, it gets parsed<br>
&lt;fantasai> emilio: things that need substitution aren't parsed<br>
&lt;fantasai> fantasai: still isn't making sense to me<br>
&lt;fantasai> Rossen_: if we have substitution rules defined, would you align?<br>
&lt;fantasai> emilio: yes<br>
&lt;fantasai> Rossen_: Tab, would you want to specify?<br>
&lt;fantasai> TabAtkins: both behaviors are allowed by syntax right now<br>
&lt;fantasai> TabAtkins: can preserve comments or toss them<br>
&lt;fantasai> Rossen_: Do we have any compat risk?<br>
&lt;fantasai> TabAtkins: doubt it<br>
&lt;fantasai> Rossen_: do we need to worry about this issue?<br>
&lt;fantasai> Rossen_: or just say it's allowed?<br>
&lt;fantasai> TabAtkins: it's a CSSOM issue at this point<br>
&lt;fantasai> emilio: willing to have interop on this<br>
&lt;fantasai> emilio: would like to understand what chrome and webkit do<br>
&lt;fantasai> emilio: because need to preserve some stufff, but not others<br>
&lt;fantasai> emilio: if you put a UUID and a variable, do you actually serialize integers?<br>
&lt;fantasai> emilio: do you have same problem as custom property?<br>
&lt;fantasai> TabAtkins: if you put UUID into a custom prop and then it goes into normal prop and somehow ends up valid<br>
&lt;fantasai> TabAtkins: then specified eosnt' matter because didn't do substitution<br>
&lt;fantasai> TabAtkins: computed value doesn't matter because substituted already<br>
&lt;fantasai> TabAtkins: ...<br>
&lt;fantasai> emilio: is it useful to have consistent behavior for custom properties and normal properties?<br>
&lt;fantasai> TabAtkins: I think our answer is we parse into token stream, throw out comments, reserialize (and have some errors in cases which needs comments re-inserted)<br>
&lt;fantasai> TabAtkins: could fix those bugs<br>
&lt;fantasai> emilio: do you also toss the comments?<br>
&lt;fantasai> emilio: if you keep number token with integer on it, or do you keep 1e3?<br>
&lt;fantasai> TabAtkins: I dont' remember<br>
&lt;fantasai> emilio: that's the interesting bit. If you serialize what author put in, ff is more consistent<br>
&lt;fantasai> TabAtkins: ok, I'll open a new issue on CSSOM<br>
&lt;TabAtkins> fantasai: for consistency, what i'd expect is that non-custom props are consistent with themselves as much as possible, and customs are self-consistent<br>
&lt;TabAtkins> fantasai: And once you do a substitution that can be consistent with the original serialization rules...<br>
&lt;TabAtkins> fantasai: But outside of that substitution, i wouldn't expect behavior to change, just because a keyword was swapped for a var()<br>
&lt;TabAtkins> fantasai: Seems weird from a user pov<br>
&lt;astearns> +1 to fantasai<br>
&lt;fantasai> TabAtkins: ok, I'll open a new issue on CSSOM<br>
&lt;fantasai> TabAtkins: Registered properties with a syntax, should act the same as a normal property<br>
&lt;fantasai> TabAtkins: I assume that's uncontroversial<br>
&lt;fantasai> emilio: yes<br>
&lt;fantasai> RESOLVED: registered properties same as normal property (whatever that ends up being)<br>
</details>


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 July 2021 22:40:50 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:31:47 UTC