Web component semantics

[alice]

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:

• Using ShadowRoot
• Adding a new ElementSemantics object

Would appreciate some guidance/discussion around these two options!

[caridy]

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.

[alice]

On the pro-ShadowRoot side:

• AccessibilityRole and AriaAttributes are already mixed in to Element, so it is intuitive to mix them in to ShadowRoot as well, since they are both subclasses of Node
• 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)

[alice]

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?)

[SiTaggart]

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

[alice]

@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?

[SiTaggart]

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

[alice]

@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!

[hayatoito]

@alice Thank you for filing an issue. I prefer ElementSemantics here.

[robdodson]

+1 for ElementSemantics as well

[SiTaggart]

Yup, that sums it up nicely @alice

[annevk]

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.

[bkardell]

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.

[robdodson]

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.

[alice]

@robdodson Check out the discussion over on https://github.com/w3c/webcomponents/issues/762