[Webkit-unassigned] [Bug 78617] MathML internals - embellished operators, getBase() accessor functions
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Feb 15 10:27:55 PST 2012
https://bugs.webkit.org/show_bug.cgi?id=78617
--- Comment #8 from Dave Barton <dbarton at mathscribe.com> 2012-02-15 10:27:55 PST ---
I'll remove the "const" and "get", and add comments to the code summarizing or referring to our discussions here.
"base" here omits a subscript and/or superscript, or an underscript and/or overscript. In legal MathML, the result will still be MathML, hence a RenderMathMLBlock or RenderInline, both of which derive from RenderBoxModelObject. We do need to be able to work with the base, e.g. compute its offsetHeight.
I'm not an SVG expert, but you raise a basic design question for MathML in WebKit. Currently RenderMathMLBlock, which is used by most MathML elements, derives from RenderBlock. We get a lot of horizontal and vertical formatting for free that way, hit-testing, probably a lot of other things(?). Also MathML elements are probably most like inline-block elements, which are implemented by RenderBlock. However, one might argue it'd be cleaner to not derive from RenderBlock, and reimplement layout() and other functionality for some base RenderMathML class. This effort is probably beyond the time I have available though.
Even more fundamental is the question of whether MathML objects obey the CSS box model, or whether they should. The MathML spec suggests that one ought to be able to style MathML with CSS in environments that support CSS, presumably including using the box model.
For now, I am indeed using a simplified definition of "embellished operator". I think it's best to simplify the current RenderMathML* classes before we add things to them. Also, I don't agree with larger definition, FWIW. Is there a reference explaining more fully the rationale for always treating an <mrow> of one argument, and without attributes, as a special case? I've written a MathML generator, jqMath, and it was actually simpler to not do this. Also checking specially for space-like elements adds complications and an unnecessary inconsistency, in my opinion. This requirement pre-dates CSS. Just as many presentational attributes in HTML were deprecated and replaced by CSS, I think many in MathML should be also, and the definition of "embellished operator" should be simplified as well. But having said all that, if the spec isn't changed, then I agree that WebKit MathML should eventually implement a mechanism similar to Mozilla's.
Thanks for the pointers to the tests. We definitely should include these tests, and/or tests from the w3c mathml committee, at some point.
This careful review from you experts is invaluable.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list