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