Add invalidation discussion summary #9
Conversation
css/has/invalidation-discussions.md
Outdated
|
|
||
| 1. **Interactions** -- Hovering a button within a card makes the card style change (i.e. background color, border, or even interaction like having a shine animation gloss over it). Sure you can solve this when a single card has a single action, but what happens when that card has multiple actions? You need JS for that. | ||
| 2. **States** -- Styling things like containers with certain states (i.e. "empty" or "pending") is either not consistent (:empty/:not:empty due to elements vs text nodes and whitespace), or not possible in CSS. Say you want an empty state experience and in your JS you populate an Inbox with a cute message that says "Yay you've reached Inbox 0!". You may want to style the page a certain way, detecting when the child class is present. I.e. if .empty-message is present, it's parent/ancestor .inbox-container could get a style, like a sunshine background. JS is currently required for that. | ||
| 3. **Pairings** -- Say you have a shopping card. The shopping card has a "Buy" button. The buy button may be :disabled when the item is sold out. It would be nice to be able to style either the parent card or any parent element with the "Sold Out" style. JS is currently required for that. (I guess this is also a state example) |
There was a problem hiding this comment.
I'm not sure these are honestly the best use cases articulations, and I agee with this "I guess this is also a state example" because the state example itself is wonky
There was a problem hiding this comment.
Yes right. There can be other best cases. But in the previous conversations of the mailing thread, the use cases seemed to appear to be reasonable to consider as representative examples of many cases. So I just added those to keep our communication progress.
There was a problem hiding this comment.
How about adding additional explanation like this?
#13
| * Allow `:has()` argument starts with `>` | ||
| * Allow `:has()` argument starts with descendant combinator | ||
| * Allow attribute/elemental selectors in `:has()` | ||
| * Allow compound selector in `:has()` |
There was a problem hiding this comment.
this should say allow compound selectors of attribute and elemental selectors, right? I think the thing here is we are talking about allow, but it is unclear that everything else not explicitly stated is disallowed - which is why my email stated some of that, I guess
There was a problem hiding this comment.
I think it would be clear to think about the each criteria as independant.
There can be lots of variations if we need to mention all the cases - 'Allowing compound of attribute and elemental selectors', 'Allowing compound of attribute and elemental selectors and user action pseudo classes', ...
By combining the 3rd and 4th criteria, we can make the 'compound of attribute and elemental selectors'. I think this is more clear to focus to the complexity or performance impact on 'Allowing compound' if there are some arguable point on this criteria.
css/has/invalidation-discussions.md
Outdated
|
|
||
| | Criteria | Example | | ||
| | :----------- | :----- | | ||
| | Allow `:has()` argument starts with `>` ? | `.hero:has(> img)` | |
There was a problem hiding this comment.
similar to the comment on 141, this is a little confusing - the statement preceeding talks about limitations, but all of these begin with allow (the opposite of a limitation and somewhat repititous). I'm not sure what this matrix is defining, exactly...
There was a problem hiding this comment.
To get the limitation of 'Disallow something' that mentioned below (line 156~), I tried to get criteria that can split the selector expression into two group - a group from allowing something, the other group from disallowing something.
So the criteria "Allow :has() argument starts with >" splits all the selector expressions to these group
- selectors that have leftmost child combinator in
:has()argument. - selectors that don't have leftmost child combinator in
:has()argument.
Then we can focus complexity or performance impact when we try to support the selectors with the leftmost child combinator in :has() argument. Or, we can focus complexity or performance impact of some other approach that supports the opposite case (selectors without the leftmost child combinator in :has() argument). And with the complexity or performance impact, we can say that, when we have limitation of not supporting leftmost child combinator, we may have this kind of (amount of) advantages.
When we have some discussions about a limitation, it would be better to minimize the variations to focus the complexity or performance impact of that limitation. So I tried to get the independant criteria that can split the selector usages as simple as possible.
There was a problem hiding this comment.
How about adding this explanations for that?
#12
|
Merged sub PRs to remove some branches. |
|
Remove this from explainer |
No description provided.