[css-cascade-6] Do we want to defer some or all of these scope extensions to level 7? #8628
Labels
Projects
Comments
|
The CSS Working Group just discussed
The full IRC log of that discussion<emeyer> miriam: Some tagalong features we can consider; all are useful, question is whther we shoudl be trying to cover them now or defer to next spec level<emeyer> …If we don’t defer them, next on the agenda is a scope sibling feature <emeyer> …This would be horizontal in the DOM <emeyer> …A pretty straightforward thing to spec, we think, but it hasn’t been specced <emeyer> …The other is the scoped proximity combinators <emeyer> …We have a little less sense when people would use this rather than @scope <emeyer> …For @scope you’re trying to target several elements in the DOM, and the at-rule does that neatly <emeyer> …In a single selector, it gets more complex <TabAtkins> +1 to deferring, they're all nice but none are necessary <emeyer> …The real question is: defer, or no? <emeyer> astearns: One concern with deferring is there may be feedback with current-level features that could modify <emeyer> …If we’re not considering these now, we may miss something <emeyer> miriam: It’s hard to know if that’s too cautious <emeyer> …So far neither has caused major changes and will continue to be in our heads, but I dunno <emeyer> TabAtkins: My estimate is they shouldn’t cause any problems, and should be forward-compatible <emeyer> astearns: Would it make sense to have a note about things we’ve explicitly deferred? <bramus> q+ <emeyer> miriam: Since one is partically-specced, it could be opening another spec <astearns> ack bramus <fantasai> s/partically/partially/ <emeyer> bramus: I’m okay with deferring combinators due to complexity, but was wondering if we can have sinling scope in level 6 <emeyer> s/sinling/sibling/ <emilio> Implementation-wise they seem a bit trickier than descendant scopes fwiw <emeyer> astearns: What use case are you concerned about with sibling proximity? <emilio> Because to change the descendant relationship you need to remove from the DOM but that's not true for siblings <emeyer> bramus: So authors can style things like start and end dates on a calendar and also styles things between them <emeyer> miriam: Another example is to style everything between one header and the next header <astearns> ack fantasai <emeyer> fantasai: Seems like those are use cases where you don’t need scope proximity effect, you just want the flooring effect, yes? <emeyer> miriam: I think I’ve seen examples using both <emeyer> …They achieve the same goal, but at different levels of explicitness and power <RRSAgent> I have made the request to generate https://www.w3.org/2023/03/22-css-minutes.html fantasai <emeyer> astearns: Can we resolve on deferring the combinator? <emeyer> …Proposing deferring 8380 with a note that it was deffered to next level <emeyer> RESOLVED: The combinator is deferred |
andruud
added a commit
to andruud/csswg-drafts
that referenced
this issue
Apr 14, 2023
mirisuzanne
pushed a commit
that referenced
this issue
Apr 14, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Two of the open issues related to
@scopeare related to defining extensions to the syntax:>>/~~)Before we get into discussing and resolving on the details, I just want to note that neither is a core requirement for shipping the existing scope syntax. If we want to defer them to a future spec, the current scope rule can ship uninhibited. To consider each one at a time:
@scope- but with the added complexity of resolving multiple subjects from a single selector. These may be worth pursuing, but it's not clear that there is a strong need for them - or that the 'semi-de-sugaring' solution proposed will make sense in practice. To me, these feel non-essential.@scoperule more precisely, it may also be simpler to spec -- but not trivial.I think both discussions are worth pursuing. I also think both could be deferred in order to ship the central functionality here.
The text was updated successfully, but these errors were encountered: