Closed Bug 33339 (ruby) Opened 25 years ago Closed 6 years ago

[meta] HTML5 <ruby> support


(Core :: Layout, defect, P4)




Tracking Status
relnote-firefox --- 38+


(Reporter: bobj, Assigned: smontagu)


(Depends on 2 open bugs, Blocks 1 open bug, )


(10 keywords, Whiteboard: [adt2])


(9 files, 1 obsolete file)

Support "Ruby Annotation -- W3C Working Draft 17 December 1999" which looks
something like:
     <rp>(</rp><rt>World Wide Web</rt><rp>)</rp>
Changed URL field to location of current official document:
Adding Roger Sidje to Cc list. In some ways, Ruby is similar to some of the
things that MathML requires. In Ruby, the main text is in one normal size, and
the Ruby text is smaller and drawn above or below the main text (in the
horizontal case; left or right in the vertical case).

In math, we also have superscripts and subscripts, and various things drawn at
various sizes above and below other things, and so on. It is quite possible
that Roger and the other MathML folks could have some good ideas for Ruby too,
or perhaps whoever implements Ruby could get some ideas from the MathML code.
Then again, Ruby is simpler, and is somewhat similar to a plain table, so
perhaps we don't need anything as complicated as MathML's implementation.
Ruby is not a gecko 1.0 feature. I'll put it on the remind list in case we have 
Closed: 25 years ago
Resolution: --- → REMIND
   Would you mind leaving this open and marked M20 instead of marking it
RESOLVED, so it is easier to find doing bugzilla queries?  Or you could
assign it to  (It went to you by default since the
component is HTML Element.)

Added "helpwanted" in case we can find an eager mozilla-ite to look into this.
As erik points out, we may be able to leverage from the great MathML work.

BTW, IE5 has this feature and does "advertises" it as one if its I18N features.
Keywords: helpwanted
Summary: HTML <RUBY> support → XHTML <RUBY> support
Depends on: 39965
massive update for QA contact.
QA Contact: petersen → lorca
Taking bobj's advice and reopening to leave it on M21-sound good?  Smack me later 
if not.
Resolution: REMIND → ---
Target Milestone: --- → M21
Fine. Open if you want. I'm marking it future, though, to make it clear that 
it's not a 6.0 feature.
Priority: P3 → P4
Target Milestone: M21 → Future
Keywords: xhtml
CC'ing nhotta who is also looking into the issues surrounding ruby.
Keywords: intl
Assignee: rickg → nhotta
nhotta- why don't you own it for now.
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
qa contact updated.
QA Contact: gerardok → bsharma
Update: On April 6, 2001: Ruby Annotation became a W3C Proposed Recommendation.
For rendering we also need to deal with "CSS3 module: Ruby", W3C Working Draft:
We need a spec that goes beyond the w3c proposal.  We should spec everything
as much as possible, but we probably want to implement in phases.  Some thoughts
in no particular order:
  - exporting (or copying&pasting) to plain text w/ and w/out <rp>
    - when no <rp>, how do we determine how to "parentesize"?  should it
      be locale (xml:lang=xx) sensitive? and directional (horiz v. vert)
  - editor support (if any)
  - ruby positioning support.  See
  - font size algorithm (minimal size or something to keep it readable?)
  - default style sheet
  - backwards compatibility?  See
  - "CSS3 module: Ruby" ( support?
     - still a working draft, but could be a ton of work to implement
Ruby has become a W3C Recommendation on May 31, 2001. So even if I think it 
won't be in Mozilla 1.0, I hope to have it soon after. wrote on 2000-03-27 11:48:
> IE5 has this feature and does "advertises" it as one if its I18N features

I don't know how the support is in IE 5.5. In IE 5, the simple ruby (see 
the "world wide web" example above) does indeed work. However complex ruby like 
this one is not yet supported (the rendering is a complete rubbish):

    <rt rbspan="3">Expiration Date</rt>
Added ftang.
Maybe simple ruby as below is enough.

     <rp>(</rp><rt>World Wide Web</rt><rp>)</rp>

Becaouse <rbc> and <rtc> gives no additional feature to represent ruby.
 For example above, I would like to write as below.

I don't think it would be "enough". Because this takes away a lot of the ruby 
feature. And your example isn't quite the same like the one above: where would 
you put (and how?) "Expiration Date"? You can't make it span 3 ruby elements.

