Re: [css-houdini-drafts] [css-typed-om] Clarify list-valued properties

The Houdini Task Force just discussed `Clarify list-valued properties`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: Clarify list-valued properties<br>
&lt;TabAtkins> github: https://github.com/w3c/css-houdini-drafts/issues/823<br>
&lt;heycam> TabAtkins: this was brought up by one of our engineers<br>
&lt;heycam> ... I was hoping at the start this issue wouldn't occur. I was hoping to split props into list values and single values<br>
&lt;heycam> ... every prop would be one or the other<br>
&lt;heycam> ... anders pointed out we have several props that at minimum have.a neutral value, but sometimes have more than that<br>
&lt;heycam> ... and the list value / single value split is not enforced in custom props either<br>
&lt;heycam> ... you can always define [ length+ | number+ ]<br>
&lt;heycam> ... not handling that well<br>
&lt;heycam> ... so rather than declare props to be list valued or single valued, declare top level productions as being list valued or single valued in a given prop<br>
&lt;heycam> ... e.g. content<br>
&lt;heycam> ... some of the productions will be single valued, and they can't be used with the append() methods<br>
&lt;heycam> ... some are multi-valued, and can be used with the append() methods<br>
&lt;heycam> ... and if you do the wrong one, and you call styleMap.append("counter-reset", "none")<br>
&lt;heycam> ... I believe we'll throw in that case<br>
&lt;heycam> ... one thing I'm not sure is how to handle the case where it's currently a single value, and you append a list production<br>
&lt;heycam> ... e.g. it's currently set to none, and you want to append real values<br>
&lt;heycam> ... the most common case is none, I'd like that to be easier to handle<br>
&lt;heycam> ... so I'd like to make that silently drop the single value, and turning it into a multi-value production instead<br>
&lt;heycam> ... not sure about this, may be more consistent to throw here<br>
&lt;heycam> ... I believe this design in general, is the way to go to handle all possible props properly<br>
&lt;heycam> ... it's not a significant complexity increase<br>
&lt;heycam> ... it'll be a bit more work continuing we need to make sure they're properly tracked<br>
&lt;dbaron> heycam: what if we change a property from single-value length to multi-value length?<br>
&lt;heycam> TabAtkins: in that case the original length would be classified as a multi value<br>
&lt;dbaron> heycam: so in the updated property that would be defined as a multi-value thing<br>
&lt;heycam> TabAtkins: so let me know if you have opinions on this<br>
&lt;heycam> ... otherwise I'll resolve it like this and edit it in<br>
&lt;heycam> fremy: how you define that syntax, how would you write down your decl to say this is single valued or list valued?<br>
&lt;heycam> TabAtkins: CSS in the specs will define this<br>
&lt;heycam> ... don't have to do that in the API side<br>
&lt;heycam> fremy: for custom properties<br>
&lt;heycam> TabAtkins: right now, custom props are either a single value or there's a + in there<br>
&lt;heycam> ... but once we had the # one, those will be multi-valued<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/823#issuecomment-432980451 using your GitHub account

Received on Thursday, 25 October 2018 09:27:51 UTC