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 <[email protected]
> 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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
