Which standard defines :defined

[annevk]

HTML suggests https://html.spec.whatwg.org/#pseudo-classes are all defined in Selectors and CSS UI, but that doesn't appear to be the case for :defined.

cc @snuggs

[domenic]

What?

HTML defines :defined, in the section you linked to:

:defined
The :defined pseudo-class must match any element that is defined.

This is the same as how it defines most pseudo-classes, in that same section.

[annevk]

That section only defines when those pseudo-classes match HTML elements. The actual pseudo-classes themselves are defined by Selectors and UI Events.

(It's not always entirely clear to me what purpose that distinction serves, but it's there.)

[domenic]

Can we just not have that distinction, for :defined? I think that's what I was assuming.

I guess that's where we need CSS experts like @tabatkins.

[annevk]

Maybe, but then we should probably say something more in that section, that it also defines some pseudo-classes rather than just define when they match.

[tabatkins]

The purpose of the distinction is that the CSSWG typically defines the actual CSS thing, and when necessary, the host language fills in whatever language-specific details are required. This distinction isn't theoretical wankery; SVG and HTML define things separately sometimes (or at least did in the past).

But there's nothing theoretically wrong with another spec defining a pseudo-class, so long as it has enough visibility for the correct implementors to know about it.

[snuggs]

@annevk @domenic @tabatkins thanks for the clarity. Out of curiosity how does this impact us with the Element#matches DOM api implementation? Trying to think of where interest has been forming around :defined. On average is trivially used for loading states. As we know, only assuming trivial use cases is often a footgun.

https://dom.spec.whatwg.org/#dom-element-matches

The actual pseudo-classes themselves are defined by Selectors and UI Events. - @annevk

Typically UI Events cover canonical pseudo selectors (i.e. :hover). Would :defined be considered a "UI Event" or more of a side effect of a successful element upgrade routine from HTMLUknownElement? Feels more the latter IMHO.

[annevk]

@tabatkins SVG and HTML aren't really separate languages/hosts though. They can be intertwined. I think it only works if there's a completely separate runtime of sorts that also happened to use Selectors, which I realize may be the case and I don't really object to the distinction per se (although I think in some areas it has caused a bunch of trouble due to the abstraction not being perfect).

So the CSS WG doesn't object to HTML defining new pseudo-classes? And how HTML decides to name them? That used to be much more controversial at least.

[tabatkins]

SVG and HTML aren't really separate languages/hosts though. They can be intertwined.

Of course, but they are allowed to give different definitions to how/when particular pseudo-classes match.

So the CSS WG doesn't object to HTML defining new pseudo-classes? And how HTML decides to name them? That used to be much more controversial at least.

As I said, "so long as it has enough visibility for the correct implementors to know about it". In practice, the "correct implementors" are CSSWG members. So other specs can be the home for a particular pseudo-class’s definition, but the act of defining it still generally has to make at least a cursory pass thru the CSSWG.

[domenic]

I don't really understand the next steps here, nor do I understand what is confusing about the status quo, so I am unassigning myself. If someone wants to pick this up I'll happily review patches.

[tabatkins]

Basically: it's fine for HTML to define :defined. At most, it might need some cleanup of the text that says all pseudoclasses are defined in Selectors and just given HTML-specific definitions here, to instead allow HTML to be the canonical definition for this one.

[TakayoshiKochi]

FYI - @jyasskin taught me https://drafts.csswg.org/indexes/#selectors has the list of pointers to where each pseudo selector is defined (a caveat that the list can fall out of date sometimes).

[tabatkins]

It's exactly as up-to-date as the Bikeshed database is, module some delay in running the spider and regenning the CSSWG specs.

[TakayoshiKochi]

So as long as the list above is the most reliable source of the complete list, everyone is happy?
If so, let's close this.

[annevk]

Yeah we can close this I suppose. I'll leave the upstream issue open since that still feels unresolved.