Re: [csswg-drafts] [css-variables?] Higher level custom properties that control multiple declarations (#5624)

The CSS Working Group just discussed `[css-variables?] Higher level custom properties that control multiple declarations`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-variables?] Higher level custom properties that control multiple declarations<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/5624<br>
&lt;dael> leaverou: There is a very reasonable tag guideline that custom elements shoudl use properties for presentational elements. With current state of custom properties this is impossible for non-trivial<br>
&lt;dael> leaverou: Current custom prop can only be literal fragments and you need to transform<br>
&lt;dael> leaverou: There are problems where we need to add inline conditionals.<br>
&lt;dael> leaverou: However, when you have lots of these properties intersecting then it can get really messy if only 2 you have is inline funcitons that need both condisions.<br>
&lt;dael> leaverou: Ideal is something to cascade but not sure feasible. Wanted impl feedback and then I can draft a more detailed proposal<br>
&lt;dael> leaverou: Examples I've looks at from component liberties are in the issue<br>
&lt;dael> leaverou: Some impl have weighed in in the issue [missed]<br>
&lt;dael> leaverou: Wondering if set of constraints could be introduced to make it more feasable. Wanted to bring to attention of group for more ideas or thoughts<br>
&lt;dael> astearns: Feedback on the shape of the feature?<br>
&lt;dael> fremy: I think it's a pretty good idea.<br>
&lt;dael> fremy: Really something that's a limitation of custom properties. Quite true when you use attributes you do more than reuse variable.<br>
&lt;dael> fremy: Pseudo class you can't use in theory but it would be really nice to have syntactic sugar. I know you can do it meta languages. Good to auto-prefix with an if condition. That would give us most of advenatages. Extend the css selector syntax to have an id for all properties<br>
&lt;TabAtkins> Assuming we're fine with simple conditionals in an if() function (which we've discussed before and this should be okay), doing an at-rule inside holding a block of props could have a reasonable desugaring to that.<br>
&lt;dael> leaverou: One thing to keep in mind is these often need to control multiple elements in the component. Alignment might need to control margins and padding. Ideally should work<br>
&lt;dael> leaverou: [missed]<br>
&lt;TabAtkins> It would have some side-effects - any properties in the block are effectively using a variable, so it would kick in IACVT behavior, etc.<br>
&lt;dael> leaverou: Often they need to control properties in mutli elements. Example alignment controls spaces, padding, etc in multi child elements. Good to keep in mind that it plays nicely with nesting module<br>
&lt;dael> TabAtkins: invalid at computed value time = iacvt<br>
&lt;fremy> @TabAtkins: I would think it solves many issues<br>
&lt;dael> leaverou: Some reasonable syntax to combine and falling back to invalid at computed value time would prob be acceptable<br>
&lt;leaverou> As long as we can combine conditions and nest them, having IACVT as the ultimate fallback is acceptable<br>
&lt;TabAtkins> so like `.foo { color: blue; @if (var(--state) = one) { color: red; } }`, it'd desugar to `.foo { color: cond(var(--state) = one, red; blue); }`<br>
&lt;dael> astearns: I think this is a really interesting proposal and I'd like to see further discussion on what we can do here. Any major concerns about spending time on this?<br>
&lt;dael> astearns: I think we should take this back to the issue and/or come up with a proposal which we can file issues on. IT's a really good idea. Anything else from group?<br>
&lt;dael> leaverou: I primarily wanted to draw impl attention. I can't design impl needs. Continue on issue is fine<br>
</details>


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 9 December 2020 17:26:09 UTC