Ideas for future improvements [was: mtable borders etc]

Just to repeat what I've said several times in the past: I'm in favor of
making the MathML spec more compatible with existing CSS and HTML
technologies and in my opinion that should be the main goal of an
hypothetic MathML 4. That also seems the only chance to get MathML
natively implemented in browsers one day (assuming this is what the Math
WG people want).

Rationale:

1) This makes native implementations easier and cleaner, since we are
reusing existing code (in Gecko, many attributes used to be implemented
by exposing _moz* attributes in the DOM tree, which obviously violates
the spec and moreover leads to bugs when doing dynamic update via
Javascript. Even after the refactoring, the MathML table attributes may
conflict with CSS properties and we have to do a special case to make
the latter override the former...)

2) This makes it possible to get code accepted by browser companies (see
Robert's commment:
https://bugzilla.mozilla.org/show_bug.cgi?id=330964#c46 
https://bugzilla.mozilla.org/show_bug.cgi?id=330964#c46). In general, my
feeling is that there are conflicts between standardization groups and
Web browser developers/implementers (cf the stories W3C vs WhatWG,
XHTML2 vs HTML5, SVG vs Canvas, EPUB3 vs "EPUB NG", XML Schema vs
RelaxNG...). My understanding is that the efforts to make MathML in
HTML5 was intended to move MathML from an isolated XML language to a
math rendering well-integrated into the Web platform, so I hope efforts
will continue in that direction.

3) This allows Web developers to reuse technology they are familiar
with, instead of reinventing the wheel and always asking for new MathML
attributes. It seems to me that Daniel and Peter's border requests could
easily be done using CSS (even if the spacing is not necessarily obvious).

Some ideas off the top of my head for future MathML improvements:

* Work with the CSS WG to see how tabular attributes can be made
compatible with CSS properties (adding new properties if necessary).

* <mlabeledtr> should be make compatible with HTML table (the MathML
spec says that label is not to be treated as a table cell whereas the
elements are nested in the DOM tree, moreover the side attribute changes
the rendering order). In my opinion, this element should just be removed
as equation labeling could be done in HTML (that's what LaTeXML or
Wikipedia do for example). AFAIK, the only serious request Mozilla had
for that element came from MathJax because internally MathJax only does
LaTeX to MathML conversion and so can not put the label outside (note
that MathJax has similar issues with e.g. mixing SVG/MathML for LaTeX
diagrams so that's not specific to mlabeledtr).

* <mstyle> should be make compatible with CSS inheritance and irrelevant
attributes should be deprecated. Perhaps CSS properties should be
created for displaystyle and mathvariant too. cf previous remarks I made
in the past. This is already done in Gecko and there is no plan to
implement all the mstyle attributes in WebKit.

* <mfenced> should be deprecated as it duplicates its equivalent
<mrow>+<mo> expansion and thus adds more code to implementation. For
native implementation like WebKit/Gecko this typically means creating
many anonymous frames (for separators and open/close). This is a mess to
make the mfenced rendering 100% equivalent to the <mrow>+<mo> expansion,
to handle edge cases when parsing the attributes or to manage memory
allocation/desallocation after dynamic changes. It seems that the only
reason for this element is that it is a convenient shorthand for
rudimentary implementations that don't know about the operator
dictionary or have bad mo support in general (in some a11y tools or in
Opera Presto).

* Clarify how MathML linebreaking behave with respect to the existing
CSS rules (we could provide more feedback when progress is made on
https://bugzilla.mozilla.org/show_bug.cgi?id=534962). For example with
normal HTML text, "$x_1 + x_2 + x_3 + ... + x_{n-1} + x_n$" can split
into two or more lines while "$k$-lipschitzian" should never split
before the dash. I expect the same should happen for inline equations.
AFAIK, there are two existing implementations (MathJax and MathPlayer)
and they were not compatible with the basic case of automatic line
breaking of formulas inside a table cell (recent versions of IE even
crashes). Even worse, last time I checked (one year ago) MathJax wraps
all its equations inside an inline-block span which is clearly not
compatible with CSS rules.

Additionally, one of the recurring reproach was that MathML
intentionally does not specify precisely the mathematical rendering and
so conformant implementations may still look "ugly" or may have
inconsistent rendering. I believe a non-normative appendice should
provide some suggestions regarding how to pick the math font using CSS
(font-family / Web fonts) and apply LaTeX's appendix G rules + the Open
Type MATH tables (currently being standardized in
http://mpeg.chiariglione.org/standards/mpeg-4/open-font-format).

Le 11/11/2014 01:55, David Carlisle a écrit :
> extensions are always possible to propose...
>
> In this case, personally, I'm rather lukewarm, latex allows || mainly
> because tabular and array are the same thing, more or less. I'm not
> sure there are that many use case for || in math?
>
> However if a double rule is needed you could model the example in the
> bug report
>
>   |c|c||c|
>
> as
>
>  |c|c|@{\hspace{\arrayrulesep}}c@{}|c|
>
> with an empty cell (ie in tex &&) at the relevant cell boundary.
>
> If we were to extend this in an html+mathml context probably we should
> be looking to see some way of specifying how css table cell border
> ptoperties are supposed to work here. CSS styling does basically work
> already in firefox as far as I can see, If I take this MDN example
> and adapt it to include mtable
>
> https://developer.mozilla.org/en-US/docs/Web/CSS/border-style
>
> It produces the attached
>
>
> David
> (wearing TeX hacker's hat not Math WG one)
>
>


-- 
Frédéric Wang
maths-informatique-jeux.com/blog/frederic