Re: Personalization Task Force meeting minutes

Hi, John:

We missed you on p13n.

To your first point, my suggestion to the call was that we needed to
decide very soon whether it is now time to ask for a permanent prefix. I
think I suggested at some point we should decide during February.

And, as to point #2 there was suggestion that the implications of a
permanent prefix actually would satisfy the minimum ask from browsers,
because values provided by our prefixed attributes would make it into
the DOM by definition.

Best,

Janina

John Foliot writes:
> 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> 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 and w3.ibm.com/able
> > [image: Slack logo]  #accessibility-at-ibm
> >
> >
> 
> -- 
> *​John Foliot* | Principal Accessibility Strategist | W3C AC Representative
> Deque Systems - Accessibility for Good
> deque.com

-- 

Janina Sajka

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Accessible Platform Architectures http://www.w3.org/wai/apa

Received on Monday, 3 February 2020 17:41:48 UTC