comments on chapter 3

[davidcarlisle]

I was doing some pubrules and other sanity checking on the spec and collected a few comments, thought I'd try a "combo" issue rather than lots of small PR. I added checkbox on main items that can be checked once considered

First a note that you can now use ?open eg https://w3c.github.io/mathml/?open to view the spec with all folded sections unfolded: makes it much easier to review the examples.

• suboptimal polyfills.

  It's not that surprising that not everything covered by polyfills but in the respec editor's draft where images are not shown you get a misleading displayed rendering, with no warning. We could (perhaps?) show the images always or at least in the new ?open mode for reviewing examples. In spec.html you only see the image, not the polyfill so it is not an issue there. I made the screenshots here from a local version showing both image and polyfill

  • linebreaking (no breaks) https://w3c.github.io/mathml/?open#presm_mo_linebreaks

    

  • menclose no sloping line in phasorangle https://w3c.github.io/mathml/index.html?open#examples-11

    

  • menclose non-cursive madruwb https://w3c.github.io/mathml/index.html?open#examples-11

    

  • malign not aligned https://w3c.github.io/mathml/index.html?open#mathml-representation-of-an-alignment-example

    

  • - in mstack becoming hyphen (as it ends up in an html table) http://localhost:8080/w3c/mathml/index.html?open#presm_addsub

    

• Remaining Numeric Character ref <mmultiscripts><mo>&#x0644;</mo> must have missed my global update for some reason.

• Wide examples needing scrollbar https://w3c.github.io/mathml/?open#presm_mo_linebreaks
  (affects several sample presentations in chapter4 as well)

  Originally all examples were indented to fit to width but recent change to use
  <mo>&#x2061;<!--ApplyFunction--></mo>
  made some lines too long. We could re-indent over more, shorter, lines, or drop the comment in those cases, or always, or...

• mfenced wording https://w3c.github.io/mathml/?open#description-13

  While mfenced might be more convenient for authors or authoring software, only the expanded form is supported in [MathML-Core]. A renderer that supports this recommendation is required to render either of these forms in exactly the same way.

  I think it's not clear here if "this recommendation" is full or Core, perhaps

  A renderer that supports this recommendation is required to render either of these forms in exactly the same way. Note that while mfenced might be more convenient for authors or authoring software, only the expanded formusing mrow is supported in [MathML-Core].

• malign https://w3c.github.io/mathml/?open#presm_malign

  wow this is still scary and long, even if the main table/intent description ends up in chapter5, I think we should say less here and describe some hopefully easier way of setting aligned equations and numerically aligned columns,

• Incorrect example of mathvariant https://w3c.github.io/mathml/?open#examples-with-ordinary-operators

  <mo mathvariant='bold'> + </mo> does not make a bold + as + is not in the Unicode bold math alphabet block. I suggest we simply delete this.

  

• [] maction attributes https://w3c.github.io/mathml/?open#attributes-34

  Currently says namespaces should be used in xml and data-.. in HTML. I think we should recommend data- in all cases and just mention namespaces as an altrnatve, and change the example, something like

  The actiontype values are open-ended. If another value is given and it requires additional attributes, they should have names
  begining with begin with "data-". (or in XML, may be in a different namespace). An example is shown below:

  expression

  In the example, non-standard attributes are being used to pass additional information to renderers that support them. The data-color attribute might change the color of the characters in the presentation, while the data-background attribute might change the color of the background behind the characters.

• [] maligmark https://w3c.github.io/mathml/?open#specifying-alignment-points-using-malignmark

  I think the note "Can malignmark elements occur inside of tokens? " is resolved (No)

• [] alignment point.

  _The malignmark element indicates that the alignment point should occur on the left edge (right edge in a RTL context) of the following element. _

  It's not immediately clear to me what "following" means if there is no following sibling element eg
  https://w3c.github.io/mathml/?open#legal-grouping-of-space-like-elements
  where it is the last child of the mrow

<msup>
  <mrow>
    <mi> x </mi>
    <malignmark edge="right"/>
  </mrow>
  <mn> 2 </mn>
</msup>

Is the alignment point the end of the mrow (right edge of x) or the left edge of the superscript 2 (ie is <mn> the "following element"), possibly not much difference here but with mfrac could be quite different

the edge attribute is no longer valid so I think it needs

<mrow>
    <mi> x </mi>
    <malignmark/>
   <mrow/>
  </mrow>

to have a following elment to align on, or special-case maligmark as last child, to align at that point so

<mrow>
    <mi> x </mi>
    <malignmark/>
  </mrow>

[davidcarlisle]

acually factorial seems to be transliterated as madrub rather than madruwb on many sites (can any Arabic speaker confirm?) and wikipedia does show it with two straight lines, so perhaps this is Ok and we should change the image. https://en.wikipedia.org/wiki/Modern_Arabic_mathematical_notation

[davidcarlisle]

also

Arabic factorial (‘madruwb’ is the transliteration of the Arabic مضروب for factorial). This is shown in the third example below.

It is acually (now) the fourth, and as the examples are folded, a bit hard to count. Perhaps reword this, and (if it is not an error) say somehing about using bottom and right border lines rather than a stretched Lam shape.

[NSoiffer]

I'll work on improving some of the renderings. But some limitations:

1. I don't intend to do malign, especially since it might be deprecated. We should switch to the image for that.
2. The menclose polyfill makes heavy use of CSS ::before and that seems to only work in Chrome on MathML at the moment. I'm not sure it is feasible to change the polyfill to use HTML instead of MathML. I'll do some experimentation. Also, Safari and Firefox should implement core at some point, but I doubt this bit will happen anytime soon. Still, I should ask. If the answer is negative to both of those options, we'll need to switch to images :-(

Perhaps YAC (yet another class) is needed -- "no-polyfill" or maybe both "mmlp4" and "mmlp4-no-polyfill"?

I think most of the other issues can be fixed.

[davidcarlisle]

@NSoiffer I added some additional check boxed items in the initial comment here (but checked off some that are now done)

[NSoiffer]

madruwb was discussed in the distant past and the consensus was as you described -- the right angle is ok.