On Wed, May 27, 2009 at 6:37 PM, David Hyatt hy...@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/rubywould not render
as a ruby, butspan style=float:leftruby style=float:left A rt
B /rt/ruby/spanwould 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
