[webkit-dev] Inline vs Inline Block and relative positioning for MathML

[David Hyatt]

You really don't want to use relative positioning to move objects  
around like this.  The objects should just be placed into the correct  
positions by the layout() method without having to resort to relative  
positioning.

You also can't mutate a DOM-backed renderer's style like that as it  
could be shared by other renderers.

updateBoxModelInfoFromStyle is an internal method to styleWIll/ 
DIdChange.  It should never be called directly by anyone.  I should  
probably make it so that it cannot be called from subclasses to make  
that less confusing.

Raw casts are a no-no in the render tree.  Always use the toRenderXXX  
method, e.g., toRenderBoxModelObject, toRenderBox, toRenderInline, etc.

Solutions I can think of to this problem include adding a new CSS  
property to indicate that sub/sup objects should sit together.... or  
just make sure the line box code in placeBoxesHorizontally does a  
query to see if you're in MathML (which may be easier if some object  
is subclassed).

dave
(hyatt at apple.com)

On Aug 27, 2009, at 9:35 AM, Alex Milowski wrote:

> I'm struggling with something I don't quite understand.  I get a  
> different
> behavior when the superscript is an instance of RenderInline versus
> and inline-block instance of RenderBlock for the superscript.   
> Specifically,
> it works just fine in the case of the RenderInline but not when the  
> superscript
> is an instance of RenderBlock.
>
> What I need to do is relatively position the superscript back to the  
> right most
> edge of the base.  The layout has first the base, then the  
> subscript, and
> then the superscript.  The superscript is then relatively positioned  
> back
> to the base's right edge as it starts out at the right edge of the  
> subscript.
>
> Here's the layout code that partially works:
>
> void RenderMathSubSup::layout() {
>    RenderBlock::layout();
>    RenderBoxModelObject *base = (RenderBoxModelObject *)firstChild();
>    RenderBoxModelObject *subscript = base ? (RenderBoxModelObject
> *)base->nextSibling() : 0;
>    RenderBoxModelObject *superscript = subscript ?
> (RenderBoxModelObject *)subscript->nextSibling() : 0;
>    if (superscript) {
>        int adjust =
> superscript->offsetLeft()-base->offsetLeft()-base->offsetWidth()-1;
>        superscript->style()->setLeft(Length(-adjust,Fixed));
>        superscript->style()->setPosition(RelativePosition);
>        superscript->updateBoxModelInfoFromStyle();
>        int baseSub = base->offsetWidth()+subscript->offsetWidth()+1;
>        int baseSup = base->offsetWidth()+superscript->offsetWidth()+1;
>        style()->setWidth(Length(baseSub>baseSup ? baseSub :  
> baseSup,Fixed));
>        updateBoxModelInfoFromStyle();
>        markContainingBlocksForLayout();
>    }
> }
>
>
> What confuses me is that the calculated block position is correct  
> for the
> superscript and I can inspect that in the Console in Safari but the  
> actual
> glyphs rendered are still in the original place.  That leads me to  
> believe that
> a repaint was not actually invoked.
>
> Any ideas?
>
> I've been digging through the source code for examples but most of
> the renders seem to either have their own layout code and rely upon
> existing layouts of inline or block flows.
>
> -- 
> --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
> considered."
>
> Bertrand Russell in a footnote of Principles of Mathematics
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev