Re: [csswg-drafts] [css-values-4] How to serialize infinite values? (#3768)

The CSS Working Group just discussed `How to serialize infinite values?`, and agreed to the following:

* `RESOLVED: Use calc(1/0) and calc(0/0)`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: How to serialize infinite values?<br>
&lt;dael> plinss: Tab sent regrets, anyone want to talk about this?<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/3768<br>
&lt;dael> AmeliaBR: I can go over quickly<br>
&lt;dael> AmeliaBR: Issue is that at serialization stage before computed style we say divisions are simplified. Sometimes means you have /0 situation or other situations with infinite or NaN values. WE havethat NaN is +infinity but how to serialize.<br>
&lt;dael> AmeliaBR: Prop is serialize it as a calc expression as something/0 where something is appropriate to dimension you're using 1px, 1deg, 1ms<br>
&lt;dael> AmeliaBR: This would only be exposed in serialized values<br>
&lt;dael> AmeliaBR: Catching up on issue discussion between oriol and TabAtkins where NaN should have own unique serialization diff than infinity<br>
&lt;dael> AmeliaBR: We want something predicable and consistent but not too complicated b/c used in a lot of places. Jsut for intermediate serilization<br>
&lt;dael> fantasai: Seems infinity is calc(1)/0 and NaN is calc(0)/0<br>
&lt;dael> plinss: negative infinitiy is calc(-1)/0?<br>
&lt;fantasai> calc(1/0) and calc(0/0)<br>
&lt;dael> fantasai: Yep<br>
&lt;dael> AmeliaBR: And all of these would hold on to a unit so it's calc(1px)/0<br>
&lt;dael> fantasai: Makes sense<br>
&lt;dael> gregwhitworth: Consider none as a keyword?<br>
&lt;fantasai> s/none/NaN/<br>
&lt;dael> fantasai: Then we'd need to make it for all CSS and why would you want that<br>
&lt;dael> gregwhitworth: For this reason? B/c we're spec in a weird way<br>
&lt;dael> fantasai: THis is better than a global keyword that's a number that doesn't exist. I don't think it helps anyone<br>
&lt;dael> emilio: Prob doesn't work with dimensions<br>
&lt;dael> fantasai: That's an important point<br>
&lt;dael> plinss: Other alt is keywords for NaN and infinityfor only in calc. Curious if they have an actual use somewhere else<br>
&lt;dael> AmeliaBR: We do havesome prop that have an infinity keyword and that is treated diff than a calc expression that computes to inifity. It's the infinite keyword in animations. Not sure where else<br>
&lt;dael> fantasai: We should go with calc-based serialization. It comes up in serializing calcs and that way we don't need keywords for units. it's built into the method<br>
&lt;dael> plinss: Objections?<br>
&lt;dael> RESOLVED: Use calc(1/0) and calc(0/0)<br>
&lt;dael> emilio: How does NaN behave? Like NaNpx body?<br>
&lt;dael> AmeliaBR: I assume keep current rule where treated as +inifinity and then clamps per property rules<br>
&lt;dael> emilio: Wouldn't be better to keep as computed time for clamping and not care about serialization?<br>
&lt;emilio> heh<br>
&lt;dael> AmeliaBR: Serialization simplifies multiplication and division so it has to be simplified. Going down to a standard division structur<br>
&lt;dael> AmeliaBR: If you spec calc(3/3) at serialization you get 1. If you spec calc(3/0) we're saying at serialization you get 1/0<br>
&lt;dael> plinss: GIven our existing rules we have to do this<br>
&lt;dael> emilio: calc(1/0) doesn't parse anywhere, right?<br>
&lt;dael> AmeliaBR: I don't know. If we have people rejecting at parse or doing own thing at serialization<br>
&lt;dael> emilio: Pretty sure gecko rejects at parse time. When we impl min/max may have to change<br>
&lt;fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Chtml%20style%3D%22background%3A%20red%3B%20background%3A%20calc(1px%2F0)%20calc(1px%2F0)%20green%3B%22%3E<br>
&lt;dael> fantasai: Doesn't appear to be the case ^<br>
&lt;dael> fantasai: If we enter as keyword still won't parse.<br>
&lt;fantasai> s/Doesn't/Does/<br>
&lt;dael> fantasai: Gecko does not parse<br>
&lt;dael> AmeliaBR: Same for Chromium<br>
&lt;dael> AmeliaBR: But we're extending number of pss divisions poss. Allowing to devide values withunits and some units might be 0 so need robust math rules<br>
&lt;dael> emilio: But then how to serialize this is only small part, need to spec how behave. You're introducing them into layout<br>
&lt;dael> AmeliaBR: There is an extended new section on range checking<br>
&lt;dael> AmeliaBR: that says any infite values are clamped to min/max allowed. emilio is right most prop don't have explicit min/max value allowed<br>
&lt;AmeliaBR> https://drafts.csswg.org/css-values/#calc-range<br>
&lt;dael> AmeliaBR: That prop still part of spec needs to be discussed. I don't know if need to hold off discussion of serialization<br>
&lt;dael> emilio: Generally the spec saysclamp and apply transformations as early as possible. calc(10px) serialize to 10px. Serialization might not be an issue depending on how spec to behave<br>
&lt;AmeliaBR> s/That prop still part of spec/That part of spec probably still/<br>
&lt;dael> myles: Not sure should spec max for every prop. Browsers may vary. Some browsers might be able to handle a really big width and some can't<br>
&lt;dael> emilio: Agree<br>
&lt;dael> myles: Tons of impl specific limits like nesting depth that aren't written. These max should be with those<br>
&lt;dael> AmeliaBR: Good point. Should lead to not clamp too early. Eventual clamp will be impl specific so should only happen when it has to. If we just propagate mathematical infinity it helps interop and serialization stage<br>
&lt;dael> emilio: Reasonable answer<br>
&lt;dael> plinss: Anything else?<br>
</details>


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

Received on Wednesday, 10 April 2019 16:49:33 UTC