-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Describe how to layout DOM elements violating HTML5 model #57
Comments
This was discussed at the CG meeting today. Whatever the HTML parser does, it does. Likewise, JS might do things also to put HTML into MathML in places where it isn't allowed (i.e, putting it outside of leaf elements). The meeting consensus is that MathML should treats these as unknown elements (#15). Currently, the plan is to layout unknown elements as an mrow/grouping container. This is consistent with the HTML philosophy of showing content even when the tag is not known, but differs from WebKit's current implementation. Before resolving this, the CG wants feedback from other implementers as to whether this is something they think is a good idea or not (both for this issue and for unknown elements in general). If not, what is preferred? |
This proposal certainly works for us - it's what we're doing already. Any orphaned text is wrapped in an |
At the meeting today, Brian felt there were enough positive signs to consider this resolved. It can be re-opened if Webkit/Gecko implementers decide this is a problem. |
Looks like all that needs for this to be closed is some tests. @fred-wang: were any tests written for this so it can be closed? |
Let's keep it open, as I'm not sure if any test was written. |
I don't understand what @bkardell meant here. I believe most (all?) problems I mentioned in my initial report are not resolved i.e. we have inconsistencies between browsers and the HTML spec (and MathML Core is silent on this). |
text nodes need specification similar to unknown elements |
cc @bfgeek
This was discussed during the previous meeting.
The HTML parser has some restrictions on the DOM tree but one can always use JS API to insert elements where they want: https://mathml-refresh.github.io/mathml-core/#html-and-svg
Some cases:
non-MathML elements used inside MathML elements that only accept MathML children (e.g.
<math><p>x</p></math>
. What WebKit and Chromium do is not to create any layout box i.e. don't render anything. Firefox renders something. Note that HTML has very precise definition (e.g. only allowing phrasing element or annotation element with special encoding values) that we probably want to simplify as that's adding complexity Synchronization with WHATWG HTML5 spec mathml#145 -- I think we can either not render anything (like chromium and webkit do) or define a MathML box for such non-MathML element from its CSS margin box (which as @rwlbuis pointed out is probably more consistent with the idea of trying to render everything).text nodes inside MathML elements that don't accept text (e.g.
<math>x</math>
). Again, WebKit and Chromium don't create any layout box i.e. don't render anything contrary to Firefox. The HTML and MathML3 spec say they should be rendered as if they were wrapped in a<mtext>
, but not sure that's worth it Synchronization with WHATWG HTML5 spec mathml#145 -- And we can again probably define a MathML box for such non-MathML element from its CSS margin box.A MathML element that is an invalid childr of another MathML element e.g.
<math><mfrac><annotation>x</annotation><mn><mtext>1</mtext></mn></math>
or<mrow><math></mrow>
. The HTML and MathML3 spec say they should be rendered as an merror with appropriate message. This is a bit similar to Interoperable handling of invalid markup #136 where we instead decided to render something. I think in general since the box layout is recursive we can just render things as already specified by the spec. Probably some care has to be taken for the edge case of<math>
and token elements though.MathML elements, other than the
<math>
root, inside non-MathML elements. e.g.<p><mn>2</mn></p>
. I think we can allow these cases too as we already define a CSS box for the MathML ones.The text was updated successfully, but these errors were encountered: