aom
aom copied to clipboard
Web component semantics
https://github.com/w3c/webcomponents/issues/758 raises some doubts about using ShadowRoot
to encapsulate semantics for web components.
I've written up two versions of some spec changes to try and formalise some of the ideas discussed in the explainer around web component semantics:
Would appreciate some guidance/discussion around these two options!
I will probably favor ElementSemantics
at this point. Probably a different name, but I don't have a better alternative. IMO citizen developers usually reject the word "semantics" for whatever reason that I don't understand.
On the pro-ShadowRoot
side:
-
AccessibilityRole
andAriaAttributes
are already mixed in toElement
, so it is intuitive to mix them in toShadowRoot
as well, since they are both subclasses ofNode
-
ShadowRoot
encapsulates the appearance (via css:host
) and structure of an element, so it seems logical for it to encapsulate the related accessibility semantics - Having semantics on
ShadowRoot
make them more easily available for testing (you could imagine using open mode for testing and closed mode for production)
On the pro-ElementSemantics
side (sigh, naming):
- Keep all the semantics things in one place (the custom element definition, between the constructor and the options object)
- No need to attach a shadow root just to encapsulate semantics if you wouldn't have otherwise used one (how likely is this?)
ElementSemantics
for me too. It feels like the most familiar with what developers are currently accustomed to with regards to defining semantics on DOM nodes.
It also feels overly complicated to have 2 separate ways to achieve the same thing, so simplification is good.
And no need to attach a shadow root just to encapsulate semantics is a pro for me too
@SiTaggart
It feels like the most familiar with what developers are currently accustomed to with regards to defining semantics on DOM nodes.
I don't quite follow. Any chance you could elaborate a little on this?
Well, unless I'm completely misreading everything which is quite possible, with semantics only ever being defined by the element and it's object, it's directly familiar with what we have right now. An element defines it's semantic through attributes and it's API.
By placing some of an elements semantic meaning, or at least a way of defining it, onto it's shadowRoot
, that's something totally alien to most seasoned developers in the world right now. My suspicion, and even to me now, a shadowRoot
is just this mysterious thing that's not the element, and it being able to define semantics might just be jarring or weird.
Hopefully that makes some sense
@SiTaggart That makes sense - I think the issue is with explaining how setting something on a completely separate node affects the host element, is that right?
Thanks for clarifying!
@alice
Thank you for filing an issue. I prefer ElementSemantics
here.
+1 for ElementSemantics
as well
Yup, that sums it up nicely @alice
I used to favor ShadowRoot
for this since it offers encapsulation, but ElementSemantics
(indeed, naming might need work...) offers that too and can be used by custom elements that do not warrant a ShadowRoot
. In addition I think this is worthwhile as ElementSemantics
would only work for custom elements, whereas ShadowRoot
also works for, e.g., h1
which already has some associated semantics. I think that would get rather muddy.
ElementSemantics
seems like it just 'fits' better than anything else I've seen proposed. Honestly, I don't even think that is a bad name.
Should I be able to set tabindex
as well using the ElementDefinitionOptions
object? I realize it's not the same as semantics, but they are related and I'd want every instance to have the same behavior.
@robdodson Check out the discussion over on https://github.com/w3c/webcomponents/issues/762