Open LeaVerou opened 3 weeks ago
domenic
commented
2 weeks ago This is just a proposed change to conformance requirements, as I understand it, so I'll re-tag a bit.
One possible consideration here is accessibility. E.g., we may want to require that <li> elements are children of custom elements whose default ARIA role semantics (as set by elementInternals.role) are list.
stevefaulkner
commented
2 weeks ago allow any element to have a custom element as a parent.
Sounds OK, but the custom parent element would need to have a role that allows role="listitem" or role="option" as children no? Unless the <option> or <li> default roles are overwritten by an explicit role.
from ARIA 1.3 editors draft: https://w3c.github.io/aria/
Authors MUST ensure elements whose role is listitem are accessibility children of an element whose role is list.
Authors MUST ensure elements with role option are accessibility children of an element with role listbox or of an element with role group that is the accessibility child of an element with role listbox. Options not associated with a listbox might not be correctly mapped to an accessibility API.
LeaVerou
commented
2 weeks ago I think framing it around roles, rather than element types makes a lot of sense! 💯
What problem are you trying to solve?
Certain elements, such as
<li>or<option>are only permitted within certain element types. Should this perhaps be expanded to custom elements? Many use cases where a custom element may reasonably want to slot these.What solutions exist today?
Currently they need to invent their own elements (e.g.
<sl-option>) that provide no functionality, and just mirror the API of these.How would you solve it?
If there is no parser weirdness, allow any element to have a custom element as a parent. @annevk thought that sounds reasonable, with that caveat.
Anything else?
No need to do it all at once, it could be done one element at a time, starting from
<li>and<option>, which are the ones I most frequently needed to slot personally.