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

@FremyCompany 

I think attribute inheritance, range attribute selectors (gt, lt etc), and `attr()` as a token stream are things that are useful in their own right and should be pursued independently, regardless of where this goes. There have even been times when I mirrored attribute values with CSS properties, just so they can inherit.

However, I don't think attributes are a good solution here. We cannot be deprecating presentational HTML attributes, then directing Web Component authors to use attributes for presentation. Not to mention that this means it's hard or impossible for authors to use conditional rules and selectors to vary these values (e.g. think of a tabs component, where the author wants the tabs to be on top in narrow viewports and to the left in larger viewports).

You say that these new properties are way too constrained, however we carefully reviewed how web component libraries are currently specifying these presentational attributes and it seems that these would cover nearly all use cases. Did you have any use cases in mind, from popular web components, which would not be addressed by something like this?

I agree the double cascade pass is not ideal, but:
1. It's only done when such properties are both specified *and* used, so only when two cascade passes are actually needed
2. It's already done today for certain things as @emilio pointed out
3. Let's not forget that `O(2 * ƒ(N))` is still `O(ƒ(N))`. The cascade today is extremely fast, so twice that is still extremely fast, and definitely much faster than a lot of JS solutions to address these gaps.

@tabatkins I just realized one more reason to make this an `@property` option instead of new syntax: It promotes better encapsulation. How components use these properties is an implementation detail, and could change between different versions of the component. Authors should not have to care, or even know how these properties are used within the component, and should not need to change their code that styles the component if the component starts using properties in a different way. _(I suppose components can always internally define regular custom properties that take their values from constants, but not the other way around, so it could become a pattern for components to accept all their styling inputs via constants wherever the syntax permits this. Not sure that's a good thing.)_

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


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

Received on Thursday, 4 February 2021 15:43:44 UTC