Last Comment Bug 33339 - (ruby) HTML5 <ruby> support
: HTML5 <ruby> support
: access, dev-doc-needed, helpwanted, html5, intl, meta, testcase
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
P4 normal with 174 votes (vote)
: Future
Assigned To: Simon Montagu :smontagu
: Jet Villegas (:jet)
: 192435 232216 310015 (view as bug list)
Depends on: 39965 css-ruby 621267 650616 664104 1135306 1141892
Blocks: html5 html5test 104930 157673
  Show dependency treegraph
Reported: 2000-03-26 01:02 PST by bobj
Modified: 2016-09-30 19:37 PDT (History)
128 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Examples of ruby with CSS (2.67 KB, text/html)
2002-04-08 14:44 PDT, Simon Montagu :smontagu
no flags Details
More examples (4.33 KB, text/html)
2002-04-08 14:46 PDT, Simon Montagu :smontagu
no flags Details
Patch to html.css (1.43 KB, patch)
2002-04-08 14:53 PDT, Simon Montagu :smontagu
no flags Details | Diff | Splinter Review
New patch with comments (1.54 KB, patch)
2002-04-08 17:43 PDT, Simon Montagu :smontagu
no flags Details | Diff | Splinter Review
Attachment 78238 without the CSS (1.87 KB, text/html)
2002-04-08 19:21 PDT, Simon Montagu :smontagu
no flags Details
Attachment 78239 without the CSS (3.53 KB, text/html)
2002-04-08 19:22 PDT, Simon Montagu :smontagu
no flags Details
example showing problems with rbspan (2.15 KB, text/html)
2002-04-09 12:11 PDT, David Baron :dbaron: ⌚️UTC-8
no flags Details
More problems with rbspan (2.62 KB, text/html)
2002-04-09 15:01 PDT, Simon Montagu :smontagu
no flags Details
side-by-side screenshot from (772.94 KB, image/png)
2002-04-09 16:04 PDT, Simon Montagu :smontagu
no flags Details
CSS file (347 bytes, text/css)
2002-07-27 18:09 PDT, Kai Lahmann (is there, where MNG is)
no flags Details

Description User image bobj 2000-03-26 01:02:45 PST
Support "Ruby Annotation -- W3C Working Draft 17 December 1999" which looks
something like:
     <rp>(</rp><rt>World Wide Web</rt><rp>)</rp>
Comment 1 User image Erik van der Poel 2000-03-26 11:23:56 PST
Changed URL field to location of current official document:
Comment 2 User image Erik van der Poel 2000-03-26 11:39:11 PST
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.
Comment 3 User image rickg 2000-03-27 11:07:41 PST
Ruby is not a gecko 1.0 feature. I'll put it on the remind list in case we have 
Comment 4 User image bobj 2000-03-27 11:48:27 PST
   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.
Comment 5 User image gerardok 2000-09-06 21:22:28 PDT
massive update for QA contact.
Comment 6 User image Loco 2000-09-20 16:13:27 PDT
Taking bobj's advice and reopening to leave it on M21-sound good?  Smack me later 
if not.
Comment 7 User image rickg 2000-09-20 16:22:46 PDT
Fine. Open if you want. I'm marking it future, though, to make it clear that 
it's not a 6.0 feature.
Comment 8 User image Katsuhiko Momoi 2000-11-01 18:27:25 PST
CC'ing nhotta who is also looking into the issues surrounding ruby.
Comment 9 User image Frank Tang 2001-01-08 12:33:52 PST
nhotta- why don't you own it for now.
Comment 10 User image Hixie (not reading bugmail) 2001-01-29 10:16:04 PST
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
Comment 11 User image bsharma 2001-03-02 12:39:53 PST
qa contact updated.
Comment 12 User image bobj 2001-04-24 01:31:29 PDT
Update: On April 6, 2001: Ruby Annotation became a W3C Proposed Recommendation.
Comment 13 User image bobj 2001-04-27 11:28:42 PDT
For rendering we also need to deal with "CSS3 module: Ruby", W3C Working Draft:
Comment 14 User image bobj 2001-04-27 13:43:22 PDT
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
Comment 15 User image Erich 'Ricky' Iseli 2001-06-06 01:30:46 PDT
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.
Comment 16 User image Erich 'Ricky' Iseli 2001-06-06 05:03:51 PDT 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>
Comment 17 User image Katsuhiko Momoi 2001-06-06 14:56:40 PDT
Added ftang.
Comment 18 User image TAKAHASHI Makoto 2001-06-11 23:10:03 PDT
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.

