Repository navigation
[css-cascade-6] What is the desired shape of CSSScopeRule? #8626
Description
In #8468 @andruud pushed a spec definition for adding CSSScopeRule to CSSOM:
[Exposed=Window]
interface CSSScopeRule : CSSGroupingRule {
readonly attribute CSSOMString start;
readonly attribute CSSOMString end;
};
As far as I can tell, this change in the spec never had a resolution attached – so bringing it up here to get that resolution. In conversation with @fantasai, she also raised a few questions about the final shape of this rule:
- Is 'start'/'end' the terms we want? Or do we want 'root'/'floor', or any number of other things. Since this is the only place in which the terminology is actually user-facing, it becomes a real question.
- Should they return null string or null if they're missing?
- Do they include the wrapping parentheses or not?
Activity
fantasai commentedon Mar 21, 2023
Fwiw, I think we should not include the wrapping parentheses so that the returned string is a proper selector, and they should be null if omitted.
I don't have much opinion on the names (they seem fine), but I think it's a question worth asking.
mirisuzanne commentedon Mar 21, 2023
I agree that the names seem fine to me. Other terms that get used for these concepts are 'root', and 'boundary' or 'limit'.
tabatkins commentedon Mar 21, 2023
I'm fine with the names as well. I could think of some different ones, but nothing seems better, and quite a bit seem worse.
nullwhen omitted is indeed correct imo. There's a lot of stuff in CSSOM that uses empty string for this semantic and I think that's just terrible legacy design, and doesn't need to be emulated.Yeah, omit the wrapping parens so the values are just the selectors themselves. The parens are a syntactic necessity for the rule itself, they're not part of the start/end bits.
tabatkins commentedon Mar 21, 2023
Well, wrt the names, I actually suggested
upperandloweras option-bag property names in qSA() over in #7709 (comment). Those might be a little better?bramus commentedon Mar 22, 2023
Does
upperandlowermake sense with@scope-siblings? My hunch would be thatstartandendis better, especially if the suggested:scope-endselector would make it.tabatkins commentedon Mar 22, 2023
Yeah that's a good point, so let's stick with the more generic
startandend.mirisuzanne commentedon Mar 23, 2023
Does this seem like a good candidate for async resolution? I think so. Proposal is:
start/endtermsnullwhen missingbramus commentedon Mar 24, 2023
SGTM
css-meeting-bot commentedon Mar 29, 2023
The CSS Working Group just discussed
[css-cascade-6] What is the desired shape of CSSScopeRule?, and agreed to the following:RESOLVED: Accept the CSSScopeRule design, with the three changes noted in the thread.The full IRC log of that discussion
<TabAtkins> miriam: Anders pushed a definition for the CSSSCopeRule, in the ED<TabAtkins> miriam: We didn't ahve a resolution on the details tho, so wanted to clarify it's defined properly
<TabAtkins> miriam: Main qs in the thread are terms used for the start and end fo the scope (sometimes called "root" and "lower boudnary"/"scoping limit")
<TabAtkins> miriam: In thread we decided start/end were clearest terms, especially if we do sibling scopes - they keep making sense, while upper/lower dont'
<TabAtkins> miriam: Another q is what to return if one of the values isn't specified, we suggest null
<TabAtkins> miriam: Final q, should the value contain the parens around the selectors? Propose no.
<Rossen_> q?
<TabAtkins> miriam: So proposal is accept the CSSScopeRule, with the three conclusions outlined above.
<fantasai> +1
<bramus> +1
<TabAtkins> Rossen_: Looks like agreement in the thread, anyone have objections?
<TabAtkins> RESOLVED: Accept the CSSScopeRule design, with the three changes noted in the thread.
[css-cascade-6] Make CSSScopeRule.start/end optional
[css-cascade-6] Make CSSScopeRule.start/end optional (#8716)