search

w3ctag / webcomponents-design-guidelines

https://w3ctag.github.io/webcomponents-design-guidelines/ - Guidelines for creating web platform compatible components
8 stars 8 forks source link

When to use data-* attributes #2

Open kenchris opened 5 years ago

kenchris commented 5 years ago

@slightlyoff

I have had some discussion about data-* attributes and custom elements.

I believe data-* attributes are for developers when they put together their app (using native and custom elements) and it is important that the data-* attributes are not being used by custom elements etc because then developers would have to start to worry about an attribute is being used or not

slightlyoff commented 5 years ago

Thanks for the ping.

I agree that data-* attributes make the most sense as a way for end-developers (consumers of WC) to add data to elements outside of the Custom Element's declared contract and that WC authors should not use them. That is, WC authors should not use the prefix in their observedAttributes.

plinss commented 5 years ago

I also agree about data-* attributes, but this still leaves the issue of future global attributes possibly conflicting with WC observedAttributes.

kenchris commented 5 years ago

@plinss that is a valid fear yes, but using data-* in custom elements, means that there is already a potential conflict with user data-* properties which I think is far worse.

Luckily the amount of new global attributes is quite low and some are even prefixed like the aria ones.

I assume that the observedAttributes override the new global attributes, so that it is up to the custom element author to fix their elements if they want to take advantage of the new global attributes.

plinss commented 5 years ago

Right, and I'm not proposing using data-*, as I agree with your reasoning. I'm just pointing out that there still is an issue. Since data-* is off the table, our options are:

  1. Create some other prefix for custom elements to use for their own attributes (ick, and doesn't help all the existing custom elements, or make it easy to standardize custom elements later).
  2. Recommend all new global attributes have a prefix to avoid conflicts with custom elements (and tell custom element authors to not use that prefix) (ick).
  3. Live with the current situation and hope for the best(🤷‍♂️).
  4. Invent something else. IIRC @slightlyoff has previously mentioned and idea along the lines of allowing custom elements to opt-in to the set of global attributes they will respect (and possibly how they relate to exposed properties, which has the same issue). I'd like to explore that more (and invite alternate solutions).

As much as XML namespaces had its issues, at least this was a problem that it solved. We lost something when we walked away from XML, and it would be nice to get the advantages back...