[webkit-dev] Ruby design document

[Roland Steiner]

Ok, in that case should I also remove the code and constants for the
complex-ruby-specific CSS3 properties and HTML 'span' attribute, or should I
leave them in the code (and they just get ignored)?

Cheers,

Roland


On Wed, Jun 3, 2009 at 5:15 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Jun 3, 2009, at 5:12 PM, Peter Kasting wrote:
>
> On Wed, Jun 3, 2009 at 5:04 PM, Roland Steiner <rolandsteiner at google.com>wrote:
>
>> 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)
>>
>
> Seems like it wouldn't be hard to add the complexity in later (as a second
> pass) if we decide there's value there; in the meantime, writing the
> simplest possible implementation has testing and code readability benefits.
>  I suggest sticking with the simple stuff that's sufficient to do HTML5 as a
> first pas.  When everything is in, tested and working, you can evaluate if
> more complex support a la the current CSS3 spec is a good idea.  If so it'd
> probably make sense to get HTMLx (whatever x is by then, perhaps 6) to agree
> so that other browsers are all on board too.
>
>
> I had the same reaction. Handling simple ruby seems like a good first step,
> even if we decide later that we want to add complex support.
>
> Cheers,
> Maciej
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090603/1c3f52f5/attachment.html>