Webcomponents: Add global reflecting attributes to ElementInternals?

[justinfagnani]

Since reflecting IDL attributes create HTML attributes on an element when set, and there may be cases where that's undesired, or even disallowed (setting attributes in a constructor) - should some or all of the global attributes have properties added to ElementInternals? And should global attributes going forward be added to ElementInternals?

A use case would be an element that wants to perform some initialize a value in a custom element constructor

class MyElement extends HTMLElement {
  constructor() {
    this.title = 'A Custom Element';
  }
}

This will report an error because the title attribute is created. I've seen people hit this with title and recently with ariaPressed in Safari. ariaPressed will be handled by ElementInternals, so should other attributes be to?

Looking at the current list of global attributes, including title (but excluding tabindex, which might be covered differently like in #762) I could possibly see arguments that they're not actually internal and _should_ only be set externally, ie an element shouldn't sprout it's own tooltip, but I'm not sure if or how that's been rationalized yet.

[domenic]

ElementInternals is for setting internal values. ariaPressed will be "handled" by ElementInternals, but not in the same way that setAttribute("aria-pressed", ...) does. Instead it will set the default aria-pressed semantic. (Maybe we should rename it defaultARIAPressed.)

The example code you give doesn't seem to be a use case; I'm unclear what it's saying. Is the author trying to use title, unaware that it's a reflecting setter? Are they trying to set the title attribute, but unaware that you're not supposed to do that in constructors? I think there are clear solutions for either of those use cases (e.g., use a different name, or use connectedCallback, respectively) that don't require new spec and implementation work on ElementInternals.

So in general I agree with your last paragraph; the global attributes are generally not internal things (like default ARIA semantics are) and it doesn't make much sense to put them on ElementInternals.

[justinfagnani]

The example code you give doesn't seem to be a use case; I'm unclear what it's saying. Is the author trying to use title, unaware that it's a reflecting setter? Are they trying to set the title attribute, but unaware that you're not supposed to do that in constructors?

I think the intent was just to add a tooltip, and the title attribute is the mechanism available. Is that something that should always be done via title attribute? If so, and if attribute are for external uses, does that imply that custom elements should never add tooltips to themselves?

If that's _not_ the conclusion, then is the correct way to do this to set the title attribute in connectedCallback, or is this the kind of thing where there should also be an internal default, overridable by the public attribute?

edit: defaultARIAPressed does sound clearer for its purpose.

[rniwa]

The example code you give doesn't seem to be a use case; I'm unclear what it's saying. Is the author trying to use title, unaware that it's a reflecting setter? Are they trying to set the title attribute, but unaware that you're not supposed to do that in constructors?

I think the intent was just to add a tooltip, and the title attribute is the mechanism available. Is that something that should always be done via title attribute? If so, and if attribute are for external uses, does that imply that custom elements should never add tooltips to themselves?

Just adding a tooltip is a misguided way of thinking about title content attribute. But that aside, given there is no builtin element which sets title content attribute or any sort of default for its advisory information, I don't think custom elements implementations should do it either. title content attribute should be set by the users of custom elements instead.