Fwd: Personalization TF Vocabulary List requested from TPAC

Response from Marcos regarding Léonie’s comments.
Thanks

Begin forwarded message:

From: Marcos Caceres <marcos@marcosc.com<mailto:marcos@marcosc.com>>
Subject: Re: Personalization TF Vocabulary List requested from TPAC
Date: February 7, 2019 at 1:47:35 PM PST


On 8 Feb 2019, at 04:29, Léonie Watson <lw@tetralogical.com<mailto:lw@tetralogical.com>> wrote:

The TF looked at various existing solutions for meeting the use cases, and the reasons they seemed not to be entirely viable [1].

I’m not sure what part of [1] says it’s not viable to do this with web components using plain old HTML, CSS, and JS? Again, it may be the case, but I’m struggling to find it. Charles, as one of the authors, can you help understand?

I see pros and cons, but no “browsers can’t do X, Y, Z”.

I think it would be very helpful to have some input on this research from browser engineers. Marcos, is that something you could help facilitate?

Respectfully, I am a browser engineer on Mozilla’s DOM Team (i.e., the team that maintains the HTML and all DOM APIs implementation in Gecko) - so my response was as a browser engineer. Apologies if that was not clear.

We could definitely widen the pool to other browsers engineers, but I’m pretty sure they will just come back with the same questions (see also the similar line of questioning from Ryosuke Niwa in the TPAC minutes).

Now, as a browser engineer, I’d suggest going with data-* “dataset” (cheap, easy, widely supported - use as many as you need) and if you go down the custom elements route aui-*.

Definitely don’t do the single “purpose” attribute and try to avoid creating new micro-sytaxes or copying inline CSS. That’s no good - very difficult to parse and maintain.

Avoid the microdata and RDFa stuff. Also avoid, the JS object solution.