Skip to content
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

Open
fred-wang opened this issue Jan 28, 2020 · 7 comments
Open

Describe how to layout DOM elements violating HTML5 model #57

fred-wang opened this issue Jan 28, 2020 · 7 comments

Comments

@fred-wang
Copy link
Contributor

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.

@NSoiffer
Copy link
Contributor

cc: @rniwa, @bfgeek, @emilio

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?

@faceless2
Copy link

This proposal certainly works for us - it's what we're doing already. Any orphaned text is wrapped in an <mtext>, and any unknown elements are treated as <mrow>.

@NSoiffer
Copy link
Contributor

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.

@NSoiffer
Copy link
Contributor

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?

@NSoiffer NSoiffer transferred this issue from w3c/mathml Jun 29, 2021
@fred-wang
Copy link
Contributor Author

Let's keep it open, as I'm not sure if any test was written.

@fred-wang
Copy link
Contributor Author

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.

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).

@davidcarlisle
Copy link
Collaborator

text nodes need specification similar to unknown elements

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants