Low level imperative API

samuelgoto commented 6 years ago

I wrote this over email, editing and moving it into a github issue to allow easy tracking.

Regarding the comparison of serialization strategies for the metadata, I think it is worth exploring (i'm genuinely curious, not sure how it compares) and adding to the list a lower level API per the Extensible Web Manifesto and leave the ergonomics to userland code. Here are a couple of ideas worth comparing and contrasting:

(1) JSON-LD (2) A JS API (viz the AOM)

In both (1) and (2) the approach here is that you (a) detach the semantics from the DOM/presentation and (b) leave ergonomics (or the color of the bikeshed) to be explored/innovated from userland code with polyfills. So, for example, you'd expect user agents to understand these low-level APIs (1) or (2) or another alternative and you'd allow/foster/encourage JS libraries to fill the gap of ergonomics. In time, if you find a specific userland framework has won and everybody converged to it, you bake that into the user agent.

I think that one of the reasons why you may be struggling to find a silver bullet in your current analysis is because I believe that there is a fundamental difference between the DOM and the data structure you want to build. Specifically, when it gets to position: absolute everything falls apart, and, in my experience, a lot of production-level code (e.g. things that you'd find on gmail.com, yelp.com, hertz.com, opentable.com, rather than on demos/prototypes) is written in a manner where the DOM doesn't represent anymore the semantic data structure.

In Google Search, I have found that the semantic web has taken off when JSON-LD was introduced: de-coupling the semantic information from the DOM substantially increased its expressivity, earlier tied to microdata/rdfa (at the cost of duplication of data and misrepresentation - which I think are worth paying in exchange to expressivity).

Here is an example of what that could look like (just take this as an example to illustrate the concept rather than a specific proposal):

<html>

  <script src="https://jquery.com/a11y.js">

  <button intent="undo"/>

</html>

Which would be equivalent, from a user agent perspective, if the user had written something along the lines of:

<html>

  <button id="1"/>

  <script>
    // TODO: actual JS api largely TBD.
    document.a11y.actions.push({
      label: "undo",
      id: "1"
    })
  </script>
</html>

The latter is obviously unergonomic, so we wouldn't encourage people to use it directly, but the cool part about it is that it enables/delegates the bike-shedding to userland, giving somebody else the ability to come up with a different serialization, like

<html>

  <script src="https://anotherpolyfill.com/a11y.js">

  <button itemscope itemtype="http://schema.org/UndoAction"/>

</html>

Unclear to me if this is any better than what you currently have, but it seems like a fundamentally different approach worth comparing / contrasting :)

LJWatson commented 6 years ago

@SamuelGoto wrote: <(2) A JS API (viz the AOM)<

What is the use case for using the AOM and/or accessibility APIs?

samuelgoto commented 6 years ago

What is the use case for using the AOM and/or accessibility APIs?

It is a different layering approach, viz https://extensiblewebmanifesto.org/. The strategy here is to give access to lower level APIs (i.e. specifically a programatic JS API) and enable ergonomics (e.g. bindings to HTML) to be done / innovated / invented in userland.

ghost commented 6 years ago

Thank you, Sam. Added to Comparison page.

w3c / adapt

Low level imperative API #73