Re: Reminder: MathML intent meeting 5 Nov, 2020

Hi Moritz, all,

Point 2: Thanks for reporting these two issues! Both were my
implementation bugs, just deployed two hotfixes for them. Not related
to the spec thankfully - a regex mistake and a string interpolation
typo.

At some point I should turn each of the examples in this tiny showcase
into unit tests, to avoid unnecessary turbulence with bad markup.
Maybe that point is this week? :-)

Point 1: As to the alignment topic, the four examples currently there
can be found if you search for "alignments" in the Examples input.
Ideally those remain as good as last week. In positive news, I made
the piecewise readout a little better yesterday.

What we have indeed had consensus on last week is that the top-level
serialization of the content tree can look intimidating+ugly, and I
believe discussing how to simplify is one of the topics for today. I
suspect that we can get the attributes a lot smaller with Sam's
direction of work with implied default values, though we have to do
the work to find out.

By the way, all four examples in the showcase can now also be
converted with the "pMML+cMML" math format mode to also compare to
parallel Pres+Content MathML markup. And, as you suggest, some in the
group find the twice as long vertical axis scarier than the one extra
line that fully spans the horizontal axis :-)

Greetings,
Deyan


On Thu, Nov 5, 2020 at 2:37 AM Physikerwelt <wiki@physikerwelt.de> wrote:
>
> Hi Neil,
>
> I have a few comments regarding 2)
>
> According to the HTML standard
>
> https://www.w3.org/TR/html52/dom.html#element-definitions-attributes
>
> attributes can contain an arbitrary string value.
> While some common attributes have more complex values like the event-attributes that specify a callback function or the style attribute that specifies CSS values the proposed new attributes seem even more complex to me.
>
> This makes MathML the black sheep in the HTML family once again. Does the majority of this group really think it is a good idea to encode tree structures as part of XML / HTML documents that are inherently trees?
> If the answer is yes, which I somehow assume, I still don't understand why we can't use an existing language such as JS or (La)TeX or ... to represent this tree structure.
> Having to define, encode, implement, and maitain a new MathML costom logic seems to require a very good reason.
>
> Independent of that I have some questions about the attached example.
>
> Why are do m and n both have arg=2 in msubsup(C, m, n) whereas x,y have arg 1,2 in binomial(x, y)?
>
> In the second example
>
> annotation: binomial(binomial( a,, b), binomial(x, y))
>
> tex: \binom{\binom{a}{b}}{\binom{x}{y}}
>
> why are there two commata within the first binomial annotation?
>
> See you soon
> Moritz
>
> On Wed, Nov 4, 2020 at 9:57 PM Neil Soiffer <soiffer@alum.mit.edu> wrote:
>>
>> Onto November... We meet again on Thursday, 5 November at 10am Pacific, 1pm Eastern, 7pm Central European Time. Summertime is done for everyone.
>>
>> The zoom meeting link is the same one we have used at the last few intent meetings. Due to zoombombing, I can't send it out to the public mailing list. If you would like to join and don't have the link, please send me email at least 10 minutes before the meeting.
>>
>>
>> Agenda:
>> 1. Move to WG -- making sure there is consensus to do this. Last chance to make comments on charter.
>>
>> 2. Continue discussion based on Deyans (live demo) ideas: https://dginev.github.io/tiny-mathml-a11y-demo/
>>
>>
>> Sam can't make the meeting this week. Sam: I'm sure the whole group wishes best of luck on surgery!
>>

Received on Thursday, 5 November 2020 11:10:26 UTC