johnfoliot
commented
4 years ago Hello Pär,
[Speaking as an individual member of the Task Force:] As one of the folks actively involved in the discussions, I can confirm we are aware of the concerns you are raising, but are also following guidance provided to us from the Technical Architecture Group (TAG) at the W3C. We are actually using data-* in the fashion precisely envisioned when it was added to HTML 5.
One of our overarching goals is to try and have non-prefixed attributes as much as possible (so, for example, we want ultimately to have @purpose="" as opposed to @data-purpose="" or even @tbdprefix-purpose=""), but to achieve that, we have to first deliver some proof of concepts, and determine which if any/all of our proposed attributes might advance prefix-free. We believe we've got a great proposed solution here, but we have no evidence or proof that it's workable or scalable today - and that's a problem - and it's a chicken or egg problem as well (no tools because there is no solution, no solution because there are no tools: data-* helps break that vicious circle).
So, data-* is not intended for a "final" name, but rather an experimental name for now, as we gather-up the necessary implementation experience and user-feedback data as part of the maturing process. In many ways, it is similar to browser-prefixed CSS before they become "fully baked" or prefix free. (BTW, we also looked at using MicroData, but decided at this time it was overly complex to author at the element level.)
We also have precedent for this approach with ARIA, where a
critical attribute - @role - advanced prefix free into HTML5, but other
ARIA attributes remain prefixed with aria-. It is my personal hope that
we'll be even more successful this time around, and that we'll get multiple
attributes "folded in" directly into HTML 5!
One concern I (at least) have early-on is to avoid 'ghettoizing' these attributes by using a "special" prefix (read: "for disabled people only"), as it has been my experience over the past years that an approach like that is a barrier to adoption more broadly. I think we all understand that not all of our proposed attributes will advance prefix free, but rather than pre-judging that, we'd rather (at least I'd rather) presume all will go through prefix-free, and then later being told "...We can only really justify 60% of your attributes advancing prefix-free..." after which THEN we can have the discussion with the browser vendors and other W3C stakeholders to choose a better prefix (which MAY be one of either AUI-, or ARIA-, or TBC-). The reality is that we need other stakeholders to join us*, including the browser vendors and other tool vendors, and they aren't very inclined to take "dictated" solutions "...just because", so we're working within some constraints already.
Finally, it is also worth remembering that TAG understood these goals, and thus suggested we start with @data-* 2 years ago at our annual meetings (TPAC 2018)
Note that this is not a 100% consensus position at this time - we are actually still discussing this within the Task Force. But we've gone around the block on this topic more than once, and I suspect that at this time, we want to move forward with what we have and start soliciting wider review and feedback, so your observations and comments are both welcome and will be taken into account going forward. (So THANK YOU!) Hopefully this helps you better understand "the plan" (at least as I understand it) regarding the naming pattern both short-term and longer-term.
JF
On Thu, Feb 20, 2020 at 3:31 PM Pär Lannerö notifications@github.com wrote:
The document "Comparison of ways to use vocabulary in content" makes it obvious that the selection of prefix "data-" was done after a serious consideration of the options. Thanks!
However, when I presented the Personalization documents to a group of a11y people in Sweden, several of them objected to the use of "data-" as a prefix to be used for standardized semantics. The main argument being that there's a significant risk that a "data-*" attribute (eg "data-action") is used with an entirely different meaning, causing confusion.
In the "Comparison" document, at https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content#-data-set-data--or-data-aui--attributes the pros and cons of "Data set" attributes are listed under "data- or data-aui-", but in the draft recommendation only "data-" is being used. It appears to me that - although longer - "data-aui-" would be considerably less likely to be already used for some other purpose, and therefore a better compromise.
Unfortunately, all web-wide use of "data-" seems to be in conflict with the HTML 5.2 specification: "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).", and a bit further down (in Example 21): "these attributes are intended for use by the site’s own scripts, and are not a generic extension mechanism for publicly-usable metadata." https://www.w3.org/TR/html52/dom.html#embedding-custom-non-visible-data-with-the-data-attributes
Perhaps you already discussed these factors? If you didn't, and if it is not too late, I would suggest at least to change from data- to data-aui- in order to minimize conflicting semantics. Or even go for the microformat/itemprop construction if the W3C wants to use the momentum from ongoing accessibility regulation to further such generic frameworks for a more semantic web. Perhaps a question for the TAG?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/personalization-semantics/issues/137?email_source=notifications&email_token=AAJL445G6HQE7VMQ3AU6CV3RD3ZDZA5CNFSM4KYXIM32YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IPD5MGQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJL444Y6CVOVDF655NJ4PDRD3ZDZANCNFSM4KYXIM3Q .
-- John Foliot | Principal Accessibility Strategist | W3C AC Representative Deque Systems - Accessibility for Good deque.com
plannero
MelSumner
The document "Comparison of ways to use vocabulary in content" makes it obvious that the selection of prefix "data-" was done after a serious consideration of the options. Thanks!
However, when I presented the Personalization documents to a group of a11y people in Sweden, several of them objected to the use of "data-" as a prefix to be used for standardized semantics. The main argument being that there's a significant risk that a "data-*" attribute (eg "data-action") is used with an entirely different meaning, causing confusion.
In the "Comparison" document, at https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content#-data-set-data--or-data-aui--attributes the pros and cons of "Data set" attributes are listed under "data- or data-aui-", but in the draft recommendation only "data-" is being used. It appears to me that - although longer - "data-aui-" would be considerably less likely to be already used for some other purpose, and therefore a better compromise.
Unfortunately, all web-wide use of "data-" seems to be in conflict with the HTML 5.2 specification: "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).", and a bit further down (in Example 21): "these attributes are intended for use by the site’s own scripts, and are not a generic extension mechanism for publicly-usable metadata." https://www.w3.org/TR/html52/dom.html#embedding-custom-non-visible-data-with-the-data-attributes
Perhaps you already discussed these factors? If you didn't, and if it is not too late, I would suggest at least to change from data- to data-aui- in order to minimize conflicting semantics. Or even go for the microformat/itemprop construction if the W3C wants to use the momentum from ongoing accessibility regulation to further such generic frameworks for a more semantic web. Perhaps a question for the TAG?