- From: Frédéric WANG <fred.wang@free.fr>
- Date: Sat, 29 Nov 2014 13:18:17 +0100
- To: www-math@w3.org
- Message-ID: <5479B989.4080903@free.fr>
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
Received on Saturday, 29 November 2014 12:18:43 UTC