Proposed response to Jeremy Keith

All,

This is my draft proposed response to Jeremy. Are there any objections to
my responding with this? Please advise.
______________________

> 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 pivotted 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 unprefixed 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).

-- 
*John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com
"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"