Comment 19 User image Erich 'Ricky' Iseli 2001-06-12 03:14:01 PDT,
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.
Comment 20 User image TAKAHASHI Makoto 2001-06-12 07:10:38 PDT
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.
Comment 21 User image Erich 'Ricky' Iseli 2001-06-12 09:09:01 PDT,
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$.
Comment 22 User image bobj 2001-06-12 10:32:51 PDT
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
Comment 23 User image TAKAHASHI Makoto 2001-06-12 22:58:35 PDT
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.

Comment 24 User image Karl Ove Hufthammer 2001-06-15 04:29:33 PDT
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
Comment 25 User image bobj 2001-06-15 11:41:36 PDT
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)
Comment 26 User image Robin Lionheart 2001-08-03 07:39:13 PDT
For reference, the XHTML 1.1 spec declares its use of the Ruby Annotation module at
Comment 27 User image Heikki Toivonen (remove -bugzilla when emailing directly) 2001-09-05 10:49:50 PDT
SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.
Comment 28 User image Frank Tang 2001-10-15 15:55:43 PDT
make this a meta bug and add it to the 104930
Comment 29 User image David Woolley 2001-11-23 11:41:42 PST
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).
Comment 30 User image Aaron Kaluszka 2002-02-19 13:30:35 PST
<RUBY> isn't valid XHTML ;-)  fixing summary
Comment 31 User image nhottanscp 2002-04-02 16:51:23 PST
It was mentioned in mozilla i18n newsgroup that Ruby experiment as part of
context menu extension.
Comment 32 User image Simon Montagu :smontagu 2002-04-04 17:04:12 PST
The url in comment 31 refers to This
implementation of Ruby is all in CSS.
Comment 33 User image Simon Montagu :smontagu 2002-04-08 14:42:18 PDT
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.
Comment 34 User image Simon Montagu :smontagu 2002-04-08 14:44:12 PDT
Created attachment 78238 [details]
Examples of ruby with CSS
Comment 35 User image David Baron :dbaron: ⌚️UTC-8 2002-04-08 14:46:27 PDT
Is our 'inline-table' code well tested?  I'm surprised we even support it.
Comment 36 User image Simon Montagu :smontagu 2002-04-08 14:46:35 PDT
Created attachment 78239 [details]
More examples

These examples are condensed from, with
some corrections to the markup.
Comment 37 User image Simon Montagu :smontagu 2002-04-08 14:53:58 PDT
Created attachment 78241 [details] [diff] [review]
Patch to html.css
Comment 38 User image Simon Montagu :smontagu 2002-04-08 15:34:00 PDT
See on |inline-table|.
It's a mystery.
Comment 39 User image Simon Montagu :smontagu 2002-04-08 17:43:00 PDT
Created attachment 78269 [details] [diff] [review]
New patch with comments

Thanks to Roy Yokoyama for translating the comments from the original Japanese
Comment 40 User image nhottanscp 2002-04-08 17:50:24 PDT
Reassign to
Comment 41 User image Simon Montagu :smontagu 2002-04-08 19:15:36 PDT
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.
Comment 42 User image Simon Montagu :smontagu 2002-04-08 19:21:26 PDT
Created attachment 78279 [details]
Attachment 78238 [details] without the CSS

It may be useful to attach the rendering of the examples without the CSS, to
test fallback, or to compare with other browsers.
Comment 43 User image Simon Montagu :smontagu 2002-04-08 19:22:20 PDT
Created attachment 78280 [details]
Attachment 78239 [details] without the CSS
Comment 44 User image Frank Tang 2002-04-09 11:49:52 PDT
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
Comment 45 User image David Baron :dbaron: ⌚️UTC-8 2002-04-09 12:03:56 PDT
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?
Comment 46 User image David Baron :dbaron: ⌚️UTC-8 2002-04-09 12:11:44 PDT
Created attachment 78380 [details]
example showing problems with rbspan
Comment 47 User image Simon Montagu :smontagu 2002-04-09 15:01:55 PDT
Created attachment 78426 [details]
More problems with rbspan

