[webkit-dev] Q on CSSStyleSelector::adjustRenderStyle(), render tree node ordering

[Roland Steiner]

On Wed, May 27, 2009 at 6:37 PM, David Hyatt <hyatt at apple.com> wrote:


Thanks a lot for your answers!

On May 27, 2009, at 8:21 PM, Roland Steiner wrote:
>
>  Hi all,
>>
>> As I am currently hacking on implementing ruby for WebKit, I came across 2
>> questions where I couldn't find a good answer in the code, and thus would
>> like to ask people more knowledgable than me:
>>
>> Question #1: CSSStyleSelector::adjustRenderStyle
>> (css/CSSStyleSelector.cpp) changes the effectiveDisplay value of a node.
>> Amongst other things:
>>
>>        // Mutate the display to BLOCK or TABLE for certain cases, e.g., if
>> someone attempts to
>>        // position or float an inline, compact, or run-in.  Cache the
>> original display, since it
>>        // may be needed for positioned elements that have to compute their
>> static normal flow
>>        // positions.  We also force inline-level roots to be block-level.
>>
>> I.e., basically, for positioned and floating elements it changes
>> INLINE_TABLE -> TABLE, INLINE_BOX -> BOX, everything else -> BLOCK. Now, a
>> ruby is analogous to an inline block, or inline table. However, there is no
>> analogous block-level object for ruby. Therefore I wondered whether it
>> wouldn't be ok (or even better, read: less error prone) to generally just
>> wrap such objects into an anonymous block instead of changing the display
>> value (with an exception for positioned/floated table parts that are handled
>> after that point in the code).
>>
>>
> My own expectation is that if you float or position a ruby it would just
> stop being a ruby and turn into a normal block.  Maybe others disagree
> though.
>

Just to clarify in order to avoid misunderstandings: with ruby I meant the
whole <ruby> element, including the base text, not just the ruby
text/annotation part.

Thus converting <ruby> to a block is IMHO not satisfying, as positioning the
ruby would cause it to no longer render correctly (its content just gets
dumped).
Also,    <ruby style="float:left"> A <rt> B </rt></ruby>    would not render
as a ruby, but    <span style="float:left"><ruby style="float:left"> A <rt>
B </rt></ruby></span>    would render correctly.


>
>  Question #2: Is there code that would expect that the relative order of
>> objects in the render tree follows the relative order of the corresponding
>> nodes in the DOM tree (i.e., if DOM-node-B is after DOM-node-A then
>> render-node-B should also be after render-node-A, where "after" means in the
>> same order encountered when doing a depth-first search). Or am I worrying
>> too much and I can order the nodes in the render tree without regard for the
>> DOM tree?
>>
>>
> You cannot order nodes in the render tree without regard for the DOM tree.
>  There is an assumption of document ordering in the RenderObject lists.
>  Check out how newly created renderers from the DOM get inserted passing in
> previous renderers for example.
>

Thanks. Solution #2 (muck around with layouting) it is, then! ^_-


Cheers,

Roland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090527/3d480e37/attachment.html>