Re: Personalization Task Force meeting minutes

Thanks John, some very considered points

 >   * JS: "Suggesting we want to be in the DOM. We need to decide early so
 >     we can understand what we are asking from the browsers."
 >     JF: By using data-*, we *will* be exposed in the DOM *today*,

+1. I did point out in the meeting there is an API for accessing the 
data-* attributes in addition to that used for accessing HTML specified 
attributes.

 >     browsers will not (at this time) do anything else with the data or
 >     values. (I don't think that's a bad thing per-se)

But web sites may do. There was a comment fed back to us that data-* is 
for INTERNAL site use. If we effectively reserve a data-* for our early 
spec there is then a risk we that will clash with someone's website use 
so they cannot easily include our spec to explore it.

However, this is pretty much a non issue right now for the reasons you 
point out later and will always be a tiny risk. So we can probably 
ignore it. I'll now shut up about this.

 >   * JS: "We can work with them on what the prefix should be. We need to
 >     lock down a prefix."
 >     JF: Do we?
[snip]
 >

This was my question too and I still don't have a clear understanding if 
we are at that point of implementation yet or should concentrate on 
getting feedback using the temporary attachment mechanism of data-*.

Are we able to define when we will know we are at (or close to) that 
point? As you point out it seems we need more data first (pun intended).

One suggestion for moving now was it can take a long time but that seems 
to assume we know all the answers already. It was also pointed out that 
even if we do have a few committed 'users' it should be relatively easy 
for them to search and replace the updated attachment mechanism.

Steve

