- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Oct 2021 23:36:29 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[cssom] Serialization of large numbers should use scientific notation`, and agreed to the following: * `RESOLVED: Take scientific notation and match serialization of JS` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [cssom] Serialization of large numbers should use scientific notation<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/6471<br> <dael> Rossen_: Added to TPAC agenda but we didn't get to it<br> <dael> smfr: The issue is how large numbeer serialize.<br> <dael> smfr: Agreed in past to allow scientific notation when we pass. Difference in serialization. FF and Blink use scientific notation. Webkit writes them out<br> <dael> smfr: One question is if should be different for numbeer vs int. z-index how much precision do we maintain so they round trip, for example<br> <dael> smfr: And then there are differences like blink adds leading 0s.<br> <TabAtkins> q+<br> <dael> smfr: This impacts wpt so would be good to resolve<br> <florian> q-<br> <Rossen_> ack florian<br> <Rossen_> ack TabAtkins<br> <TabAtkins> https://drafts.csswg.org/cssom/#serializing-css-values<br> <dael> TabAtkins: Well defined in CSSOM. Will grab a link<br> <dael> TabAtkins: Per this int serialize fully and floats with no more than 6 digits. If needed scientific with 6 digits.<br> <dael> TabAtkins: it is defined. If question is should define something else we can talk about it<br> <dael> smfr: Fine with as spec. Q is if impl will impl as spec<br> <dael> florian: Does this no more than 6 cover the leading 0s?<br> <dael> TabAtkins: 6 significant digits. And need to use shortest form. Leading 0s are dropped<br> <TabAtkins> "A base-ten number using digits 0-9 (U+0030 to U+0039) in the shortest form possible, using "." to separate decimals (if any), rounding the value if necessary to not produce more than 6 decimals, preceded by "-" (U+002D) if it is negative."<br> <Rossen_> q?<br> <dael> Rossen_: Sounds like we don't need to change a definition. Back to smfr question about are impl willing to use this definition?<br> <dael> Rossen_: Survey question to implementors<br> <dael> iank_: All of our folks are in EU so I'm not sure<br> <dael> Rossen_: Perhaps we don't have right folks.<br> <dael> Rossen_: We can resolve on the issue as no change to spec and encourage implementors to engage<br> <dael> Rossen_: Reasonable?<br> <dael> smfr: I'm reading the link from TabAtkins it says scientific notation is not used. Is it out of date?<br> <dael> TabAtkins: Yes, must be. Thought it was required. Integer question is answered. Hmm.<br> <dael> TabAtkins: No way to satisfy this without scientific notation. If you do a large number you need more than 6<br> <dael> Rossen_: And why is it a note?<br> <dael> TabAtkins: It's a clarification. It should fall out from definition.<br> <dael> Rossen_: Perhaps we can try and ammend the spec to require scientific notation?<br> <dael> TabAtkins: Yes<br> <dael> smfr: Serialization we can reference? Perhaps from JS?<br> <dael> TabAtkins: JS does have well spec one<br> <dael> smfr: Chrome JS doesn't match number serialization which is a bit surprising<br> <dael> Rossen_: We can call for resolution here to add scientific notation to be used for number<br> <dael> Rossen_: Then wait for TabAtkins or someone to define the serialization. Unles syou have one right now<br> <dael> TabAtkins: Happy to take that<br> <dael> Rossen_: Prop: Take scientific notation and match serialization of JS<br> <dael> Rossen_: Obj?<br> <dael> RESOLVED: Take scientific notation and match serialization of JS<br> <dael> Rossen_: Call to impl and getting feedback still stays<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6471#issuecomment-937325105 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 October 2021 23:36:31 UTC