W3C home > Mailing lists > Public > www-math@w3.org > August 2016

[MathML4] Whitespace and attributes canonicalization in MathML VS HTML5/CSS

From: Frédéric Wang <fwang@igalia.com>
Date: Mon, 1 Aug 2016 17:31:05 +0200
To: "www-math@w3.org" <www-math@w3.org>
Message-ID: <751e95f0-3be3-d3b9-ec6e-5d3055adb6e2@igalia.com>
Hi Math WG,

Continuing on feedback for a future MathML specification, here is a
(probably non-exhaustive) list of inconsistencies between MathML and
HTML5/CSS regarding whitespace and attributes canonicalization. As a
rule of thumb, it would be better for web engines if MathML can align on
HTML5 so that we can reuse as much code as possible and avoid extra code
to handle MathML special cases. Also people familiar with HTML5 will be
less surprised when handling MathML.

1) Whitespace collapsing/trimming

   Whitespace collapsing is consistent with the default CSS property
"white-space" and people are familiar with it.

   Removing "whitespace at the beginning and end of the content" is less
expected. Gecko has some code to handle this but it would be very
helpful to avoid this additional complexity. WebKit does not handle it
at the moment and it's not clear it's worth doing it... Except in the
MathML spec/test, everybody seems to just write <mo>(</mo> and not <mo>
( </mo>. Can we deprecate this behavior in MathML4? Or maybe you should
work with the HTML5 WG to define such collapsing rules during document
parsing, so that the MathML rendering code no longer need to handle it?

2) In MathML, white spaces are understood as XML spaces (U+0020), tabs
(U+0009), line feeds (U+000A), and carriage returns (U+000D) while HTML5
also includes "form feed" (U+000C).

3) MathML attributes are case-sensitive while HTML5 attributes are
case-insensitive. case-sensitiveness is probably not a problem for users
and it's easier for the parsing. However, WebKit developers writing or
reviewing patches have often considered doing case-insensitive
comparisons as that's consistent with the rest of the code base.

4) MathML boolean attributes take value "true" and "false". In HTML5,
the boolean value is given by the presence/absence of the attribute and
the only allowed value is the name of the attribute. This allows to get
more compact syntax like <mo largeop stretchy> instead of <mo
largeop="true" stretchy="true">. However, Web engines and authoring
tools will continue to support the true/false syntax anyway, so it's
probably not worth adding complexity here...


5) As I said in a previous message, the values "small", "normal", "big"
of mathsize do not exist for CSS font-size. Removing them will simplify
a bit the parsing code.

6) The definition of numbers is also not very accurate in the MathML
recommendation compared to HTML5. One has to check the RelaxNG schemas
and the predefined RelaxNG types to know the exact syntax. Again, it
think it would be best to rely on the HTML5 definitions. For example,
<math><mspace width="1E1em" height="10em" mathbackground="red"/></math>
draws a red square in WebKit but Gecko says "1E1em" is invalid.


Received on Monday, 1 August 2016 15:31:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 1 August 2016 15:31:45 UTC