[Webkit-unassigned] [Bug 3749] XHTML 1.1 Ruby Annotation

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jul 23 23:52:35 PDT 2009


https://bugs.webkit.org/show_bug.cgi?id=3749





--- Comment #22 from Roland Steiner <rolandsteiner at google.com>  2009-07-23 23:52:34 PDT ---
(In reply to comment #21)
> (From update of attachment 32823 [details])
> Why an extra ruby stylesheet?  I think the rules can just go in html.css. 
> There are only 4!

The idea was that ruby.css would not be included if ENABLE_RUBY isn't set. Esp,
the CSS rule "rp { display: none; }" shouldn't be used in that case.

> Can rp just always be display:none?
>
> When does rt occur outside a ruby?

Both shouldn't occur outside of <ruby>, but the HTML5 spec says: "An rt element
that is not a child of a ruby element represents the same thing as its
children." (same for <rp>).

> I do not like the addition of an extra virtual function call in
> InlineFlowBox.cpp's placeBoxesVertically method.  Possible to avoid it?

Will remove this and re-order the children instead, as discussed on #webkit. 

> In RenderBlock.cpp I worked hard to devirtualize the container walk, so having
> it be re-virtualized is bothersome.  I'm curious why that is needed.  It looks
> like you're using some CSS style constant to scramble order.  Is that actually
> part of HTML5?

My very first implementation was more CSS3 oriented . That constant and the box
model are the only holdover from that implementation: I felt that the ability
to choose where to put the ruby text (in the 'before' or 'after' position) was
worthwhile to keep. At the moment, this is more of an implementation detail,
though - while you CAN put the ruby text into the 'after' position with the
current implementation, I haven't added layout tests for that feature yet,
because I felt that it may be controversial.

Even without that constant the virtual function however would have been
necessary anyway in the current approach, to scramble the layout order as you
say.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list