Re: [css-houdini-drafts] [css-typed-om] Change CSSKeywordValue's attribute to allow forward-compatible upgrades

The Working Group just discussed `Forwards-compat design choices`, and agreed to the following resolutions:

* `RESOLVED: when we have this sort of upgrade situation we should, if possible, make new complex type subclass whatever it was before, but only do it for upgrade situations`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Forwards-compat design choices<br>
&lt;TabAtkins> GitHub: https://github.com/w3c/css-houdini-drafts/issues/735<br>
&lt;dael> TabAtkins: One issue...a general issue with any attempt to design typed om is what happens when we change value space of a property.<br>
&lt;dael> TabAtkins: There are patterns we commonly do like when something is a list. There are things not handled well like changing a property from being a single keyword to something more complex. Which means...the question is hwo to handle reification. If it started simple and we reify as a keyword and it becomes more complex there's options<br>
&lt;dael> TabAtkins: Firs tis we maintaing compat. If it's simple it's a keyword and more complex it's more complex. When the single keyword isn't a special case it's awkward to handle. It would mean if you want to test if the weight value is spec is it' the keyword or the keyword set. You'd have to branch twice. If we know the final value it would be more complex.<br>
&lt;dael> TabAtkins: I think I can make it less complex in common cases. In the basic types the relevent accessor have a unique name and then when it upgrades is still has the accessor.<br>
&lt;dael> TabAtkins: If we start with font synth as a single value and then becomes a double it would be a keyword set with a .keyword property that reflects the single value that exists. That way any older code will continue working properly. Newer code can work more natively.<br>
&lt;dael> TabAtkins: Won't work always, but a lot of cases. Propobaly changes the accessor to .keyword and string to .string. .unit.value stays where it is.<br>
&lt;dael> TabAtkins: More basic cases like a hash token we'll add a unique value.<br>
&lt;dael> TabAtkins: Is that a good idea or do we accept that as we extend we'll have legacy things.<br>
&lt;dael> shane: Is there a combo where we could consider so the special object type extends. THis is the same trick sa the style mapping. That gives us the consistancy approach to a longer list<br>
&lt;dael> TabAtkins: Likely. What I like is if a property is keyword or numeric and people branch on type can still branch on type.<br>
&lt;dael> TabAtkins: Means a slightly weird object hierarchy and we can't do it on number...Well...math values ar emore complex.  But strings or keywords subclassing keyword value class would be fine.<br>
&lt;dael> dbaron: I feel...there's compat risk. Also the risk that once a thing is upgraded that people will write new code that only works for old stuff.<br>
&lt;dael> TabAtkins: ExmpalE?<br>
&lt;dael> dbaron: You're writing new code tha tonly works with single keyword case because you forgot this property was upgrade. When the compat thing is a thing where you can handle the old values you're creating a risk that people will fall into the compat risk.<br>
&lt;dael> TabAtkins: True, but only way to handle is break old code.<br>
&lt;dael> dbaron: True.<br>
&lt;dael> dbaron: There might be an advantage to not having the compat for properties that weren't upgraded. So if a property starts as multi keywords there's an advantage ot not having single keyword available.<br>
&lt;dael> TabAtkins: That was my plan. If we know ahead of time something is complex it'll descend straight from style.<br>
&lt;dael> TabAtkins: That reflects on a 3rd option, similar to how Ana tried to handle this.  Every value had a short named accessor that gave you a complex value of it. If it was simple you'd get simple, but you could also ask for hte complex form and if it existed you'd get it.<br>
&lt;dael> fremy: Other similar thing was a problem for c# browser. They solved that by when you add a value you give a list of all functions you expect and then as the UA you know all the values expected byt he author and if it's none you can return the css tyle value. You have context. It worked for c# brwoser<br>
&lt;dael> TabAtkins: You'd have to put that into the get method<br>
&lt;dael> fremy: i don't know if it's good design, but it's one way that works.<br>
&lt;dael> TabAtkins: I thought of that, but figured it was too much to write on every get call.<br>
&lt;dael> TabAtkins: So, taling this over. Best idea is when we have this sort of upgrade situation we should, if possible, make new complex type subclass whatever it was before, but only do it for upgrade situations.<br>
&lt;dael> fremy: Another thing we could do is when we make a breaking change we can make a priority like a .v2 if they don't have it they get the old scenario.<br>
&lt;dael> TabAtkins: That's true. THat's reasonable. I hadn't thought of the escape when we can't upgrade.<br>
&lt;dael> TabAtkins: Reasonable to people?<br>
&lt;dael> Proposed resolution: when we have this sort of upgrade situation we should, if possible, make new complex type subclass whatever it was before, but only do it for upgrade situations<br>
&lt;dael> RESOLVED: when we have this sort of upgrade situation we should, if possible, make new complex type subclass whatever it was before, but only do it for upgrade situations<br>
&lt;dael> emilio: How is clampping done in typed om?<br>
&lt;dael> TabAtkins: It's automatic. When it enters the style system clamping happens. If you try and set a negative value typed OM is fine, when it enters style system it's 0.<br>
</details>


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

Received on Monday, 9 April 2018 08:00:44 UTC