New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-cascade-6] Handle sibling-proximity in @scope #7751
Comments
Shouldn't that be |
yes, the root selector is in parenthesis. So this pattern would be something like |
I had this idea of changing the
Reasons not to like that:
I don’t think an extra at-rule (e.g. |
I'm actually not sure if there are impl constraints that would encourage us to keep the number of at-rules in check or not. If not, |
Agenda+ to decide between |
I don't think there are such constraints. |
The CSS Working Group just discussed
The full IRC log of that discussion<emeyer> bramus: In regular scope, we can walk down the DOM tree<emeyer> …Suggestion here is to introduce sibling proximity where the lower boundary is a sibling of the upper boundary element <emeyer> …Syntax would be the same as @scope rule; different would be the at-rule would be @sibling-scope <emeyer> s/different/difference/ <astearns> ack fantasai <emeyer> fantasai: With normal scoping, relationships are obvious, but here we’re only doing following siblings, so should make that a little more obvious <emeyer> …Because we’re only going forwards in the tree <masonf> FYI, I'm here and I understand the group wanted to talk about 8189 but I wasn't here earlier. Here now! <emeyer> bramus: It’s implied by the name, I think <emeyer> …The end boundary element should be a following sibling of the start boundary element <emeyer> …It could be you style all the siblings from a certain element down <lea> +1 to @scope-sibling over @sibling-scope for the reason fantasai mentioned <emeyer> fantasai: I would go with @scope-siblings rather than @sibling-scope so they sort together <lea> also typing @scope would bring both up in autocomplete <lea> q? <emeyer> lea: I agree with Elika on the naming; they sort together, they autocomplete together <emeyer> astearns: Should we resolve on that? <emeyer> bramus: I’m fine with that <fantasai> i/lea/bramus: Would it be @scope-sibling or @scope sibling? <emeyer> astearns: We do tend to go with non-plural syntax for things, so @scope-sibling <emeyer> fantasai: The non-plural form reads weirdly <emeyer> astearns: Yeah, okay <emeyer> miriam: You are creating a scope of siblings <emeyer> florian: We do have precedent for a few plurals <emeyer> RESOLVED: The name will be @scope-siblings <emeyer> astearns: Anything else? <emeyer> miriam: I think we’re hoping things will carry over from the other one <emeyer> bramus: There’s another CSS cascade issue at the bottom of the list <emeyer> astearns: People have joined specifically for the animation issue, so I want to do that next |
Branching off of #7233...
Currently,
>>
is a shorthand for writing an@scope
. That is, anytime you see.foo >> .bar {...}
, it's equivalent to@scope .foo { .bar {...}}
.Now that we've agreed to add
++
(or~~
) to do sibling proximity, it would be nice to keep the consistency between the two syntaxes.I suggest
@scope siblings ... {}
, where the...
is the current scope prelude stuff. If you specifysiblings
the lower bound, and all contained selectors, are auto-scoped to be siblings of the upper bound element, and we apply sibling-distance proximity as the tiebreaker rather than ancestor-distance proximity.Need to be careful with the definitions to make sure descendant-scopes can still be nested; I guess descendant-scopes would scope the upper bound as a sibling but switch back to normal scoping for their lower bound. I believe this'll reproduce the behavior of
.foo >> .bar ++ .baz >> .qux
.The text was updated successfully, but these errors were encountered: