Last Comment Bug 353926 - MathML in HTML5
: MathML in HTML5
Status: RESOLVED FIXED
[fixed by the HTML5 parser]
:
Product: Core
Classification: Components
Component: MathML (show other bugs)
: Trunk
: x86 All
: -- normal with 2 votes (vote)
: mozilla1.9.3a5
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: html5-parsing
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-23 00:59 PDT by rbs
Modified: 2010-05-14 11:52 PDT (History)
23 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (1.81 KB, text/html)
2006-09-23 01:01 PDT, rbs
no flags Details
patch - v1 (24.14 KB, patch)
2006-09-23 01:04 PDT, rbs
no flags Details | Diff | Splinter Review
screenshot - MathML-in-HTML - rendering of the testcase (18.42 KB, image/png)
2006-09-23 01:07 PDT, rbs
no flags Details
patch - v1b (same as v1, but sync'ed with bug 355451) (24.74 KB, patch)
2006-10-15 18:39 PDT, rbs
no flags Details | Diff | Splinter Review

Description rbs 2006-09-23 00:59:28 PDT
At the Firefox engineering meeting in Mountain Views (last December 2005), I pleaded that we enable MathML in HTML5 to advance the cause of MathML, which is so far locked in a XHTML/XML world that does not seem to going anywhere in terms of display content as opposed to data (witness the WHATWG effort). Those to whom I spoke included dbaron, hixie and sicking, and they welcomed the suggestion, asking for a broader discussion. Hixie raised the caveat that MathML elements should still remain in the MathML namespace. He e-mailed me a while ago about a discussion on this matter in the WHATWG mailing list, which can be seen here
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-June/thread.html.

That discussion is however too broad and involves tangential issues such as inventing another syntax, etc. My original take was simply to enable MathML+HTML, in the same vein as we have MathML+XHTML.

I have finally been able to code this up (with Hixie's caveat about keeping MathML elemens in the MathML namespace). I will attach the patch I have so far.
Comment 1 rbs 2006-09-23 01:01:07 PDT
Created attachment 239769 [details]
testcase
Comment 2 rbs 2006-09-23 01:04:50 PDT
Created attachment 239770 [details] [diff] [review]
patch - v1

Summary: How does MathML-in-HTML5 work? 

We support MathML-in-HTML5 when these two conditions are met:

 1. The DOCTYPE of the document says so. If yes, we load
    MathML entities (TODO) and flag mMayHaveMathML in the sink.

 2. And either a) OR b) is met:

    a) <html> has the MathML namespace as the value of an attribute with a
       prefix, e.g., <html xmlns:m="http://www.w3.org/1998/Math/MathML">.

       In this case, we cache the prefix "m" in mMathMLNameSpacePrefix,
       and we intercept all <m:tag> in the document and create
       MathML content nodes for them.

    b) MathML fragments are in the document as
       <math xmlns="http://www.w3.org/1998/Math/MathML">
         ...
       </math>

       In this case, we intercept all non-HTML elements inside the <math> tag 
       and create MathML content nodes for them.

Issues:
 1. Tag soup: we understand that we are exposing ourseleves to this.

 2. a) What about CSS matching rules? From the Style System point of view,
       the document is still HTML, but <m:math> is the MathML namespace. We
       might have to special case MathML-in-HTML5 in the Style System as well.

    b) The second option raises an issue with HTML-in-MathML, e.g.,
       <math xmlns="http://www.w3.org/1998/Math/MathML">
         <b>bold</b>
       </math>
       We don't intercept the <b> in this case. Hence, even though it is
       HTML-in-MathML without an explicit XHTML namespace for <b>, the HTML sink 
       will give <b> a HTML content node. This is not really XHTML friendly.
       On the other hand, we don't want to be an XML parser either... These
       are conflicting objectives. We need to decide what to do. We may agree
       to only support tags with prefixes as in a), or also keep b) knowing
       that it has this XHTML unfriendly behavior.
Comment 3 rbs 2006-09-23 01:07:05 PDT
Created attachment 239771 [details]
screenshot -  MathML-in-HTML - rendering of the testcase
Comment 4 Hixie (not reading bugmail) 2006-09-25 11:06:42 PDT
As noted on the newsgroups, I don't think we should do this by having namespace syntax. I think we should just automatically assume that if the HTML parser parses any of the following elements:

   math, mrow, mfrac, msqrt, mroot, mstyle, merror, mpadded, 
   mphantom, mfenced, menclose, msub, msup, msubsup, munder, 
   mover, munderover, mmultiscripts, mtable, mlabeledtr, mtr, 
   mtd, maction

...that they get put into the DOM with the MathML namespace.

(Note that this would be done while not changing the parser -- these elements don't get any special processing other than changing the namespace. i.e. they are parsed just like <xyzzy>.)
Comment 5 rbs 2006-10-15 18:39:49 PDT
Created attachment 242359 [details] [diff] [review]
patch - v1b (same as v1, but sync'ed with bug 355451)

I had to update to pick the changes in bug 355451 that conflicted with the earlier patch. Since the prefix approach (included in the current patch) is not going to be retained, I am just dropping this update here for the record.
Comment 6 :Ms2ger (⌚ UTC+1/+2) 2009-07-09 11:54:44 PDT
I believe this is fixed by bug 487949.

Note You need to log in before you can comment on or make changes to this bug.