Re: what if... Intents could be fed by CSS?

Hi Paul, all,

Thanks for the quick CSS writeup! It's still a little difficult to
follow, and can benefit from a fully worked out minimal example (with
an explicit MathML tree and CSS rules as per your preferences).

That aside, there are multiple open questions, most pressingly:

1. How can we set up the Math and CSS working groups on a solid common
footing where **any** constructive collaboration can take place?
2. Followed by the secondary complication that MathML has been
possible to use in the past without a strict dependence on CSS, so
introducing one for the AT component will also have wider ecosystem
considerations.

---

If (and that's a big if) those can be productively addressed, the
technical considerations about a "selector language for math
notations" are also non-trivial / interesting. Traditionally this has
required a full-blown grammar (e.g. CFG) to do well, since we have a
lot of contextual interplay - balancing fences, repeated delimiters,
n-ary infix operators, and even recognizing full-blown subtrees with
holes (e.g. Leibniz's notation, falling factorial, Prüfer group, ...).
Present day CSS is very ill-equipped to do these kinds of selections.
I'll also pose this technical challenge to our prior topic of
discussing "subject area" rule sets. For these conceptual "subject
definition sets" one also needs such a selection mechanism for
targeting notational primitives.

Annotating every single MathML node with an intent attribute clearly
feels redundant and verbose, but I think it is a very solid baseline
for what is allowable by the spec. Similarly to how you don't have to
add a CSS "style" attribute to every HTML node, but if you really
wanted to - you could. What you lose in verbosity you gain in AT
runtime simplicity - you don't need any advanced lookup/logic when the
intent is already spelled out. How you get the annotations on the tree
is then a burden shifted to the authoring tools / remediating author.
And some tools are very well-equipped for this kind of thing, have
pre-existing macro/palette interfaces, grammar capabilities, etc.

I don't think the fully verbose variant is the best we can do, but it
definitely seems like the right "flat" target. For a browser analogy,
the inspector tools for CSS have a "Rules" (or "Styles") and
"Computed" tabs, where the "Computed" one contains all fully
flattened/instantiated rules, derived from all CSS rules applicable to
the node inspected. The big question is whether we can achieve this
model with the level of technical work we're prepared to invest here.

Thanks for investigating the CSS angle,
Deyan

P.S. GMail had flagged the original email as "spam" for me, for some
unknowable reason, so there is a chance the original post had a
limited audience.

On Wed, May 5, 2021 at 6:01 AM Paul Libbrecht <paul@hoplahup.net> wrote:
>
> Hello community,
>
> We discussed in the last group call that CSS could possibly play a role to support the intent attribute. I’ve sketched a few thoughts inside this page in the form of a “what if…”:
> https://mathmlmuses.netlify.app/intents-as-css-styles/
>
> … and got surprised in writing that this seems desirable…
>
> Thanks for thoughts.
>
> Paul
>
> On 2 May 2021, at 3:31, Neil Soiffer wrote in Minutes of the call 29 April 2021:
>
> NS: A.T. does  not see CSS information. It just sees the MathML. You may not be able to globally change speech behavior with CSS technology.
>
> NS: Should we say that the A.T. must look at CSS as well as MathML? (this is often not the case or not doable thus far)

Received on Tuesday, 11 May 2021 19:49:24 UTC