[webkit-dev] Ruby design document

David Hyatt hyatt at apple.com
Wed Jun 3 17:33:02 PDT 2009


On Jun 3, 2009, at 7:15 PM, Maciej Stachowiak 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.
>

I guess what I'm getting at is that if you remove the complex ruby  
concept of being able to break across multiple lines, then couldn't  
simple ruby could just be implemented using slightly specialized table  
subclasses?

I also think it's good to question what is in both of these specs  
rather than simply implementing them.  I don't think there is any  
serious implementation of <ruby> yet, so we have the freedom I think  
to question just about everything.

For example, is it an IE compatibility constraint that you can have  
one or more groups of annotated phrasing content inside a <ruby>?  If  
it is, then I guess we're stuck with it, but if that's something Ian  
invented I'm inclined to push back on it and limit to 1.

I think knowing the high level reason why we're implementing <ruby> in  
WebKit would be helpful.  Is the primary goal compatibility with IE?   
Is it to implement HTML5?

The CSS3 draft is clearly very incomplete and not ready for primetime,  
so the more I look at it, the more I'm thinking we should maybe just  
limit ourselves to an HTML5/IE-compatible implementation.

dave

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


More information about the webkit-dev mailing list