W3C home > Mailing lists > Public > public-personalization-tf@w3.org > September 2018

How do we put the vocabulary in content

From: John Foliot <john.foliot@deque.com>
Date: Sat, 29 Sep 2018 11:24:43 -0500
Message-ID: <CAKdCpxxeRFkA3_ogRDbKatdPD6gp+4D-J3Pb6WLbO9-tXfP5XQ@mail.gmail.com>
To: public-personalization-tf <public-personalization-tf@w3.org>
Cc: Harris Schneiderman <Harris.Schneiderman@deque.com>
Greetings colleagues,

I have been discussing this problem-statement with a number of engineers
external to our group, and I have actually received some interesting
feedback, and (for what it's worth) some additional suggestions with regard
to notation.

My bigger take-away however is that more discussion and consultation from
external partners is required, and that perhaps we are rushing a bit too
quickly.

As a point of process, I am requesting that the chairs add to Monday's
agenda a discussion over the feasibility of getting a publishing extension
(60 - 90 days?). I fully appreciate that we have deadlines we need to meet,
but both personally, professionally, and formally on behalf of Deque
Systems, I think it is more important to get it right than to get
*something/anything* done against an artificial, self-imposed deadline.

*******************

Regarding notation pattern(s), as mentioned I have been discussing this
with engineers and implementers (and will continue to do so), however a few
additional notation patterns have been proposed:

   1. *Class-style notation:* again, using CSS style notation, but instead,
   using a "Cascading Attribute Sheet" (see this old blog post from Tab Atkins
   of Google, and a key member of the CSS WG:
   https://www.xanthir.com/blog/b4K_0). *NOTE: this method/idea does not
   exist at this time*

   The idea is that the declarations are made external to the actual
   content as class values, and the 'assembly' happens at the user-agent
   level. This is a common pattern already, for both CSS, but also for
   JavaScript libraries such as jQuery, where all of the functionality is
   achieved via class attributes.

   .foobar {
     field: "password";
     moreinfo: url('PasswordFAQ.html');
     symbol: url('images/helpicon.png');
     importance: critical;
   }


   2. *Javascript object* (very similar to the above approach but just in
   JavaScript instead) NOTE: This could be in JSON format as well (it'd look
   almost identical to the below code sample)

   {
     '.foobar': {
       field: "password";
       moreinfo: url('PasswordFAQ.html');
       symbol: url('images/helpicon.png');
       importance: critical;
     }
   }


   3. *dataset (data-* or data-aui-* attributes) *I was somewhat surprised
   that a) we never thought of this, and b) virtually all of the engineers
   I've spoken with to date have gravitated towards *this* solution.

   Extremely similar to the multiple attributes proposal, the difference
   being the addition of the data-* prefix. The feedback I have is that this
   notation will integrate seamlessly with frameworks such as React and
   Angular, and will be familiar to developers using these types of frameworks
   already.

   <div
     data-aui-field="password"
     data-aui-moreinfo="PasswordFAQ.html"
     data-aui-symbol="images/helpicon.png"
     data-aui-importance="critical"/>


I had one of Deque's engineers (thank-you Harris) look at and write up some
additional thoughts, including Pros and Cons for the two current
"front-runners", along with these 3 new suggestions.

That write-up can be found here:
https://gist.github.com/schne324/9eda7dbc99954e2d4e44a86515a87f97
<https://gist.github.com/schne324/9eda7dbc99954e2d4e44a86515a87f97>

JF
-- 
*John Foliot* | Principal Accessibility Strategist
Deque Systems - Accessibility for Good
deque.com
Received on Saturday, 29 September 2018 16:25:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:56 UTC