rbspan is indeed very broken and I can't see a way to save it in the context of
this implementation.
Comment 48 User image Simon Montagu :smontagu 2002-04-09 16:04:01 PDT
Created attachment 78448 [details]
side-by-side screenshot from

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.
Comment 49 User image Koike Kazuhiko 2002-04-09 16:58:07 PDT
The another example from
Comment 50 User image Simon Montagu :smontagu 2002-04-09 17:57:39 PDT
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)
Comment 51 User image David Baron :dbaron: ⌚️UTC-8 2002-04-09 18:08:25 PDT
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
Comment 52 User image David Baron :dbaron: ⌚️UTC-8 2002-04-09 18:10:29 PDT
Oh, wait, I didn't notice all the improperly nested tags.  Or the fact that the
document was HTML and not XHTML...
Comment 53 User image Simon Montagu :smontagu 2002-04-09 18:20:42 PDT
Yes, <rp> and <rt> are never closed, and <rb> is omitted throughout. IE accepts
this, apparently.
Comment 54 User image Takeyori Hara 2002-04-10 06:55:11 PDT
yes, original CSS only implementation by Kitamura-san has that probrem, 
and the ContextMenu Extension by piro
use DOM to handle these well.
Comment 55 User image nhottanscp 2002-04-10 10:58:10 PDT
Comment 56 User image Frank Tang 2002-04-11 10:43:05 PDT
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?
Comment 57 User image Simon Montagu :smontagu 2002-04-11 16:07:37 PDT
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.
Comment 58 User image Simon Montagu :smontagu 2002-04-11 16:19:27 PDT
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.
Comment 59 User image Hixie (not reading bugmail) 2002-04-12 03:26:14 PDT
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?
Comment 60 User image Henri Sivonen (:hsivonen) 2002-04-12 05:01:01 PDT
| 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?
Comment 61 User image Henri Sivonen (:hsivonen) 2002-04-12 05:06:46 PDT
Oops. I misread the tags in the "may" example. Please disregard my comment about
Comment 62 User image Frank Tang 2002-04-15 12:42:58 PDT
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. 
Comment 63 User image David Baron :dbaron: ⌚️UTC-8 2002-04-30 21:29:50 PDT
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;
Comment 64 User image Frank Tang 2002-07-24 01:46:54 PDT
chang it to m1.2alpha
nsbeta1+ for m1.2final release
Comment 65 User image Kai Lahmann (is there, where MNG is) 2002-07-27 18:09:49 PDT
Created attachment 93043 [details]
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)
Comment 66 User image Doron Rosenberg (IBM) 2002-07-28 14:33:47 PDT
I've been also fooling around with an xbl version, but xbl has serious bugs with
html tables/xul grids
Comment 67 User image Roland Mainz 2002-07-28 16:44:03 PDT
There is now a seperate bug to investigate the XBL version for <ruby>-support,
see bug 159855 ("investigate ruby support via xbl") ...
Comment 68 User image Frank Tang 2003-02-07 15:09:20 PST
take out "nsbeta1+, " from this
Comment 69 User image R.K.Aa. 2003-02-08 15:18:35 PST
*** Bug 192435 has been marked as a duplicate of this bug. ***
Comment 70 User image unknown_kev_cat 2003-04-22 16:16:48 PDT
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.
Comment 71 User image rbs 2003-04-22 16:56:39 PDT
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 -->

