Re: [webkit-dev] Ruby design document
Addendum: .) IE does NOT honor 'display: ruby' Cheers, Roland On Wed, Jun 3, 2009 at 6:30 PM, Roland Steiner wrote: > Hi Dave, > > thanks for the feedback! To answer some of the questions you raised: > > .) There certainly is a demand for this feature in Japan, China, and other > countries. The only browser that natively supports ruby currently is IE, so > I would assume most of the pages that use ruby today are written at least > with IE in mind. Therefore, the base line would be compatibility with that, > which boils down to implementing the HTML5 spec. > > There are also apparently still be some pages left that adhere to a very > early ruby draft (http://www.w3.org/TR/1999/WD-ruby-19990322/), but I'm > not sure it's worth extra work to try to support that (haven't looked at > that in great detail yet). > > .) IE (at least IE8) honors 'float' and 'position' on ruby elements, and > also 'display:block' works as expected. > > .) Multiple runs within a single element are rendered correctly in > IE (which I would suppose is the original reason for their inclusion in > HTML5). IE also line-breaks those runs. > > > Cheers, > > Roland > > > > On Wed, Jun 3, 2009 at 5:39 PM, David Hyatt wrote: > >> On Jun 3, 2009, at 7:33 PM, David Hyatt wrote: >> >> >>> 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. >>> >>> >>> >> In other words I'm thinking we should just make the only way you >> can make these things, and not necessarily support the CSS stuff yet. I am >> concerned about crashes related to crazy interactions of all these new ruby >> display types (every time we add new display types the render tree >> complexity goes up, since any element can implement the display type and be >> put inside any other display type). >> >> For example, I don't even think display:ruby should be the right way to >> make a ruby in CSS, since a ruby clearly can be either block-level or >> inline-level. You need two display types and not just one. >> >> How the ruby box model works in CSS is woefully underspecified as well. >> >> For now we could just hardcode the creation of the specific renderers when >> the tag names are encountered. This has the added benefit of allowing you >> to make a ruby inline or block by changing the display type. I'd suggest >> testing in IE in fact to see what happens when you float/position a ruby or >> when you specifically put "display:block" on a ruby. >> >> dave >> (hy...@apple.com) >> >> >> >> >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
Hi Dave, thanks for the feedback! To answer some of the questions you raised: .) There certainly is a demand for this feature in Japan, China, and other countries. The only browser that natively supports ruby currently is IE, so I would assume most of the pages that use ruby today are written at least with IE in mind. Therefore, the base line would be compatibility with that, which boils down to implementing the HTML5 spec. There are also apparently still be some pages left that adhere to a very early ruby draft (http://www.w3.org/TR/1999/WD-ruby-19990322/), but I'm not sure it's worth extra work to try to support that (haven't looked at that in great detail yet). .) IE (at least IE8) honors 'float' and 'position' on ruby elements, and also 'display:block' works as expected. .) Multiple runs within a single element are rendered correctly in IE (which I would suppose is the original reason for their inclusion in HTML5). IE also line-breaks those runs. Cheers, Roland On Wed, Jun 3, 2009 at 5:39 PM, David Hyatt wrote: > On Jun 3, 2009, at 7:33 PM, David Hyatt wrote: > > >> 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. >> >> >> > In other words I'm thinking we should just make the only way you can > make these things, and not necessarily support the CSS stuff yet. I am > concerned about crashes related to crazy interactions of all these new ruby > display types (every time we add new display types the render tree > complexity goes up, since any element can implement the display type and be > put inside any other display type). > > For example, I don't even think display:ruby should be the right way to > make a ruby in CSS, since a ruby clearly can be either block-level or > inline-level. You need two display types and not just one. > > How the ruby box model works in CSS is woefully underspecified as well. > > For now we could just hardcode the creation of the specific renderers when > the tag names are encountered. This has the added benefit of allowing you > to make a ruby inline or block by changing the display type. I'd suggest > testing in IE in fact to see what happens when you float/position a ruby or > when you specifically put "display:block" on a ruby. > > dave > (hy...@apple.com) > > > > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
On Jun 3, 2009, at 7:33 PM, David Hyatt wrote: 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. In other words I'm thinking we should just make the only way you can make these things, and not necessarily support the CSS stuff yet. I am concerned about crashes related to crazy interactions of all these new ruby display types (every time we add new display types the render tree complexity goes up, since any element can implement the display type and be put inside any other display type). For example, I don't even think display:ruby should be the right way to make a ruby in CSS, since a ruby clearly can be either block-level or inline-level. You need two display types and not just one. How the ruby box model works in CSS is woefully underspecified as well. For now we could just hardcode the creation of the specific renderers when the tag names are encountered. This has the added benefit of allowing you to make a ruby inline or block by changing the display type. I'd suggest testing in IE in fact to see what happens when you float/position a ruby or when you specifically put "display:block" on a ruby. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
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 > 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 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 ? 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 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
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 wrote: > > On Jun 3, 2009, at 5:12 PM, Peter Kasting wrote: > > On Wed, Jun 3, 2009 at 5:04 PM, Roland Steiner > 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
On Jun 3, 2009, at 5:12 PM, Peter Kasting wrote: On Wed, Jun 3, 2009 at 5:04 PM, Roland Steiner > 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
On Wed, Jun 3, 2009 at 5:04 PM, Roland Steiner 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. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
[+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 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 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 > (hy...@apple.com) > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
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 (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
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. Thanks, Roland On Wed, Jun 3, 2009 at 2:17 PM, Peter Kasting wrote: > On Wed, Jun 3, 2009 at 2:12 PM, Roland Steiner > wrote: > >> I am in the process of implementing ruby (text annotations, mainly used in >> East-Asian text), and would welcome if folks could give me feedback on my >> design document, esp. regarding the rendering/layouting: >> >> http://docs.google.com/View?id=dcgd8hk6_0ccsw4td4 > > > Your doc mentions the CSS3 ruby specs, but not the HTML5 specs (e.g. > http://www.whatwg.org/specs/web-apps/current-work/#the-ruby-element ). It > would be good to link to the HTML5 doc, and perhaps note differences between > the specs (I suggest implementing HTML5 in any cases where HTML5 and CSS3 > differ). > > PK > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
On Wed, Jun 3, 2009 at 2:12 PM, Roland Steiner wrote: > I am in the process of implementing ruby (text annotations, mainly used in > East-Asian text), and would welcome if folks could give me feedback on my > design document, esp. regarding the rendering/layouting: > > http://docs.google.com/View?id=dcgd8hk6_0ccsw4td4 Your doc mentions the CSS3 ruby specs, but not the HTML5 specs (e.g. http://www.whatwg.org/specs/web-apps/current-work/#the-ruby-element ). It would be good to link to the HTML5 doc, and perhaps note differences between the specs (I suggest implementing HTML5 in any cases where HTML5 and CSS3 differ). PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Ruby design document
Hi all, I am in the process of implementing ruby (text annotations, mainly used in East-Asian text), and would welcome if folks could give me feedback on my design document, esp. regarding the rendering/layouting: http://docs.google.com/View?id=dcgd8hk6_0ccsw4td4 Thanks, Roland ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
