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

Perhaps it would be a good idea to file an issue in the repo on
https://github.com/w3c/mathml/issues so that we don't lose visibility into
history here?

On Thu, May 27, 2021 at 2:59 AM Neil Soiffer <soiffer@alum.mit.edu> wrote:

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

-- 
Brian Kardell :: @briankardell :: bkardell.com