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

Roland Steiner rolandsteiner at google.com
Wed May 27 18:21:51 PDT 2009

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).

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?


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

More information about the webkit-dev mailing list