Protocols/traits for custom elements

[annevk]

I have some high-level concerns around custom element form controls that I wasn't sure where to raise so I thought I'd bring them up here since they are mostly future-focused.

The current approach seems to be done in such a way that you can be both a form control and a link (if we added custom element links).

1. Is this desirable? I think in general the answer here is definitely as we need multiple protocols/traits for certain custom elements (e.g., focus, various ARIA bits, and form controls go together in some fashion).
2. What about clashes? I'm worried that we'll end up losing oversight of all the possible interactions.
3. Should we perhaps do a little bit of work on what the various extension points might be (focus trait, ariaDescribedBy trait, link trait, label trait, ...) and see if we can foresee issues somehow?

cc @tkent-google @domenic

[domenic]

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.

[annevk]

FWIW, custom <label> came up at the last F2F.

Thus far it does indeed seem reasonable, but I am a little worried that the possible interactions between features might get rather involved, similar to how we never quite got <object> to work. But maybe if everything is fully designed from the start and tested there's less of a chance of running into that situation again.