This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
Here's the markup for writing that ruby inline: <p>東京(とうきょう)</p> No need to use <ruby> elements at all.
(In reply to comment #1) > Here's the markup for writing that ruby inline: > > <p>東京(とうきょう)</p> > > No need to use <ruby> elements at all. If you know ahead of time that you'll be styling it as inline only and forever, yes. If you don't (which is quite reasonable), or if you know ahead of time that in *some* contexts you'll want to style it as inline and in others you'll want it stacked, that obviously won't work.
I'm very skeptical that there are common cases where you'd really need this level of control and not know ahead of time which rendering you need. Can you give examples of sites that would need this? How common is this anyway?
(In reply to comment #3) > I'm very skeptical that there are common cases where you'd really need this > level of control and not know ahead of time which rendering you need. Can > you give examples of sites that would need this? How common is this anyway? I can ask some Japanese contacts for real-world examples, but in the meantime I can offer some theoretical ones. The most obvious example is the fallback one. If you want the "everything combined" model in legacy browsers, but the "each on its own base" model in ones that support ruby, you clearly need this level of control. Another example is if you have ruby markup in some text that's also copied into a pull-quote. Your body text size is too small for normal ruby, so you want to inline it, but the pull-quote text size is fine, and space is important there anyway, so you want on-top ruby. Ideally, this can be done without tweaking your markup. Another example is a blog that uses ruby in its posts, and has excerpts from the most recent posts in a sidebar in small text. The excerpts are too small for the ruby text to be easily readable, so you want to make it inline. Again, it would be great it you could auto-generate the excerpts from your database without having to tweak the markup.
(In reply to comment #3) > I'm very skeptical that there are common cases where you'd really need this > level of control and not know ahead of time which rendering you need. Can > you give examples of sites that would need this? How common is this anyway? Are you asking whether inline-ruby is needed, or whether inline-ruby needed to be as good as this level? There are some use cases for inline-ruby as Tab pointed out. CSS Ruby is currently left unedited for a while but it defines inline as one of the styles. In addition to small size case Tab raised, accessibility has pointed out that inline is easier than regular style ruby for some people. And if we were to do inline, 東(とう)京(きょう) is somewhat readable but awkward. 東京(とうきょう) is easier to read, less obstructive, and looks natural. I'm not sure if these answer your question, or if you are asking, knowing doing so is better, whether HTML should support good inline or not. Can you clarify?
My question is how common is it for Web authors to write ruby that splits in this manner, and want to at runtime dynamically change whether it's rendered inline or overhead. Does every Web page do this? Does every site do it once? Is it something very common to a very few rare sites? Something very rarely used on each site but used at least once on many sites? Supporting this requires making the Web platform more complicated, which is a very high cost. If there's only a few thousand pages on the whole Web that are going to ever have this problem, then the decision is a trivial one. My skepticism comes from how rarely authors actually want to dynamically change presentation of any kind, especially to this level. If for some reason this is a common desire, though, the weight of the decision goes the other way. (There's plenty of things on the Web platform that aren't possible at all, let alone possible by just changing the markup as in this case. It's not unusual for us to let uncommon things require script to be handled. Given how rare ruby as a whole actually is, I want to tread very carefully before assuming something is common enough to warrant being supported.)
First about whehter authors would want to use multiple mono-ruby style tags (multiple ruby tags in a row) or jukugo-ruby style tags (multiple rt tags in a ruby tag.) Today, most authors use multiple mono-ruby style as that's the only way to look right across browsers with proper line break opportunities, but I'm hearing wishes to move to jukugo-ruby style because 1) it gives less tags, and 2) gives more flexibility to style. I suspect in a long run that, with CSS Ruby well-defined, authors will use jukugo-ruby style tags everywhere, and use CSS to switch between mono and jukugo. How much authors want to style ruby as inline is hard to answer, because oftentimes it's not the author who want to style them as inline, but UA or viewing users, given the ultimate control of font-size is on users' hand. In EPUB UAs where allowing user to change font size is quite common, most UAs do not allow font size being smaller than a certain size. But we're hearing that ruby is unreadable in such font size. Making them as inline or popup is one way to solve the complaints, but it's hard to do given the result the current inline would be. That motivate us UA vendors to improve inline styling of ruby without changing tags. Combine the two use cases, one for authors and the other for users, I believe the wish for HTML to allow such switch without re-writing tags is stronger than you're saying. But this discussion is hard, because we're comparing benefits and cost here, you believe the cost to support the feature is high and wonder how high the requirement is. I know the requirement but wonder how high the cost is. Which side says "this is high" more strongly doesn't look a good way to make the call. My understanding is that, given I18N WG's support, implementers are willing to gather and discuss the best design/implementation options and see how high the cost really is, so that we could make better decision here. Tab and fatasai's efforts are the first step to do this. I wish them to keep driving the efforts and define an extension spec, without making the final call whehter to integrate the extension spec to HTML5 or not. By the time the extension spec is done, we'll know the cost/benefit comparison much better than today. Is this reasonable?
Regarding your first point, they are semantically equivalent in the spec, so either is fine. Regarding the topic of this bug — that is, adding markup-level data that denotes how to render the annotations inline if they're not rendered as ruby, for the case of a page where the rendering is to change dynamically — I haven't heard of a single site that actually does this, so I'm still extremely skeptical that there is enough demand to actually justify this feature. Regarding writing another spec to do this, anyone is always able to write a spec, there's nothing I or anyone else can do to stop you. But if I haven't put an HTML elemnet in the HTML standard, it's usually because I don't think it should exist, not because I think it should be done elsewhere. So my arguments against such a spec would be the same as against adding it to HTML. My recommendation would be to look for sites that use ruby and where either the site or the user is dynamically changing the rendering between these two styles where the current markup is insufficient.
To proceed with this bug, I need to look at real pages that annotate multiple characters of a base word individually (mono-ruby for compound words, or jukugo ruby) and either: 1. The page dynamically changes whether it is rendered inline or as proper ruby. 2. The page is rendered in two kinds of environments, one where the font size is adequate for ruby, and one where the text has to be inline for it to be readable. Incidentally, a simpler solution for the hypothetical cases brought up so far would be just an attribute on <ruby> to indicate that the annotations, when rendered inline, should just be collapsed into one at the end rather than inserted where they are in the markup. Are there cases where that doesn't address the problem? Please reopen the bug if you can provide links showing the above.