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

I agree with much of what Deyan mentions. I do see a copy/paste bug:

.set {
    mathintent-mo-mid: "$1 given $2";
  }

You mean "such that" in this case, right?

What I don't see is what the connection between the $n and the MathML
referenced. Using the conditional probability example because it is shorter:

  <mrow class="conditional-prob">
    <mo>P</mo>
    <mo>(</mo>
    <mi>A</mi>
    <mo>|</mo>
    <mi>B</mi>
    <mo>)</mo>
  </mrow>

The CSS match is on the mrow. I would normally think that $1 refers to the
first child, but that's not right here (FYI: the 'P' should be an <mi> and
there should be an <mo> with &#x2061 [function apply] in it that follows
the 'P'). I think maybe you mean it refers to the first <mi>, but the
argument could easily be a number or a complicated expression, so that
can't be it. In the intent proposal, the arguments get marked with "arg"
attrs. Perhaps the RHS of the css rule needs to include CSS selectors?

Whereas using attrs can be repetitive, it does keep the intent in one
place. If one were using a WYSIWYG editor that allowed the user to specify
what they mean, how would copy/paste out of that editor convey both the
MathML (with a class attr) and the CSS? It seems to me that a CSS-like
approach only works if the entire document, including the math, is
generated from the source. Definitely a possibility, but also IMHO a
limitation.

My gut feel is that using class/CSS is wrong in principle. CSS is meant to
style something, not add semantics. Using it to change the way you speak it
such as "J sub 1" vs "J 1" seems appropriate, but using CSS to change the
meaning of the 'J' to be a Bessel function seems wrong. Although HTML is
not perfect about it, the point is that the meaning is conveyed by the
markup; class doesn't count in that sense (ARIA could have used it, but
instead felt a separate @role was appropriate).

I suspect others share your enthusiasm for CSS, so this is a very good
topic for a call. Perhaps some more email discussion will help further
refine your ideas before discussing them on a call...

    Neil

On Mon, May 24, 2021 at 11:06 AM Deyan Ginev <deyan.ginev@gmail.com> wrote:

> Hi Paul, all,
>
> Now that Paul has updated his examples, I took the time to see what
> his level 3 list complaint was, and added the notation. Emailing to
> all as an encouragement to add future examples to the list directly.
>
> So. The list already had "free-product" added, and my encyclopedia
> index didn't contain the amalgamated variant of it, likely since
> wikipedia doesn't have a standalone page for that. I did a quick
> search + cursory reading and found that there are three rough synonyms
> for the same notation - "amalgamated-product",
> "amalgamated-free-product" and "free-product-with-amalgamation".
>
> So I added in an entry with a name and two aliases, the source links
> from my search, and the nice subscripted infix * operator. I also
> added the speech hint I found in a phd thesis (though maybe there are
> better ones?) of:  "amalgamated product of $1 and $3 with $2
> amalgamated".
>
> And now, 5 minutes later, it's in the list and one can imagine it
> spoken by an AT tool. Relatively painless I would hope.
>
> I'll keep this email short, so no CSS comments for now, just this level 3
> note.
>
> Greetings,
> Deyan
>
> On Tue, May 11, 2021 at 3:47 PM Deyan Ginev <deyan.ginev@gmail.com> wrote:
> >
> > 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)
>
>