Comment 72 User image rbs 2003-04-23 23:11:00 PDT
> 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>
Comment 73 User image Stefan [:stefanh] 2004-01-26 10:50:12 PST
*** Bug 232216 has been marked as a duplicate of this bug. ***
Comment 74 User image Lapo Luchini 2005-06-01 23:43:31 PDT
Just in case someone stumbles in this bug and doesn't notice it, there is a
working extension for it:
Comment 75 User image Phil Ringnalda (:philor) 2005-09-25 19:58:27 PDT
*** Bug 310015 has been marked as a duplicate of this bug. ***
Comment 76 User image Giovanni Glass 2005-12-21 08:42:40 PST Comment hidden (spam)
Comment 77 User image Roberto Ciang 2006-10-14 10:46:03 PDT Comment hidden (spam)
Comment 78 User image Britney 2006-10-21 07:05:00 PDT Comment hidden (spam)
Comment 79 User image Masayuki Nakano [:masayuki] 2006-10-21 07:29:08 PDT
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.
Comment 80 User image Jonathan Stewart 2009-02-25 01:32:01 PST Comment hidden (spam)
Comment 81 User image Frédéric Wang (:fredw) 2009-02-25 02:55:49 PST
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.
Comment 82 User image Hixie (not reading bugmail) 2009-02-25 03:30:07 PST
More than planned, it's already in HTML5.
Comment 83 User image Zéfling 2009-02-25 04:00:00 PST Comment hidden (spam)
Comment 84 User image Jonathan Stewart 2009-02-28 13:29:51 PST
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.
Comment 85 User image Micah Gersten 2009-06-12 02:18:02 PDT
Ubuntu bug:
Comment 86 User image Marco Zehe (:MarcoZ) 2009-10-28 01:43:57 PDT
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.
Comment 87 User image Chan Tsz Kin 2009-11-08 02:35:02 PST Comment hidden (spam)
Comment 88 User image Daniel.S 2010-01-22 08:35:52 PST
Apparently WebKit got a basic implementation of ruby now,
Comment 89 User image Lars Gunther 2010-01-22 09:27:07 PST
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)
Comment 90 User image Zéfling 2010-01-25 00:46:33 PST
The XHTML 1.1 RUBY is more complex than the HTML5 version.
<rbc> & <rtc> were not included
Comment 91 User image Henri Sivonen (:hsivonen) 2010-01-25 01:00:19 PST
(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.
Comment 92 User image Zéfling 2010-01-25 01:17:55 PST Comment hidden (spam)
Comment 93 User image :Ms2ger (⌚ UTC+1/+2) 2010-03-13 03:57:13 PST
Making this just about HTML5 ruby. XHTML ruby isn't going to happen.
Comment 94 User image Oli Studholme 2010-05-11 22:09:32 PDT
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?
Comment 95 User image Nomis101 2010-06-08 01:43:59 PDT
HTML5 <ruby> is now a highlighted new feature of Safari 5:
Comment 96 User image d 2010-07-25 04:53:20 PDT
Will finishing work in bug 256274 make this easy and quick to fix?
Comment 97 User image Masayuki Nakano [:masayuki] 2010-07-25 06:51:41 PDT
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).
Comment 98 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2010-07-25 16:55:55 PDT
(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.
Comment 99 User image Masayuki Nakano [:masayuki] 2010-07-25 19:43:02 PDT
Shimoda-san, do you have any advice for the invalid cases?
Comment 100 User image YUKI "Piro" Hiroshi 2010-07-25 20:43:50 PDT
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.
Comment 101 User image Masayuki Nakano [:masayuki] 2010-07-25 22:01:22 PDT
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!
Comment 102 User image aja+bugzilla 2010-07-28 17:29:16 PDT
There are some code samples here that might make decent tests, including one with nested simple ruby:
Comment 103 User image Oli Studholme 2010-07-28 18:51:28 PDT
@aja lol, thanks :) you can get the code used for those examples here btw:
No vertical ruby samples though — I never got to that.
Comment 104 User image fantasai 2010-09-30 23:43:52 PDT
Are you testing IE9 parsing? Because it does not drop the <rb> element, and also the <rb> elements are styleable.
Comment 105 User image Henri Sivonen (:hsivonen) 2011-06-14 04:33:18 PDT
(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.
Comment 106 User image David Baron :dbaron: ⌚️UTC-8 2013-10-09 22:48:57 PDT
A bunch of work fixing issues with the HTML5 ruby spec has led to:
which is probably what we should be looking at implementing.
Comment 107 User image Hixie (not reading bugmail) 2013-10-09 23:21:44 PDT
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.
Comment 108 User image Zéfling 2013-10-10 06:22:31 PDT
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.
Comment 109 User image Richard Ishida 2013-10-10 06:56:41 PDT
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.
Comment 110 User image Hixie (not reading bugmail) 2013-10-10 12:04:59 PDT
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.)
Comment 111 User image Hixie (not reading bugmail) 2013-10-10 12:10:43 PDT
(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.)
Comment 112 User image David 2014-07-06 11:12:55 PDT Comment hidden (abusive)
Comment 113 User image Jim Park 2014-11-05 13:24:17 PST Comment hidden (spam)
Comment 114 User image Sylvestre Ledru [:sylvestre] 2015-04-02 12:08:38 PDT
Added to the release notes with "Ruby annotation support" as wording.
With a link to

Note You need to log in before you can comment on or make changes to this bug.