As mentioned already, supporting ruby should not be that hard since it is 
working like mathML is working. And if we support simple ruby, then I guess it 
would be silly to not support the complex one as well.
If you can support full specification of <ruby> as early as IE spec, I would 
like to say nothing.
But I saw such complex ruby only in the recommendation.
Do you saw such example???
Please show the example other tahn the recommendation. I think engineering 
sense of IE is good.,
I haven't seen ruby anywhere. But there is an obvious reason for it: if you 
have no browser supporting it, why would you use it anyways? The first step is 
on the browser's side to support it, then the webmasters will start to use it. 
Only then. And of course, while it was only a proposed recommendation, 
developpers wouldn't care of it. Now that it is part of the new XHTML 1.1 spec, 
now it will catch a broader audience. My 0.02$.
My philosophy is that we should design to support Ruby "fully".  When we
implement, we can choose to phase in the work (e.g., first support "simple"
Ruby).  But understanding the design for "full" support will influence how we
implement the first phase, and hopefully prevent us from going down too many
wrong paths that might give us headaches in the next phase.

WG3 stuff specifies the technology level, but we also need to specify the
application requirements and features.  For some ideas, see my comment from
Ruby was not made for HTML. Ruby has long history in printings in Japan. I said 
that I did not see an example of complex ruby in books and magazines of paper.

Note that ruby is now part of the offical XHTML 1.1 rec.

And Netscape has commited to supporting it <URL: >:

"Netscape will support Ruby in adherence to the W3C XHTML recommendation, as 
well as forthcoming related CSS recommendations, through the open-source 
Mozilla project and in future versions of its award-winning Netscape web 

-- Jim Hamerly, Vice President of Netscape Client Product Development division
Wow, people actually read those testimonials.  :-) Unfortunately, Ruby won't
make it for Mozilla 1.0. or the impending Netscape 6.1 release.

Netscape is sincere in what we wrote, and intend to get really moving on this
after we complete our near-term priorities.  But we'll also take any help we
can get from other Mozilla developers!

-Bob (testimonial ghost writer)
For reference, the XHTML 1.1 spec declares its use of the Ruby Annotation module at
Component: HTML Element → Layout
SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.
QA Contact: bsharma → moied
make this a meta bug and add it to the 104930
Blocks: 104930
Keywords: meta
Re Comment #16

] Becaouse rbc and rtc gives no additional feature to represent ruby.
]  For example above, I would like to write as below.

The feature they give is clean fallback to non-ruby browsers,
although the existence of the pre-simple ruby in IE5.5, 
confuses the issue.

