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

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


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:

*John Foliot* | Principal Accessibility Strategist
Deque Systems - Accessibility for Good
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