Re: [w3c/webcomponents] Custom attribute names conflicting with built-in attribute names (#654)

I like the proposal for custom attributes, but this feels a bit different. Attributes are declarative properties that can only accept strings. Many times these are linked (even if one-way) to a property with a very similar - if not same - name. Props are the imperative API (unless you have a declarative abstraction on top of them).

Props behave differently to attributes in the fact that you can override them and callback to the parent if needed (`super.someProp = value`). Props are resilient to the described problem because of this. Adding a conflicting prop to one that a custom element defines would not break a custom element (unless it was defined as non-configurable, of course).

Attributes could benefit in the same way if for `observedAttributes` you were required to call `super.attributeChangedCallback()` in order to get the overridden behaviour. Unfortunately this requires this be implemented at the `HTMLElement` level and this probably would be difficult to implement at the browser level. I'm probably not thinking of something else, but hopefully that makes sense.

If we really shouldn't be using non-prefixed attributes, there needs to be something that discourages this.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/654#issuecomment-320880996