Bug 98791 – [MathML] Improve some addChild methods

• Component: MathML
• Status: RESOLVED FIXED

[Dave Barton]

[MathML] Improve some addChild methods

[Dave Barton]

Created attachment 167779 [details]
Patch

[Dave Barton]

David C. & Fred, this small patch does raise a spec/DOM issue. Elements such as mfrac have a fixed number of children, in this case 2 - a numerator and denominator. After the element has been built, is it legal to dynamically alter it through more than just replaceChild? If one deletes the numerator, should the single remaining child change from the denominator to the numerator? Can one temporarily append a 3rd & 4th child, and then delete the 1st & 2nd children, leaving 2 children at the end? I think it's ok to ignore this for now (just don't crash), but should precise behavior be required, or intentionally left unspecified (erroneous)?

[Frédéric Wang (:fredw)]

I think Gecko will accept this dynamic operation and typically do the same as with successive static versions (I haven't checked, though):

- When the mfrac has two children it is rendered normally
- Once it gets 3 or 4 children, it is rendered as an "invalid markup" box in lieu of the mfrac element (I think the spec suggests somewhere how to handle invalid markup)
- If you remove the two first children it will render the mfrac normally again.

[David Carlisle]

(In reply to comment #3)
> I think Gecko will accept this dynamic operation and typically do the same as with successive static versions (I haven't checked, though):
> 
> - When the mfrac has two children it is rendered normally
> - Once it gets 3 or 4 children, it is rendered as an "invalid markup" box in lieu of the mfrac element (I think the spec suggests somewhere how to handle invalid markup)
> - If you remove the two first children it will render the mfrac normally again.

I agree that inconsistent DOM should be allowed to be generated, the mathml spec (in XML tradition) doesn't really say anything about bad trees they are just bad; but it's probably best to follow the guidelines of html spec (for html and xml DOM) html says (of parsing rather than dynamically modified trees) (4.8.15 MathML)

User agents must act as if any MathML element whose contents does not match the element's content model was replaced, for the purposes of MathML layout and rendering, by an merror element in the MathML namespace containing some appropriate error message.

[Eric Seidel (no email)]

(In reply to comment #4)
> (In reply to comment #3)
> User agents must act as if any MathML element whose contents does not match the element's content model was replaced, for the purposes of MathML layout and rendering, by an merror element in the MathML namespace containing some appropriate error message.

That's a very XMLy way of doing things.  XML has lost the war for the minds of the web developers of the world.

Since MathML is now being adopted as part of HTML5, I would recommend we take a path of "do something reasonable" and "display as much as possible" instead of the XML "fail fast" model.

Obviously that doesn't have to be decided all in this bug. :)  I might either just ignore the mfrac, or ignore the children > 2.  I suspect ignoring the mfrac (treating it just like an mrow or whatever the default container would be) is probably more what authors intended.  (But I can't say I've authored much mathml.)

As you've done, its just most important that we test whatever behavior we decide on.

[Ian 'Hixie' Hickson]

I thought the MathML rendering model was that you just replaced erroreous subtrees with "an error" (much like <merror>) when you hit something bad. Isn't that what Gecko does?

[David Carlisle]

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > User agents must act as if any MathML element whose contents does not match the element's content model was replaced, for the purposes of MathML layout and rendering, by an merror element in the MathML namespace containing some appropriate error message.
> 
> That's a very XMLy way of doing things.  XML has lost the war for the minds of the web developers of the world.
> 
> Since MathML is now being adopted as part of HTML5, I would recommend we take a path of "do something reasonable" and "display as much as possible" instead of the XML "fail fast" model.
> 

Perhaps you misread it or me quoting it out of context mislead you. It was intended to be the HTML5 way of doing things (I was quoting the HTML(5) spec).  The XML-flavoured mathml spec doesn't say what to do for bad input just says its not mathml.  This isn't really  a "fail" in the sense of xml the rest of the expression still renders but it just means that a fraction with three children should be rendered as something like merror; that is typically a text box with red text indicating that a fraction with three children can't be rendered normally,it doesn't prevent the rest of the expression from displaying.

[Dave Barton]

Wow. I guess I was thinking like Eric, since that's what falls out of the current implementation. For now I think you would get something like a fraction displayed as a vertical column, with a horizontal line above its second child. If there are e.g. 3 children, then you'd just get a 2nd denominator below the first one. I guess I can see an argument that an error message would be better, especially if that's what the spec authors say :), but I don't think it's the most important MathML fix to implement next.

I was actually asking more about if someone takes a legal fraction, then does removeChild on its first child, and then later adds another child, say by appending it. Can the denominator silently move to become the numerator this way? Can superscripts become subscripts this way? Maybe I'm hypnotized by the implementation, or was just being lazy, but this current patch doesn't try to do all that. Basically it supports javascript replaceChild, but not arbitrary addChild/removeChild, with the excuse that a valid mfrac should stay at exactly 2 children. That should be relaxed in the future though?

Finally, I was hoping to land this patch before turning on the fuzzers. I think the google security guys are busy this week - are we waiting on them to review this? Is it better to just enable MathML in Chrome before landing this? Or does this patch need to be changed now for some reason, before it can be reviewed?

[Eric Seidel (no email)]

jchaffraix is probably your best reviewer here, but I can if he's too busy.

[Eric Seidel (no email)]

Comment on attachment 167779 [details]
Patch

Julien is on vacation, but LGTM.  He can comment when he comes back.

[WebKit Review Bot]

Comment on attachment 167779 [details]
Patch

Clearing flags on attachment: 167779

Committed r132735: <http://trac.webkit.org/changeset/132735>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Dave Barton]

*** Bug 100463 has been marked as a duplicate of this bug. ***