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