Re: [css-houdini-drafts] [css-properties-values-api] Allow custom property descriptors with a CSS @-rule

The Houdini Task Force just discussed `Declarative property registration`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: Declarative property registration<br>
&lt;TabAtkins> github: https://github.com/w3c/css-houdini-drafts/issues/137<br>
&lt;gregwhitworth> scribenick: gregwhitworth<br>
&lt;gregwhitworth> TabAtkins: early on in this process, when we setting up the props vals API<br>
&lt;gregwhitworth> TabAtkins: we would want a more declaritive version<br>
&lt;gregwhitworth> TabAtkins: you just want to animate a custom prop<br>
&lt;gregwhitworth> TabAtkins: you don't want JS<br>
&lt;gregwhitworth> TabAtkins: we delayed doing that<br>
&lt;gregwhitworth> TabAtkins: at this point, we're pretty stable with L1<br>
&lt;gregwhitworth> TabAtkins: that interface is working well<br>
&lt;gregwhitworth> TabAtkins: time to revive this declaritive proposal<br>
&lt;gregwhitworth> TabAtkins: have some way to store it in your stylesheet<br>
&lt;gregwhitworth> TabAtkins: the shape of it is more or less what amelia says in the issue<br>
&lt;gregwhitworth> TabAtkins: there are some minor changes for registration due to CSS syntax<br>
&lt;gregwhitworth> TabAtkins: other than that - this appears to be relatively straight forward<br>
&lt;gregwhitworth> TabAtkins: there are some potential issues with timing<br>
&lt;gregwhitworth> TabAtkins: like a late registration not causing reparsing<br>
&lt;gregwhitworth> TabAtkins: it's easier in a declaritive scenario - no need to go reparse<br>
&lt;gregwhitworth> TabAtkins: overall I think it's reasonable and I want to deliver on providing declaritive APIs<br>
&lt;gregwhitworth> SimonSapin: just now you talked about stylesheets, if the docuement contains 4 stylesheets does order matter?<br>
&lt;gregwhitworth> TabAtkins: if you have 4 registrations then the order matters<br>
&lt;gregwhitworth> fremy: it's fine<br>
&lt;gregwhitworth> fremy: I'm super excited<br>
&lt;gregwhitworth> futhark: just a concern about timing and at-rules when they start collecting<br>
&lt;SimonSapin> s/about stylesheets/about early and late stylesheets/<br>
&lt;gregwhitworth> futhark: you delay them, the latest would apply but what if one browser applies after two stylesheets but there's a new one coming in?<br>
&lt;gregwhitworth> TabAtkins: that's fine - you'll only be able to see it if you look at the GCS in between those loading docs<br>
&lt;gregwhitworth> futhark: so you would normally register the first time you collect the rules, the second time you would just ignore it?<br>
&lt;gregwhitworth> TabAtkins: doc order is normally how it works? but good question<br>
&lt;gregwhitworth> futhark: that's a little bit different how the JS version works<br>
&lt;gregwhitworth> TabAtkins: yes because JS can be definitive<br>
&lt;gregwhitworth> heycam: what happens if you do both JS and declaritive?<br>
&lt;gregwhitworth> TabAtkins: the script should just win IMO<br>
&lt;gregwhitworth> TabAtkins: that seems much more likely to have timing issues<br>
&lt;gregwhitworth> fremy: yeah<br>
&lt;gregwhitworth> TabAtkins: plus then - it saves the problem of dealing with multiple JS registrations<br>
&lt;gregwhitworth> heycam: not sure what the current status is of @font-face of counter-styles in shadow styles<br>
&lt;gregwhitworth> TabAtkins: as far as I remember, registering a property is global, so it will apply to all shadows as well - I THINK<br>
&lt;gregwhitworth> TabAtkins: I wouldn't want it to be different. font-face and what not are scoped to their own root so it's different<br>
&lt;Rossen> q?<br>
&lt;gregwhitworth> heycam: it's a bit unclear what "later in the document" means<br>
&lt;gregwhitworth> TabAtkins: it shouldnt' be - you have a flat tree ordering<br>
&lt;gregwhitworth> TabAtkins: style rules that don't show up in the flat tree don't get applied<br>
&lt;gregwhitworth> emilio: they do apply<br>
&lt;gregwhitworth> emilio: if you have an unslotted style tree then it does apply<br>
&lt;gregwhitworth> TabAtkins: this is more complicated<br>
&lt;gregwhitworth> TabAtkins: [repeats question]<br>
&lt;gregwhitworth> TabAtkins: but if you have unslotted styles still applying, then the same question applies<br>
&lt;gregwhitworth> emilio: you use DOM tree order inside of the style root<br>
&lt;gregwhitworth> emilio: I'm not sure why you can't use DOM tree order based on Host for example, that's what I think is most reasonable<br>
&lt;gregwhitworth> TabAtkins: it sounds complicated - maybe we don't allow this in scoped stylesheets<br>
&lt;gregwhitworth> TabAtkins: you already have a shadow root, so you're already in JS<br>
&lt;gregwhitworth> gregwhitworth: is there a plan for declaritive creation of shadow root?<br>
&lt;gregwhitworth> TabAtkins: I've pushed for it - but so far no<br>
&lt;gregwhitworth> TabAtkins: we'll deal with it then I guess<br>
&lt;gregwhitworth> TabAtkins: do people want to proceed with this?<br>
&lt;gregwhitworth> heycam: I think it's worth adding somewhere<br>
&lt;bkardell_> +1<br>
&lt;gregwhitworth> Rossen: there's enough excitement<br>
&lt;gregwhitworth> Rossen: let's persue it somewhere, properties and values API?<br>
&lt;gregwhitworth> Proposed Resolution: Add it to the Properties and Values API<br>
&lt;gregwhitworth> Rossen: objections?<br>
&lt;gregwhitworth> Resolved: Add declaritive registration into properties and values API<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/137#issuecomment-433037224 using your GitHub account

Received on Thursday, 25 October 2018 12:48:45 UTC