[css-cascade-6] Should `@scope`'s `<scope-start>` & `<scope-end>` be unforgiving?

[dshin-moz]

As per the discussion log in making has unforgiving in issue #7676, it seemed like the forgiving behaviour was to be restricted to :is/:where. This is reflected in the spec's note.

On the other hand, <scope-start> and <scope-end> currently are specified as <forgiving-selector-list>.

[tabatkins]

Sigh, yeah, we probably should make them unforgiving. We wanted to make sure that the learnability was reasonable for where selectors were forgiving vs not, and settled on :is()/:where() being the only places where we'd use forgivingness.

[css-meeting-bot]

The CSS Working Group just discussed [css-cascade-6] Should `@scope`'s `<scope-start>` & `<scope-end>` be unforgiving?, and agreed to the following:

• RESOLVED: @scope start and end selectors are unforgiving

The full IRC log of that discussion

<jarhar> TabAtkins: we specified at some point that the scope start and scope end selectors use forgiving selector list. we were hoping we could use it as many places as we could, and we later changed that decision and ended up locking it down and making forgiving selectors to only be used in is and where. this spot was missed so we should match precedent
<jarhar> and make these forgiving as well
<jarhar> TabAtkins: if you have a comma separated selector list, unforgiving is where whole thing gets dropped and is invalid
<jarhar> TabAtkins: you can always recover forgiveness by wraping in is, mostly
<jarhar> astearns: anyone that wants to make the argument that is and where are the only things we should make forgiving?
<jarhar> miriam: scope is somewhat where like
<jarhar> TabAtkins: we ended up leaning more toward learnability, nearly identical functions which are mostly noop and everywhere is just normal, the terrible css evolved
<jarhar> astearns: tab have you looked to see where we have forgiving in other places we should not have
<jarhar> TabAtkins: a quick grep would estabish
<jarhar> astearns: alright. any other comments?
<jarhar> astearns: it is possible to make these forgiving
<jarhar> miriam: forgiving selectors are good for authors and if we can use them more then we should
<jarhar> fantasai: we can make an argument that it might not matter as much fo rscope start whether its forvinging or not because a forgiving scope start selector it just means that it snot gonna match what you thought it was going to match, typically how selectors work.
<jarhar> fantasai: in a scope end selector if you have a forgiving and you use a selector that is not suposerted then your styles will apply to a whole bunch of things you didnt expect and could be a mes
<emilio> q+
<jarhar> fantasai: for scope end its important that its unforgiving
<emilio> q-
<jarhar> fantasai: making it forgiving in scope start is easier to understand
<astearns> ack dbaron
<Zakim> dbaron, you wanted to discuss audit results
<fantasai> miriam: I accept that logic!
<jarhar> dbaron: i just did the grep, it looks like were ok, there were 3 specs that did forgiving, selectors 4 makes is use it ??? one of them is ??? one of them is nesting 1 which has intentional prose about how ampersand in a selector list for forgiving selectors. i think this is it unless there is something that says i use the same syntax as is or where
<fantasai> RESOLVED: @scope start and end selectors are unforgiving
<dbaron> selectors-4 defines it, makes :is() use it, and makes :where() like :is(); cascade-6 was the issue we just dealt with, and css-nesting-1 has some prose about & inside of forgiving-selector-list
<jarhar> fantasai: you can make it forgiving explicitly