Fwd: Personalization TF Vocabulary List requested from TPAC

Begin forwarded message:

From: Léonie Watson <lw@tetralogical.com<mailto:lw@tetralogical.com>>
On 07/02/2019 21:47, Marcos Caceres wrote:
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?
A set of web components might solve the use case, but perhaps not easily. I think it's something where help understanding the nuances of web components would be incredibly valuable.

Thinking out loud here...

We'd need to recreate interactive elements to the extent they are
indistinguishable from their native counterparts. So for example, we'd need a custom link that to all intents and purposes was a native link, unless it was being consumed by someone using a tool that modified its appearance based on the presence of a custom attribute. Is that viable?

Another consideration is author burden. Authors would need to use a web component/custom element instead of a native interactive element, which adds overhead. Is this a concern?

Has there been progress on global styling of web components with a shadow DOM? Last I checked (some time ago) @import was the only native way to do it, but it still incurred performance problems.


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

No, I don't either. I did see things in the cons columns that may be possible to solve at the browser level though (such as CSS selectors/media queries support for Microdata). That is a moot point if Microdata isn't viable, but the point remains.


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).

That's a distinct possibility, yes. It's also possible that other people will have different questions and ideas that will help us find the right solution.

Léonie.