Re: [csswg-drafts] [selectors4] Name the “functional pseudo-class like :matches() with 0 specificity”

I tried to sum up the main possibilities discussed:
1. Leave things unchanged (`:matches()` with dynamic specificity, `:is()` for no specificity). Pros: cheaper for implementors, "Ignore Specificity" as a backronym for `:is()`. Cons: potential confusion because of suboptimal naming.
2. Try to mitigate the confusion by renaming on of the pseudo-classes. Cons: the potential confusion still exists because there are still 2 pseudo-classes with very similar functionality, `:is()` still looks much better that all alternatives, and renaming `:matches` "is not free".
3. Merge the two pseudo-classes into one. Common pro: no confusion.
    * Leave only `:matches()`, behaving as currently specified/implemented by default and ignoring/adjusting specificity when an extra argument is supplied. Pro: cheaper for implementors. Con: worse for authors because of longer and less-intuitive name.
    * Drop `:matches()` in favor of `:is()`. Default the behavior of `:is()` to [one of these options](https://github.com/w3c/csswg-drafts/issues/1027#issuecomment-354655842) and introduce the extra argument to explicitly control its specificity. Pros: just one extremely powerful selector with a short and clear name, which is good for authors. Cons: "rude to implementors" (potentially leading to higher risk of "fear of non-finalized features" and "no CR before 2 implementations/no implementations before CR" deadlocks in the future), `:is()` is no more a backronym (or needs a better backronym to be found).

Did I miss anything important?


-- 
GitHub Notification of comment by SelenIT
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-355236399 using your GitHub account

Received on Thursday, 4 January 2018 09:29:51 UTC