Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Misuse of data- attributes #157

Closed
adactio opened this issue Jul 21, 2020 · 3 comments
Closed

Misuse of data- attributes #157

adactio opened this issue Jul 21, 2020 · 3 comments

Comments

@adactio
Copy link

adactio commented Jul 21, 2020

I've checked previous discussions ( like this one: https://github.com/w3c/personalization-semantics/wiki/Prototypes-with-data-dash-*-(Take-2) ) but I can't find any debate about misusing data- attributes in the way being proposed here.

As I understand it, this is exactly what data- attributes are not for—parsing by user agents. They are explicitly provided for site-specific use.

Other extensibility mechanisms are available that don't prohibit parsing by user agents (e.g. the class attribute, microdata attributes, the property attribute). Has there been any discusison about using one of those rather than jumping straight to data- attributes?

https://www.w3.org/TR/html52/dom.html#embedding-custom-non-visible-data-with-the-data-attributes

These attributes are not intended for use by software that is not known to the administrators of the site that uses the attributes. For generic extensions that are to be used by multiple independent tools, either this specification should be extended to provide the feature explicitly, or a technology like microdata should be used (with a standardized vocabulary).

For instance, a site about music could annotate list items representing tracks in an album with custom data attributes containing the length of each track. This information could then be used by the site itself to allow the user to sort the list by track length, or to filter the list for tracks of certain lengths.

It would be inappropriate, however, for the user to use generic software not associated with that music site to search for tracks of a certain length by looking at this data.

This is because these attributes are intended for use by the site’s own scripts, and are not a generic extension mechanism for publicly-usable metadata.

Most importantly:

User agents must not derive any implementation behavior from these attributes or values. Specifications intended for user agents must not define these attributes to have any meaningful values.

The Personalization Semantics proposal is in direct violation of HTML5.2 — one of them needs to change.

@johnfoliot
Copy link
Contributor

Has there been any discussion about using one of those rather than jumping straight to data- attributes?

Yes: https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content

Most importantly:

User agents must not derive any implementation behavior from these attributes or values. Specifications intended for user agents must not define these attributes to have any meaningful values.

This depends on how you define user-agent. As this is all "new technology" we're still building out tooling and helper-apps to consume these attributes, and so we're using the 'experimental' prefix to, well, experiment. It is also worth noting that this task force pivoted to using data-* attributes based on direct and in-person feedback from the W3C's TAG during TPAC 2018.

Ideally, these newly proposed attributes will eventually emerge as non-prefixed attributes, but the TF understands that some of the proposed attributes may not 'pass muster' as un-prefixed attributes, at which point we'd look to TAG/WHAT WG/et al. to return to our group with a proposed prefix to use: one that browser vendors etc. agree to/with as well.

This is similar to how ARIA advanced, with @ROLE (which was critical to ARIA) becoming a 'fully-fledged' attribute (non-prefixed) in HTML5, whereas others (ARIA properties) are prefixed, and ARIA attribute values are either fixed terms or text string (similar to what we have with Personalization).

@snidersd
Copy link
Member

snidersd commented Nov 9, 2020

Closing the issue as per John's response.

@snidersd snidersd closed this as completed Nov 9, 2020
@adactio
Copy link
Author

adactio commented Nov 9, 2020

Uh ...okay. I guess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants