[webkit-dev] Two Pass Layout?

Alex Milowski alex at milowski.org
Thu Sep 17 12:45:53 PDT 2009

I've been thinking a bit more about stretchy operators in MathML.  The
following bits are equivalent:

   <mfenced open="{" close="}"><mfrac><mn>1</mn><mi>x</mi></mfenced>


The open and close curly bracket should be stretched to the max
vertical size of
the contained inline sequence.

Even more interesting is:

               <mtr><mtd><mn>1</mn></mtd><mtd><mtext>if odd</mtext></mtd></mtr>
               <mtr><mtd><mn>0</mn></mtd><mtd><mtext>if even</mtext></mtd></mtr>

where the left curly bracket vertical stretches to the hight of the mtable.

I'd like to re-oriented the code I have to include an RenderMathOperator class
that can stretch operators that stretchable and do something else for ones
that aren't (e.g. curly brackets can be stretched but angle brackets can only
be resized by font size to a certain maximum before they look strange).

Anyway, the way this needs to work is the inline sequence for the row
needs one layout pass to determine the maximum height size and then
the instances of this RenderMathOperator class are be given their
"stretch size" as calculated by their siblings.  Then a second pass
would layout the content given the stretched operator's size.

RenderMathOperation would be an inline-block so when the operator
is stretched, a stack of blocks would be used to contain the glyph stack
and otherwise the base font size would just be adjusted accordingly.

The consequence of this, as I've noted before, is that I somehow need
to "invalidate" the line boxes for the containing inline-block for the
mrow/mfenced.  I've tried this a number of ways but it seems that things
go wrong when the mrow/mfenced contains certain kind of replaced
content (e.g. inline-table).

So, a couple of questions:

1. Is there a draconian way to just say "invalid, start over" so that
    in the layout method of the mrow/mfenced I can just call
    layout twice?

2. When I make these kinds of changes in sample XHTML + Javascript
    everything seems to reflow properly.  The javascript manipulates
    the style.  Is there some kind of "style changed" sequence of method
    calls that I should be using?

Right now, for (1), bad things happen if the content has no
replace content or contains things like an inline-table.  That makes
me think I'm not really invalidating everything.

My thinking on (2) is that if I can do this in handwritten javascript I should
be able replicated the cascade of layout changes via method calls if I
only knew where to start.

--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language

Bertrand Russell in a footnote of Principles of Mathematics

More information about the webkit-dev mailing list