Error recovery in :is(), :has() etc.?

[facelessuser]

It seems a decision was recently made that CSS level 4 selectors that take selector lists (:has(), :is(), :nth-child(), etc.) will have error recovery. This will not apply to :not() though. Essentially :is(:nonsense) would translate to :is(:not(*)).

Some things are still unclear though. Does this mean that they take any bad syntax? Like, if we give something like :is(.some $crazy 222 << nonsense, div.valid), would we still get :is(div.valid) or is there some limit to recovery? Is it limited to bad pseudo-classes? Could it handle bad combinators, and how would you determine it without just accepting any kind of bad syntax? Do you just gobble up bad syntax until you hit either a , or )?

Aside from all of this, do we need this implemented? Something to think about.

[facelessuser]

So, I've been thinking about this as I've been playing with #224. As this experimental :in() pseudo-class sounds like it would be a forgiving selector list as well.

I think what I've decided is that we will forgive simple things like empty slots (: is(this,, this), :is(), :is(,), etc.).

I understand from a CSS perspective why this may be nice. You can specify new features and such, but fallback to a working state if the browser doesn't support the new feature. But from a SoupSieve perspective, we are the only environment, and it is immensely helpful to know when you are doing something unsupported.

I'd prefer to not complicate the parser process more to start trying to identify every failure, categorize it depending on whether we're in a forgiving list or not, but I something simple like commas and empty lists, we can accommodate. I think the feedback to the programmer that they are using bad syntax also is a benefit when you want to know the script is going to do what you think it's supposed to do.