Re: [w3c/webcomponents] Protocols/traits for custom elements (#811)

Good discussion to have!

I think in general the approach we've favored is to expose primitives, which so far seem pretty orthogonal. At least in the spec (and in the Blink implementation), we have separate nobs for all the things we've considered so far:

- Form-control stuff
- Accessible roles/states/properties
- Focus
- Custom pseudo-classes
- "Simple" built-in pseudo classes (like `:checked`) which don't have invariants or interactions with other APIs. (As opposed to e.g. `:invalid` which interacts with all the validity state APIs.)

I think with the pseudo-classes we're starting to see a bit of an overlap, but in my opinion things are still orthogonal. For example, in both the spec and in the implementation, having the accessible-state of "checked" is distinct from matching `:checked`; the built-in checkbox control ties them together, but e.g. a `<div>` which uses `aria-checked=""` does not have any impact on `:checked`.

My other point to note is that I think the above list covers most of the high-priority items we've heard from on this issue tracker that developers want. We don't have an issue filed for e.g. custom `<label>`s or custom `<a>`s, probably because those elements are already fairly flexible. I guess we do have some issues filed for custom template and custom script, mostly around parsing behavior.

So although we could try to canvas all the possible capabilities of the built-ins and look for conflicts, I think we could also accept that we're starting to see a pretty complete picture, at least for now, and things look promising to me. Promising enough that I'd be comfortable handling future conflicts with more ad-hoc solutions, instead of trying to plan it too much ahead of time.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/811#issuecomment-490096631