Add a CSS selector to only target built in elements

[KonnorRogers]

Proposal

Add a selector to only target built in elements.

Why?

with custom elements being more and more prevalent, it's sometimes important to separate custom elements from built in elements, especially with things like CSS resets.

common scenario in a CSS reset such as Tailwind:

* {
  border: 0;
}

but this can mess up custom elements that use a :host { border: 1px solid black; } css rule.

with a pseudo selector like :builtin CSS resets could target only built in elements.

:builtin {
  border: 0;
}

other scenarios:

• Form Controls. with the advent of Form Associated Custom Elements, :invalid, :valid, et al may have unintended consequences if used on custom elements. With :builtin:disabled for example you can guarantee you're only targeting native elements.

:builtin:invalid {
  outline: 2px solid red;
}

• setting display: contents; on all custom elements regardless of if they're defined or not.

:not(:builtin) {
  display: contents;
}

issues with :defined

:defined is too broad since it will count both defined custom elements and built in elements and there's no way to distinguish.

:not(:defined) misses cases where you define a custom element but it only is defined for attaching JS and has no presentational aspect.

[sorvell]

Is this the same as https://github.com/w3c/csswg-drafts/issues/11001?

[Westbrook]

Quite similar! 😳

So many issues to track, so little time...

I do like having a cogent use case. Though data on whether el.matches(':not(:builtin)') or !!customElements.getName(el) would end up being faster for a framework to leverage could sway me to seeing the benefit of approach this for those goals.

I was also immediately confused by the implicit timeline of :predefined being the state before :defined, which is not really what this is saying. However, that is also a previous request as seen in https://github.com/whatwg/html/issues/6231.

Together does this sort of hat trick get this Agenda +'d?