[webkit-dev] Ruby design document

[Roland Steiner]

[+Ian]

Hi Dave,

I just added all elements from both specs, as it was easy and
straightforward enough. Code-wise, the RubyBaseContainer & RubyTextContainer
objects don't add much complexity (the multiple runs within a single ruby
element from the HTML5 spec pose more of a challenge, tbh). Now, I don't
know of any concrete use cases, but I still left them in for the time being,
for the following, admittedly rather flimsy, reasons:

.) being able to have ruby text both in before and after positions seems
like it could be useful
.) it seemed useful to have a wrapping block element in case the input is
malformed, has extraneous <rt> elements, or tries to do cute tricks (e.g.,
adding line breaks). *)
.) the Firefox plugin honors them
.) there are several sites that detail how to use CSS inline-table to get
complex ruby rendering, so I thought that perhaps there are actual use cases
out there after all

*) If those elements are removed, the number of box model objects are
reduced, but the code required for layouting and error handling might get
rather more involved.

However, if the consensus is that we should rather take those objects out
(Ian Hickson doesn't seem to be a fan of complex ruby, either), then of
course I can remove them from the code. The resulting object model would
probably look like:

    ruby : RenderInline or RenderBlock (inline-block)
        ruby-run : RenderBlock (inline-block with inline children) - 1 or
more
            ruby-base : RenderInline -> InlineFlowBox - 1
            ruby-text : RenderInline -> InlineFlowBox - 0 or 1 (could even
allow 2, for both 'before' and 'after' positions)


Cheers,

Roland

On Wed, Jun 3, 2009 at 3:43 PM, David Hyatt <hyatt at apple.com> wrote:

> On Jun 3, 2009, at 4:59 PM, Roland Steiner wrote:
>
>  Hi Peter,
>>
>> You're right, that was an oversight, I added the reference to the
>> introduction part, and highlighted the differences as you mentioned.
>>
>> My current implementation aims to be forward-compatible with both HTML5
>> and CSS3, which seems to be rather straightforward from the pure object
>> model. It allows for several runs as per the HTML5 spec, and some variations
>> in the positioning as per the CSS3 spec. I'm not currently implementing CSS3
>> complex ruby, line stacking or ruby overhang.
>>
>
> It seems like the design could be simplified considerably if we just say
> we're not going to do complex ruby.  Given that it's not in HTML5 and that
> IE doesn't do it, is complex ruby something we even want to worry about?
>
> dave
> (hyatt at apple.com)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090603/e776691f/attachment.html>