21041 2013-02-18 14:58:13 +0000 Inlining ruby 2016-04-20 19:16:03 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified Other other RESOLVED WONTFIX P2 enhancement --- 20114 1 robin robin annevk arronei eoconnor fantasai.bugs ian jackalmage kojiishi mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 83274 0 robin 2013-02-18 14:58:13 +0000 +++ This bug was initially created as a clone of Bug #20114 +++ From: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0370.html The current ruby model explicitly uses a "column-based" model of ruby, where runs of base text and ruby text must alternate in the markup, so that ruby text is associated with the immediately preceding ruby base. This does *not* work well for common ruby inlining cases. For example, the word Tokyo is written as 東京 in kanji and とうきょう in kana. The base-text pairs are 東-とう 京-きょう, and the ruby markup must create those associations accordingly. However, when rendered inline, the correct rendering is 東京(とうきょう) with the word kept together as one unit, not 東(とう)京(きょう). The current ruby model in HTML, though, requires that you either mark up the ruby correctly and get the latter display, or incorrectly group the entire thing as one ruby text over one ruby base to get the former display. This is important, because inlining is not just a fallback measure for down-level clients. Inlining is often done as a legitimate stylistic choice, such as when there's only a small amount of ruby in the text (to avoid the increased line-height on the few lines that contain ruby) or when the base text is already small (to avoid making the ruby text unreadably small). This can be solved easily by also allowing a "row-based" model, where runs of <rb> elements can be followed by runs of <rt> elements, and they're matched up index-wise. If you can then switch back to <rb>, you still retain the convenience of "column-based" when that's sufficient. 125959 1 arronei 2016-04-20 19:16:03 +0000 HTML5.1 Bugzilla Bug Triage: This bug constitutes a request for a new feature of HTML. Our current guidelines, rather than track such requests as bugs or issues, is to create a proposal for the desired behavior, or at least a sketch of what is wanted (much of which is probably contained in this bug), and start the discussion/proposal in the WICG (https://www.w3.org/community/wicg/). As your idea gains interest and momentum, it may be brought back into HTML through the Intent to Migrate process (https://wicg.github.io/admin/intent-to-migrate.html).