On 03/02/2020 16:58, John Foliot wrote:
> Hi Sharon, Colleagues,
> 
> Thanks for this - I had a last-minute fire-drill and had to miss the 
> call. My apologies.
> 
> I see from the minutes some discussion around using the data-* mechanism 
> in our work. From the minutes (attributed to Janina):
> 
>        ... Two specific things to nail down. Are we ready to ask HTML WG
>     / WCAG, we've done what you ask. We need to move forward. Can we
>     replace it with a prefix?
>     ... We can work with them on what the prefix should be. We need to
>     lock down a prefix.
>     ... Second point, what is the minimum ask we have from the main
>     stream browsers?
>     ... Suggesting we want to be in the DOM. We need to decide early so
>     we can understand what we are asking from the browsers.
> 
> 
> The reason for using the data-* mechanism is because it is a tool that 
> HTML5 has given us. (see: 
> https://html.spec.whatwg.org/multipage/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes. 
> Another great explainer can be found here: 
> http://html5doctor.com/html5-custom-data-attributes/ )
> 
>     HTML5
>     <https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/HTML5> is
>     designed with extensibility in mind for data that should be
>     associated with a particular element but need not have any defined
>     meaning. |data-* |attributes
>     <https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/data-*> allow
>     us to store extra information on standard, semantic HTML elements
>     without other hacks such as non-standard attributes, extra
>     properties on DOM, or |Node.setUserData()|
>     <https://developer.mozilla.org/en-US/docs/Web/API/Node/setUserData>.
>     (source:
>     https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes)
> 
> 
> 
> The data-* attribute mechanism allows for the creation of custom 
> ("proprietary" [sic]) attributes that, 1) the browsers will 
> automatically pass-through to the DOM, and 2) will not throw errors with 
> the W3C code validator. The intent of data-* is to get implementation 
> experience, with (and this is the point) a longer-term goal that *IF* we 
> get sufficient implementation, we can then "drop" the prefix, so that 
> down the road, we'll ultimately end up (we hope) an attribute known as 
> "symbol" (versus our experimental attribute of data-symbol). I'll also 
> note that this has been a long-standing implementation mechanism at the 
> W3C, most notably with the CSS WG, where we've (in the past) seen 
> prefixed CSS attributes (see: 
> https://en.wikipedia.org/wiki/CSS_hack#Browser_prefixes)
> See also: https://en.wikipedia.org/wiki/CSS_hack#Example
> 
> This was the recommendation from TAG at the 23018 TPAC in Leon, as it 
> also helps avoid the "ghetto-izataion" of accessibility mechanisms (a 
> "problem" with ARIA today - it's directed exclusively towards specific 
> Assistive Technology tools, and NEVER impacts the UI - per an earlier 
> agreement between the ARIA WG and the browser vendors).
> 
> And so, to answer Janina's questions in reverse order:
> 
>   * JS: "Suggesting we want to be in the DOM. We need to decide early so
>     we can understand what we are asking from the browsers."
>     JF: By using data-*, we *will* be exposed in the DOM *today*, but
>     browsers will not (at this time) do anything else with the data or
>     values. (I don't think that's a bad thing per-se)
> 
>   * JS: "Second point, what is the minimum ask we have from the main
>     stream browsers?"
>     JF: Nothing at this time. Once we get an established collection of
>     attributes, we next need to get some implementation experience. One
>     answer from that exercise is to also determine whether this will be
>     a thing that browsers will need to do, or whether it will still
>     ultimately rely on helper-agents - whether they are browser
>     extensions or stand-alone software/hardware packages.
> 
>   * JS: "We can work with them on what the prefix should be. We need to
>     lock down a prefix."
>     JF: Do we? If the ultimate goal is to emerge with prefix-free
>     attributes (@purpose, @destination, @action), then experimenting
>     with data-purpose, data-destination and data-action (for example)
>     gives us the ability to test out implementations with valid code. If
>     ultimately we discover that not all of our proposed *data-attributes
>     advance to prefix free attributes, I'll suggest that *THEN* will be
>     the time for that discussion. (and, we've sorta had that discussion
>     already, looking at attributes such as AUI-*)
> 
>   * JS: "Are we ready to ask HTML WG / WCAG, we've done what you ask. We
>     need to move forward. Can we replace it with a prefix?"
>     JF: As this appears to be somewhat truncated minute entry, I'm not
>     100% clear on the statement/question, however I will argue that it
>     is far from ready to be taking to AG WG for inclusion in WCAG 2.2.
>     And replacing it with a prefix (???) does nothing but rearrange the
>     deck-chairs: any prefix is at some level meaningless (all it does is
>     sort of create a namespacing mechanism, without it being a namespace).
> 
> We have a great plan, we're making awesome progress, and it's cool that 
> we've already got implementers willing to work with our experimental 
> attributes. Everything is poised for more progress, but we've got 
> nothing on the ground today that works as envisioned (outside of early 
> experimental stuff, like the Proof of Concept work that Mozilla did 
> behind a browser flag).
> 
> As part of the Chartering of AG WG, it was agreed that as a matter of 
> practice we will be publishing updates to the collection of Success 
> Criteria on a two-year cycle. I will suggest that this gives us two 
> years to get some implementation experience, perhaps to the point where 
> we can approach WHAT WG and seek to have new attributes added to the 
> "mainstream" HTML5 specification. It has been my belief that to get 
> wider adoption of our work, relegating it to a prefixed attribute 
> long-term limits adoption.
> 
> Meanwhile, if any of our experimental attributes start to gain traction, 
> we can always seek to add new "Techniques" to the WCAG corpus, which are 
> both non-normative and are not linked to the 2-year publishing schedule 
> for WCAG (or whatever comes next) - Techniques can be added at any time.
> 
> <opinion>
> I'd very much like that we de-link our work from WCAG work at this time, 
> and stay focused on solving the problems we set out to solve. Getting a 
> Success Criteria into WCAG is a long process, and without implementation 
> experience we're trying to get the cart before the horse. And with the 
> impending deadline for WCAG 2.2, it's simply too late in the process (IMHO).
> </opinion>
> 
> JF
> 
> 
> 
> 
> 
> On Mon, Feb 3, 2020 at 10:01 AM Sharon D Snider <snidersd@us.ibm.com 
> <mailto:snidersd@us.ibm.com>> wrote:
> 
>     Hi all,
>     Here's a link to today's Personalization Task Force meeting minutes
>     - https://www.w3.org/2020/02/03-personalization-minutes.html
>     Regards,
>     Sharon Snider
>     IBM Hybrid Cloud ► IBM Accessibility Leadership Team
>     (512)965-3957
>     www.ibm.com/able <https://www.ibm.com/able> and w3.ibm.com/able
>     <https://w3.ibm.com/able>
>     Slack logo#accessibility-at-ibm
> 
> 
> 
> -- 
> *​John Foliot* | Principal Accessibility Strategist | W3C AC Representative
> Deque Systems - Accessibility for Good
> deque.com <http://deque.com/>
>

Received on Wednesday, 5 February 2020 10:14:44 UTC