With rbc and rtc you can arrange for the base text and 
annotation to interleave on a line by line basis, not 
just a word by word basis (more accurately, paragraph
by paragraph, for good XHTML.

This clean fallback will also mean that search engine
indexing will work properly without the search engine
needing to understand ruby.

Incidentally, IE 5.5. doesn't implement simple ruby
without rb; it coalesces multiple rt's, rather than
putting the first above and second below - this does
mean it recovers from simple use of rbc and rtc
slightly better (although not well).
<RUBY> isn't valid XHTML ;-)  fixing summary
Keywords: mozilla1.0
Summary: XHTML <RUBY> support → XHTML <ruby> support
It was mentioned in mozilla i18n newsgroup that Ruby experiment as part of
context menu extension.
The url in comment 31 refers to This
implementation of Ruby is all in CSS.
Kitamura Akatsuki has given me permission by email to use his style sheet
freely. It would be great if we could get this in to mozilla 1.0. Because all it
does is add CSS styles, the risk of causing regressions is minimal.
Keywords: nsbeta1
Is our 'inline-table' code well tested?  I'm surprised we even support it.
Attached file More examples
These examples are condensed from, with
some corrections to the markup.
Attached patch Patch to html.css (obsolete) — Splinter Review
See on |inline-table|.
It's a mystery.
Thanks to Roy Yokoyama for translating the comments from the original Japanese
Attachment #78241 - Attachment is obsolete: true
Reassign to
Assignee: nhotta → smontagu
Even though this is probably not the road we want to go down for a long-term
solution, and the alignment is not perfect, especially with complex ruby, I feel
that having this support in 1.0 could have a positive effect in encouraging the
use of ruby markup in XHTML in the future.
It may be useful to attach the rendering of the examples without the CSS, to
test fallback, or to compare with other browsers.
smontagu, please ask karnaze and dbaron to review and attinasi to superreview 
the W3C specification we want to suppot is documented in

Also, Netscape should consider this low risk patch becaues the following
"Testimonials for XHTML 1.1 and Ruby Annotation" 31 May 2001

>Netscape strongly endorses the W3C Recommendation covering Ruby Annotations.
>Ruby is an important text layout feature for both East Asian language display
>and annotations in traditional documents. Netscape applauds the efforts of the
>W3C Internationalization Working Group and will help promote the use of Ruby in
>XHTML documents. Netscape will support Ruby in adherence to the W3C XHTML
>recommendation, as well as forthcoming related CSS recommendations, through the
>open-source Mozilla project and in future versions of its award-winning 
>Netscape web browser.
>-- Jim Hamerly, Vice President of Netscape Client Product Development division

Impact Platform: ALL
Impact language users: CJK users 132.8 M 23.7%
Probability of hitting the problem: LOW, this is really a feature work. The
reason we want this bug this make our story stronger in CJK market when the
press compare us with IE.
Severity if hit the problem in the worst case: Ruby text display not as it
should be shown
Way of recover after hit the problem: User will still see the content of the
ruby and ruby markup
Risk of the fix: VERY LOW. We only add new thing to html.css for NEW element/tag
Potential benefit of fix this problem: display issue on some early adopter's
test sitss. Reduce negative press in Asia. Generate good perss in Asia when we
A few questions:

Once there are correct implementations of XHTML Ruby (with line breaking, better
spacing and alignment, etc.), will proper XHTML Ruby markup gracefully degrade
better to this CSS-based implementation or to our current lack of
implementation?  That is, will this encourage or discourage use of XHTML Ruby
when better implementations become common on the web?  It would be useful to
hear from some people who read Japanese on this point.

What happens if authors apply CSS styles to ruby markup?  Will the right thing
happen, or something that could at least be categorized as "graceful
degradation", or will there be weird results that will discourage CSS styling of
ruby once better implementations exist and make ruby support less useful in the
future until Mozilla 1.0 loses all its market share?  (Consider the CSS support
in MSIE 3.x and Netscape 4.x, which prevents web authors from using many
features of CSS.)  The percentage units for 'line-height', rather than number
units, seem somewhat suspicious to me.

How well is our 'inline-table' implementation tested?  I suspect it's not tested
much, and I wonder how well it reacts to various types of incremental reflows
and dynamic style changes.  I also wonder how correct it is even in static
situations.  Could it crash?  Could it cause incorrect behavior?
rbspan is indeed very broken and I can't see a way to save it in the context of
this implementation.
I discovered that I could find more real-world examples if I searched for
"furigana" rather than "ruby".

I echo David's comment that feedback from people who read Japanese would be
very useful.
The another example from
Ouch! If that zdnet page is typical of the way <ruby> is deployed in the real
world, we are probably better off doing nothing and relying on <rp> for fallback.

(BTW, it displays well enough if I normalize the markup and produce a page that
validates as XHTML 1.1)
That looks like a way people allow it to gracefully degrade.  ruby > * {
display: none; } would probably help.  (Perhaps also rbc>* and rtc>*.)  (You'd
then have to make sure it's overridden for the appropriate things.)

The rbspan problem seems a little harder to fix, though.  We could implement
'-moz-col-span: attr(X)' to designate which attribute contains the column span
Oh, wait, I didn't notice all the improperly nested tags.  Or the fact that the
document was HTML and not XHTML...
Yes, <rp> and <rt> are never closed, and <rb> is omitted throughout. IE accepts
this, apparently.
yes, original CSS only implementation by Kitamura-san has that probrem, 
and the ContextMenu Extension by piro
use DOM to handle these well.
Keywords: nsbeta1nsbeta1+
1. please include the chinese example I mail you yesterday with screenshot. Thanks
2. please list issues one by one. Is the currently patch good eough for nsbeta1 ?
should we start ask review?
Whiteboard: [adt2]
Further to comment 50, it appears that the zdnet site and many others are
following IE's implementation of Ruby, which corresponds to an earlier version
of the W3C spec. says:

 [Ruby] can be represented using the following markup in XML-ized HTML [XHTML],   
 which is the full form:

 <ruby><rb>WWW</rb><rp>(</rp><rt>World Wide Web</rt><rp>)</rp></ruby>

 or using the following markup in SGML HTML, where it is possible to omit the end  
 tags of rb, rt and rp:

 <ruby>WWW<rp>(<rt>World Wide Web<rp>)</ruby>

The SGML HTML example disappears in later versions of the spec, but Appendix C
of the current spec refers to it:

 For historical reasons, some authoring tools might generate ruby markup without  
 the start and end tags of the rb element, like:


 rather than the following:


 The former markup is not conforming to this specification, but user agents that  
 care about compatibility with documents generated by such authoring tools may 
 treat the former markup as if it were written like the latter.
I have downloaded Piro's context-menu extensions, which include backwards
compatibility as described in the previous comment, and also better handling of
rbspan. Rather than working in parallel, I have emailed Piro suggesting that he
submit a patch.
Personally I think this is a bad idea for three reasons, first because it doesn't 
get Mozilla any closer to a real Ruby implementation (it is not a step along the 
way, it is a stop gap implementation), second because it uses very under-tested 
code and is therefore likely to be unstable (namely 'inline-table') and thirdly 
because it will require QA resources that would be better spent testing the 
table code itself or writing tests for a real Ruby implementation.

Why don't we work on a real implementation?
| The former markup is not conforming to this specification, but user agents that  
| care about compatibility with documents generated by such authoring tools may 
| treat the former markup as if it were written like the latter.

Oh, no! How can that that sort of "MAY" appear in a document that is about a
language that purports to be XML-based an therefore the document instances MUST
be well-formed?

Ruby is part of XHTML 1.1. Assuming that XHTML 1.1 shouldn't be served as
text/html, Mozilla probably shouldn't support it as text/html--at least not the
old ill-formed syntax.

I share dbaron's concern about potentially making the proper use of later
implementations more difficult if Mozilla 1.0 ships with and inline-table-based
 How would the upcoming Ruby-related CSS properties interact with an
inline-table-based UA stylesheet implementation?
Oops. I misread the tags in the "may" example. Please disregard my comment about
ok. it seems we still have a lot of debat about taking this patch. I think the
time is running out for m1.0 and it does not make sense to spend too much time
on this issue if there are a lot of issue need to be addresss. Let's defer this
issue later. Mark this bug as nsbeta1- to off radar. Let's talk about this later. 
Keywords: nsbeta1+nsbeta1-
Target Milestone: Future → mozilla1.1alpha
Due to the checkin of bug 3935 (which changed 'inline-table' to
'-moz-inline-table' since inline-table display is very poorly tested and
somewhat buggy in the tiny bit of testing it has had), any uses of 'display:
inline-table' should be changed to 'display: -moz-inline-table'.  If you want to
support both old and new versions of Mozilla, you can simply give two declarations:

  display: -moz-inline-table;
  display: inline-table;
Blocks: 157673
chang it to m1.2alpha
nsbeta1+ for m1.2final release
Keywords: nsbeta1-nsbeta1+
Target Milestone: mozilla1.1alpha → mozilla1.2alpha
Alias: ruby
Attached file CSS file
I've revised the CSS rules a bit.
-> reduced rt font-size to 55% as mentioned in the Spec
-> now vertical-align:-25% - we sit EXACTLY on the baseline with that on all
examples linked here (no, playing with the font-scale doesn't break it)
-> removed the broken rbspan="" handling

left issues:
-> vertical-align if some text below (as the date example)
-> rbspan="" (btw. it's not even possible to read the value over JS)
I've been also fooling around with an xbl version, but xbl has serious bugs with
html tables/xul grids
There is now a seperate bug to investigate the XBL version for <ruby>-support,
see bug 159855 ("investigate ruby support via xbl") ...
OS: other → All
Keywords: testcase
take out "nsbeta1+, " from this
Keywords: nsbeta1+
*** Bug 192435 has been marked as a duplicate of this bug. ***
Is it just me or is this taking a long time to add a very easy feature? Ruby can
easily be convereted to mathml. as such I am sure a bit of the math ml code can
be copied over. Now the trick is that new code would be needed for vertical
support (or so i suspect). but horizontal is easy.

    <rt rbspan="3">Expiration Date</rt>


<math xmlns="">
          <mtext>Expiration Date</mtext>

That has a few small problem though. day is higher than the others. and the text
is a little too close, but it still looks very similar to how ruby should.

so perhaps this is the better place to look into.
Testing point where you can just copy-paste a markup to see its rendering:

Seems that MathML makes it easy to abuse the markup... That markup can be
simplied to:

<math xmlns="">
        <mtext>Expiration Date</mtext> 
        <!--note that this is centered w.r.t the other <mrow> en-bloc -->

> That has a few small problem though. day is higher than the others.

That is because 'Day' has a longer "descender" than the others in the precise
glyph positioning that the MathML engine does (e.g., placing accents this way
looks better). You can correct that with what is called a \strut or \mathstruct
in the math typesetting terminology. It is an invisible box which has the
vertical dimension of a parenthesis "(", but is of zero witdh (see markup below
which emulates that).

> and the text is a little too close,

That one can be corrected with some "padding", e.g., <mpadded height="+10px">
will add 10px to the ascent. <mpadded depth="+2ex"> will add 2ex to the descent.
(In the MathML terminology, 'height' is the ascent and 'depth' is the descent.)

See the markup below which corrects the problems that you saw and beautifies the
rendering (you can play with the values in the attributes to see their effects).
This is really pure presentation. If it was MathML, it would make it hard for an
automated tool (e.g., a computer algebra system) to detect any "meaning" from
the "equation". But this does the job for you in the ruby context.

<math xmlns="">
          <mpadded depth="+.2em">
            <mphantom><mpadded width="0"><mo>(</mo></mpadded></mphantom>
          <mpadded depth="+.2em">
            <mphantom><mpadded width="0"><mo>(</mo></mpadded></mphantom>
          <mpadded depth="+.2em">
      <mpadded height="+.2em">
        <mphantom><mpadded width="0"><mo>(</mo></mpadded></mphantom>
        <mtext>Expiration Date</mtext>
*** Bug 232216 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0
Depends on: css-ruby
Blocks: xhtml2
Blocks: majorbugs
No longer blocks: majorbugs
Just in case someone stumbles in this bug and doesn't notice it, there is a
working extension for it:
*** Bug 310015 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.2alpha → Future
We cannot use any adhoc ways for this bug. We should fix bug 256274 for this. We should support the ruby layout *by* CSS.

This bug is *very* important for our marketing. But we have *more* important CJK related bugs, e.g., better IME management, better text rendering(spacing/justify problems and collapsing spacing problem for CJ). So, we cannot work on this now.

Please don't comment of the adhoc ways. And also please don't comment of the demand.
Amaya displays and allows to edit ruby annotations and I believe Internet Explorer has a support of simple annotation. I don't think other browsers support ruby annotations.

XHTML2 has a Ruby module and I read somewhere that a support is planned for HTML5.
More than planned, it's already in HTML5.
I did some research, and Ruby is a part of XHTML 1.1 (and thus subsequent versions, XHTML 2.0, and XHTML 5, which is the same as HTML5, as far as i understand)


Since is it now part of the newest W3C recommendations, I would suggest that there should be a higher priority of implementing this in the mainline.
QA Contact: moied → layout
Additionally to what is being said in comment#84, the ruby element is part of the Web Content Accessibility Guidelines (WCAG) v2.0 here:
It is recommended for chapter 3.1.6.
Keywords: access
Apparently WebKit got a basic implementation of ruby now,
Should this not block HTML5 rather than XHTML 2, since it is DOA, and XHTML 1.1 as well (if there is such a tracking bug)
Keywords: html5
The XHTML 1.1 RUBY is more complex than the HTML5 version.
<rbc> & <rtc> were not included
(In reply to comment #90)
> The XHTML 1.1 RUBY is more complex than the HTML5 version.
> <rbc> & <rtc> were not included

It probably doesn't make sense to add support for <rbc> or <rtc> at this point. It would make sense to support ruby as specced in HTML5, since that's what works in IE and now in WebKit, too.
Making this just about HTML5 ruby. XHTML ruby isn't going to happen.
No longer blocks: xhtml2
Keywords: xhtml
Summary: XHTML <ruby> support → HTML5 <ruby> support
Aaw dang! I missed the ten year anniversary of the “implement ruby” bug! I was planning to bring cake, party hats and a sad trombone :-|

I wrote some stuff on ruby if anyone’s interested:

IE 5 in 1998 then Webkit and Chrome 5 in 2010. Who’s going to be next?
HTML5 <ruby> is now a highlighted new feature of Safari 5:
Whiteboard: [adt2] → [adt2][parity-webkit][parity-IE]
Will finishing work in bug 256274 make this easy and quick to fix?
it should be easier than bug 256274.

* Implement DOM APIs for ruby related elements
* Add default style rules of ruby related elements to browser default style sheet

And if it's needed, we should check the behavior of IE when some ruby related close tags are not there (i.e., invalid document's behavior).
(In reply to comment #97)
> And if it's needed, we should check the behavior of IE when some ruby related
> close tags are not there (i.e., invalid document's behavior).

That should already be covered by the HTML5 parser, which is now on by default. You could write tests for invalid ruby and check that we're constructing the correct DOM.
Shimoda-san, do you have any advice for the invalid cases?
This is a testcase for my XHTML Ruby Support addon. There are some examples of "broken" markups.


Expected output:

Please look at some examples which are "corrected" even if they are valid as XHTML Ruby. They expected outputs are based on actual results on the Internet Explorer. I don't know details of HTML5 Ruby spec, but, I think we should not ignore those cases because there are too many ruby markups which is written only for IE, on the Web.

By the way, XHTML Ruby markups (<ruby><rb>...</rb><rp>(</rp><rt>...</rt><rp>)</rp></ruby> and complex ruby) should be in invalid cases if Mozilla supports just only HTML5 Ruby.
Odd... IE separates *ruby* box if there is rt element. We can/should not emulate this behavior. Furthermore, IE doesn't apply any style rules to rb element...

Under current spec, rb element is dropped. So, all cases aren't problem of the list without any hacks in gecko.

Thank you, Shimoda-san!
There are some code samples here that might make decent tests, including one with nested simple ruby:
@aja lol, thanks :) you can get the code used for those examples here btw:
No vertical ruby samples though — I never got to that.
Blocks: html
Are you testing IE9 parsing? Because it does not drop the <rb> element, and also the <rb> elements are styleable.
Depends on: 650616
(In reply to comment #104)
> Are you testing IE9 parsing? Because it does not drop the <rb> element, and
> also the <rb> elements are styleable.

IE9's IE9 modes cloned WebKit's old tree builder instead of implementing the spec. Not cool. Tracking changes to the parsing spec is bug 664104.
Depends on: 664104
A bunch of work fixing issues with the HTML5 ruby spec has led to:
which is probably what we should be looking at implementing.
The HTML spec's ruby model was designed with the i18n group at the W3C (in person, even), and, to my knowledge, handles every single use case ever brought up, with the simplest possible markup. It would be a huge mistake to instead implement something over-engineered like the above spec, IMHO.
For me, the suppression of rtc (XHTML 1.1) and rb elements in HTML5 is a real problem. I still use regularly. And for the moment, the only solution is CSS hacks for desired rendering.
The W3C i18n WG did discuss this with Hixie but took an action to look into things in more detail. See

Just after meeting with Hixie we put out a document that began looking at ruby use cases and discussing how the various markup models apply to each. After several iterations and a lot of discussion, we have just published the final version of that document as a WG Note, see We tried to make the HTML5 approach work for the use cases we knew to be needed, but the upshot is that in the end the extension specification at seems to us the best approach.

Earlier this year we had a workshop about internationalization and ebooks, and ruby and vertical text were ranked by attendees as two most urgent requirements needing support for their markets.  After the workshop, we had expressions of interest to implement the extension spec from Google and Safari teams. We also spoke with Microsoft, who expressed interest.

The CSS Ruby module spec was recently republished ( with changes that were designed collaboratively with the approach in the ruby extension spec. The processing and terminology are aligned so the semantics and styling match up.
The only use case the ruby-use-cases document lists as not handled by HTML is the one specifically targeting browsers that don't implement Ruby at all. Are we really going to add two whole elements and so significantly complicate the processing algorithm just to easing the short-term transition pain as we wait for implementations to appear?

(Incidentally, it looks like the markup in some of the examples is missing and has "•" instead. Is that intentional? I'm not really sure what it means, if so.)
(Note that I asked for further feedback on this very issue and never received it:

I also have already pointed out in detail why the proposed model for double-sided ruby is more complicated than the one in the HTML spec now:

Plus, the proposal of adding more elements means more churn and complexity in the parser, which is especially sad since this is only beneficial for the transitory period. It's a cost we have to pay forever, for a short-term benefit.)
Depends on: 1135306
Depends on: 1141892
Added to the release notes with "Ruby annotation support" as wording.
With a link to
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Whiteboard: [adt2][parity-webkit][parity-IE] → [adt2]
I think we can close it now.
Feel free to reopen if I am wrong.
Closed: 25 years ago6 years ago
Keywords: feature
Resolution: --- → FIXED
I checked out Ruby documentation, and it turns out we were doin g pretty well; we were just missing a page on the <rb> element. I've added this now, along with associated compat data and an interactive example:

(In reply to YUKI "Piro" Hiroshi from comment #100)

This is a testcase for my XHTML Ruby Support addon. There are some examples
of "broken" markups.

Summary: HTML5 <ruby> support → [meta] HTML5 <ruby> support
You need to log in before you can comment on or make changes to this bug.