[Webkit-unassigned] [Bug 79274] Fix <msubsup> formatting

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=79274





--- Comment #14 from Dave Barton <dbarton at mathscribe.com>  2012-02-23 15:16:30 PST ---
Julien/Eric/etc. re anonymous blocks in this bug report: To start from the beginning, MathML renderers need to position various DOM element children horizontally & vertically - subscripts, superscripts, underscripts, overscripts, numerators, denominators, etc. Often, however, DOM children just go in a simple row or matrix (mtable). So the closest CSS concept might be that MathML elements are like inline-block elements, including the shrink-to-fit sizing. Somewhat like absolute positioning, a smart renderer's layout() function could compute x and y coordinates for all its children, and then paint() and other methods (computePreferredLogicalWidths(), hit-testing? selections? other stuff in e.g. RenderReplaced.h/cpp??) would access these computed coordinates. This might all be done in a base class, and specific RenderMathML* classes could derive from it, each with their own virtual layout() method. However, I am new to WebKit and don't know how many other methods this would be, 
 so following Alex Milowski's original WebKit MathML work, I'm leaning on RenderBlock instead, at least for now.

Alex's basic technique is to layout children inside nested anonymous RenderBlocks, using block layout to get vertical stacking, and essentially inline-block to get horizontal layout. He then sets CSS padding or sometimes margins to adjust these anonymous RenderBlocks horizontally & vertically if needed. For instance, <msubsup> is like base<sub>subscript</sub><sup>superscript</sup> except that the superscript is supposed to be over the subscript, i.e. start just to the right of the base. Alex's clever trick is to put the superscript & subscript together in an anonymous RenderBlock. The whole thing looks like this:

RenderMathMLSubSup (like inline-block, derives from RenderBlock)
    Anonymous inline-block RenderBlock (for setting its padding-top)
        base
    Anonymous inline-block RenderBlock, with { vertical-align: top }
        Anonymous block RenderBlock (for vertical/block layout, and to set its padding-bottom)
            superscript
        Anonymous block RenderBlock (for vertical/block layout)
            subscript

Then RenderMathMLSubSup::layout() computes and sets these paddings, to control each child's vertical position, followed by calling layout() on the anonymous blocks so the paddings take effect. This use of RenderBlock and CSS may seem like overkill just to set and adjust some horizontal and vertical positions. On the other hand, one could argue that while this use of anonymous blocks is different than their use in normal flow layout, their convenience is analogous. Your opinions are solicited.

If we stay with this approach, a couple complications arise in practice. First, the superscript and subscript can currently be inlines, as discussed in my comment #13 above (which hopefully makes more sense after this introduction). That comment also discusses how to deal with this, or says we can change them to inline-blocks and have a RenderWrapper (RenderPad? RenderMargin?) class that's a simplfied variant of the above absolute-positioning-like technique with exactly one child renderer.

Second, anonymous blocks currently do some things like inherit CSS from their parents, as discussed by Alex M. in https://lists.webkit.org/pipermail/webkit-dev/2011-June/017231.html. I think we can get around this by adding a check, or maybe a flag if necessary, once we have the right design chosen.

So what do you experts think of all this? Does Julien or someone want to write some kind of RenderWrapper class(es) that MathML could use or derive from? Or should we use the current inline-block technique, i.e. RenderBlock, anonymous when necessary? Please let me know your short- and long-term recommendation, and then I'll submit another patch. Thanks!!

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.