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

Hello Neil, Deyan and all,

On 27 May 2021, at 8:58, Neil Soiffer 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?

- that was an error: thanks, this is fixed

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

That’s the question of the selector language (i.e. how to interpret 
$1, $2, …): this is a problem we currently have with all intents, even 
those explicit in attributes I think.
Yes, it is difficult to solve

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

As said here and there, this is not a problem in the current browser 
landscape: it is trivial for a DOM sub-tree loaded by a browser to 
enrich attributes so that the style element of the `mrow` named by the 
class carries the extra property (that is just “style resolution based 
on class-names”). I’ve tried to explain it a bit deeper in the 
second paragraph of [challenges and 
hopes](https://mathmlmuses.netlify.app/intents-as-css-styles/#challenges-&-hopes) 
(starting from “However, CSS inheritance”).

What’s difficult is to apply “$1 given $2” to the A, pipe, and B 
elements by either using what’s in the style element or what’s in 
the table of default intents. I haven’t resolved this and, as Deyan 
noted, this is not solved by the spec or the table of all default 
intents. Maybe we can leave it to some implementations…

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

As for the feeling that CSS is not for intents. I fully disagree: CSS is 
as much semantics carrying when it says that a given paragraph should be 
displayed big as it is semantics to indicate that a given paragraph 
should be displayed or not using a print-media or using an accessibility 
tool.

I’m afraid, the word semantics should be banned here…

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


On 28 May 2021, at 18:11, Brian Kardell wrote:

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

The list archive has it already.
I would expect that the issues are more with decided directions…


Paul


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