W3C Working Draft, editor's draft

When implementing things I tend to work from pages on w3.org such as https://www.w3.org/TR/selectors-4/. https://css4-selectors.com/ seems to have not been updated for the 21 November 2018 revision, and editor's drafts seem like they can be arbitrarily updated versus published drafts such as https://www.w3.org/TR/2018/WD-selectors-4-20181121/.

I note the grammar for <combinator> and <attr-matcher> in selectors-4 doesn't match the tokenization in css-syntax-3, in that it seems to be expecting <delim-token>s rather than <include-match-token>, <dash-match-token>, <prefix-match-token>, <suffix-match-token>, <substring-match-token>, and <column-token>. Either the tokenizer or the matchers would have to be adjusted to harmonize the two. It'd be nice if they'd publish a new draft of css-syntax-3 if they're going to depend on such changes in a published draft, instead of just leaving them in the editor's draft...

We'll need to think about the "live" versus "snapshot" profile thing. TemplateStyles will want "live", while Parsoid-PHP would potentially want "snapshot".

• case-insensitive attribute selector is used by Parsoid (since the spec requires http-equiv to be case insensitive) although easy to work around in other ways

Seems straightforward enough to implement. I note the grammar for <attr-modifier> only mentions "i" while the prose description also mentions "s" (apparently someone forgot to update the grammar).

• seems useful and mostly supported: [...] :matches once Chrome unflags it (poor man's LESS nested syntax), [...]
• seems very useful but support is poor: [...] ,:has (makes selectors a lot more powerful), [...]

https://www.w3.org/TR/selectors-4/#matches seems to have renamed it again to :is(). It's not clear to me what kind of "selector list" it's referring to, although it seems both Firefox 65 and Chromium 72 interpret it as a "compound selector list" (not a "complex selector list").

Implementation of either doesn't seem hugely complicated, although we'd need to implement matchers for a "compound selector list" and "relative selector list".

I note :has() is the only difference between the "live" and "snapshot" profiles.

• seems useful and mostly supported: :focus-within (for pure CSS menus/tabs, intelligent highlighting on keyboard navigation...), [...], placeholder (for pure-CSS non-confusing placeholder styling)
• somewhat supported but seems mildly useful at best: optionality, indeterminate, validity, range, default
• seems very useful but support is poor: :dir (for LTR support), [...], grid pseudo-classes and column combination (for table column styling), :target-within (for intelligent highlighting on anchor navigation)

All these look pretty trivial to implement in css-sanitizer.

Support for this. For instance, it would be really nice to be able to use :is() (and its sibling :where()) and its opposite :not().

In T217722#8747312, @Od1n wrote:

Support for this. For instance, it would be really nice to be able to use :is() (and its sibling :where()) and its opposite :not().

:not(.a):not(.b) is already supported as an older spelling of :not(.a, .b), FYI.

By the way, when editing a "sanitized-css" page, is it possible is know if the CSS code I am supplying is supported?

Currently, when I do « Show preview » and even « Preview page with this template », absolutely no warning is displayed.
When I do « Publish changes », the save is rejected and an error message is displayed, but it would be very helpful to have the information without having to (or try to) publish the page.

Should already do that per T266157#7450639. Have you tried actually unrecognized CSS?

Indeed. Even after letting the cat type on the keyboard, there are no warnings when previewing.

I have Show preview without reloading the page feature enabled, I also tried with the feature disabled but I also don't have warnings.

Please open a new task then.

With the upcoming dark mode, TemplateStyles stylesheets get bigger and also more complex (see this discussion at dewiki for an example). It would be nice to have TemplateStyles abilities extended with some more modern css. Browser support shouldn't be that much of a problem anymore five years after this task was created.