33339 - (ruby) [meta] HTML5 <ruby> support

Status: RESOLVED FIXED

(Core :: Layout, defect, P4)

Description

[bobj]

Support "Ruby Annotation -- W3C Working Draft 17 December 1999" which looks
something like:
  <ruby>
     <rb>WWW</rb>
     <rp>(</rp><rt>World Wide Web</rt><rp>)</rp>
  </ruby>

Comment 1

[Erik van der Poel]

Changed URL field to location of current official document:

  http://www.w3.org/TR/ruby/

Comment 2

[Erik van der Poel]

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

[rickg]

Ruby is not a gecko 1.0 feature. I'll put it on the remind list in case we have 
time.

Comment 4

[bobj]

rickg,
   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 [e-mail]?  (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

[gerardok]

massive update for QA contact.

Comment 6

[Loco]

Taking bobj's advice and reopening to leave it on M21-sound good?  Smack me later 
if not.

Comment 7

[rickg]

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

[Katsuhiko Momoi]

CC'ing nhotta who is also looking into the issues surrounding ruby.

Comment 9

[Frank Tang]

nhotta- why don't you own it for now.

Comment 10

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 11

[bsharma]

qa contact updated.

Comment 12

[bobj]

Update: On April 6, 2001: Ruby Annotation became a W3C Proposed Recommendation.
See http://www.w3.org/TR/ruby/

Comment 13

[bobj]

For rendering we also need to deal with "CSS3 module: Ruby", W3C Working Draft:
     http://www.w3.org/TR/2001/WD-css3-ruby-20010216/

Comment 14

[bobj]

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)
      sensitive?
  - editor support (if any)
  - ruby positioning support.  See http://www.w3.org/TR/ruby/#positioning
  - font size algorithm (minimal size or something to keep it readable?)
  - default style sheet
  - backwards compatibility?  See http://www.w3.org/TR/ruby/#compatibility
  - "CSS3 module: Ruby" (http://www.w3.org/TR/ruby/) support?
     - still a working draft, but could be a ton of work to implement

Comment 15

[Erich 'Ricky' Iseli]

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

[Erich 'Ricky' Iseli]

[e-mail] 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):

<ruby>
  <rbc>
    <rb>10</rb>
    <rb>31</rb>
    <rb>2002</rb>
  </rbc>
  <rtc>
    <rt>Month</rt>
    <rt>Day</rt>
    <rt>Year</rt>
  </rtc>
  <rtc>
    <rt rbspan="3">Expiration Date</rt>
  </rtc>
</ruby>

Comment 17

[Katsuhiko Momoi]

Added ftang.

Comment 18

[TAKAHASHI Makoto]

Maybe simple ruby as below is enough.

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

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

<ruby>
    <rb>10
    <rt>Month
</ruby>
<ruby>
    <rb>31
    <rt>Day
</ruby>
<ruby>
    <rb>2002
    <rt>Year
</ruby>

Comment 19

[Erich 'Ricky' Iseli]

[e-mail],
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

[TAKAHASHI Makoto]

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

[Erich 'Ricky' Iseli]

[e-mail],
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

[bobj]

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
2001-04-27.

Comment 23

[TAKAHASHI Makoto]

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

[Karl Ove Hufthammer]

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

And Netscape has commited to supporting it <URL: 
http://www.w3.org/2001/05/xhtml-ruby-testimonial >:

"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

Comment 25

[bobj]

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

[Robin Lionheart]

For reference, the XHTML 1.1 spec declares its use of the Ruby Annotation module at http://www.w3.org/TR/2001/REC-xhtml11-20010531/doctype.html

Comment 27

[Heikki Toivonen (remove -bugzilla when emailing directly)]

SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.

Comment 28

[Frank Tang]

make this a meta bug and add it to the 104930

Comment 29

[David Woolley]

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

[Aaron Kaluszka]

<RUBY> isn't valid XHTML ;-)  fixing summary

Comment 31

[nhottanscp]

It was mentioned in mozilla i18n newsgroup that Ruby experiment as part of
context menu extension. 
http://www.cc-net.or.jp/~piro/works/moz/help-en.html

Comment 32

[Simon Montagu :smontagu]

The url in comment 31 refers to
http://www.akatsukinishisu.net/itazuragaki/2001_10.html#ruby_for_Mozilla_3. This
implementation of Ruby is all in CSS.

Comment 33

[Simon Montagu :smontagu]

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

[Simon Montagu :smontagu]

Attachment: Examples of ruby with CSS

Comment 35

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is our 'inline-table' code well tested?  I'm surprised we even support it.

Comment 36

[Simon Montagu :smontagu]

Attachment: More examples

These examples are condensed from http://dfj.cool.ne.jp/html/ruby.html, with
some corrections to the markup.

Comment 37

[Simon Montagu :smontagu]

Attachment: Patch to html.css

Comment 38

[Simon Montagu :smontagu]

See http://bugzilla.mozilla.org/show_bug.cgi?id=18217#c19 on |inline-table|.
It's a mystery.

Comment 39

[Simon Montagu :smontagu]

Attachment: New patch with comments

Thanks to Roy Yokoyama for translating the comments from the original Japanese

Comment 40

[nhottanscp]

Reassign to [e-mail].

Comment 41

[Simon Montagu :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.

Comment 42

[Simon Montagu :smontagu]

Attachment: Attachment 78238 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

[Simon Montagu :smontagu]

Attachment: Attachment 78239 without the CSS

Comment 44

[Frank Tang]

smontagu, please ask karnaze and dbaron to review and attinasi to superreview 
the W3C specification we want to suppot is documented in http://www.w3.org/TR/ruby/

Also, Netscape should consider this low risk patch becaues the following
http://www.w3.org/2001/05/xhtml-ruby-testimonial.html
"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
name. 
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
release. 

Comment 45

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: example showing problems with rbspan

Comment 47

[Simon Montagu :smontagu]

Attachment: 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

[Simon Montagu :smontagu]

Attachment: side-by-side screenshot from http://www.nicer.go.jp/cgi-bin/index_k.cgi

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

[Koike Kazuhiko]

The another example from zdnet.co.jp.
http://www.zdnet.co.jp/help/tips/html/010925ruby/index.html

Comment 50

[Simon Montagu :smontagu]

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

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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
information.

Comment 52

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Oh, wait, I didn't notice all the improperly nested tags.  Or the fact that the
document was HTML and not XHTML...

Comment 53

[Simon Montagu :smontagu]

Yes, <rp> and <rt> are never closed, and <rb> is omitted throughout. IE accepts
this, apparently.

Comment 54

[Takeyori Hara]

yes, original CSS only implementation by Kitamura-san has that probrem, 
and the ContextMenu Extension by piro
http://www.cc-net.or.jp/~piro/works/moz/help-en.html
use DOM to handle these well.

Comment 55

[nhottanscp]

nsbeta1+

Comment 56

[Frank Tang]

smontagu- 
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

[Simon Montagu :smontagu]

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. http://www.w3.org/TR/1999/WD-ruby-19990322/ 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:

 <ruby>
   A
   <rp>(</rp><rt>aaa</rt><rp>)</rp>
 </ruby>

 rather than the following:

 <ruby>
  <rb>A</rb>
  <rp>(</rp><rt>aaa</rt><rp>)</rp>
 </ruby>

 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

[Simon Montagu :smontagu]

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

[Hixie (not reading bugmail)]

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

[Henri Sivonen (:hsivonen)]

| 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
hack.
 How would the upcoming Ruby-related CSS properties interact with an
inline-table-based UA stylesheet implementation?

Comment 61

[Henri Sivonen (:hsivonen)]

Oops. I misread the tags in the "may" example. Please disregard my comment about
ill-formedness.

Comment 62

[Frank Tang]

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

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[Frank Tang]

chang it to m1.2alpha
nsbeta1+ for m1.2final release

Comment 65

[Kai Lahmann (is there, where MNG is)]

Attachment: 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

[Doron Rosenberg (IBM)]

I've been also fooling around with an xbl version, but xbl has serious bugs with
html tables/xul grids

Comment 67

[Roland Mainz]

There is now a seperate bug to investigate the XBL version for <ruby>-support,
see bug 159855 ("investigate ruby support via xbl") ...

Comment 68

[Frank Tang]

take out "nsbeta1+, " from this

Comment 69

[R.K.Aa.]

*** Bug 192435 has been marked as a duplicate of this bug. ***

Comment 70

[unknown_kev_cat]

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.

example:
Ruby:
<ruby>
  <rbc>
    <rb>10</rb>
    <rb>31</rb>
    <rb>2002</rb>
  </rbc>
  <rtc>
    <rt>Month</rt>
    <rt>Day</rt>
    <rt>Year</rt>
  </rtc>
  <rtc>
    <rt rbspan="3">Expiration Date</rt>
  </rtc>
</ruby>

Mathml:

<math xmlns="http://www.w3.org/1998/Math/MathML">
    <mrow>
      <munder>
        <mrow>
          <mover>
            <mrow><mtext>10</mtext></mrow>
            <mrow><mtext>Month</mtext></mrow>
          </mover>
          <mover>
            <mrow><mtext>31</mtext></mrow>
            <mrow><mtext>Day</mtext></mrow>
          </mover>
          <mover>
            <mrow><mtext>2002</mtext></mrow>
            <mrow><mtext>Year</mtext></mrow>
          </mover>
        </mrow>
        <mrow>
          <mtext>Expiration Date</mtext>
        </mrow>
      </munder>
    </mrow>
</math>

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

[rbs]

Testing point where you can just copy-paste a markup to see its rendering:
http://www.mozilla.org/projects/mathml/demo/tester.html

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

<math xmlns="http://www.w3.org/1998/Math/MathML">
    <mrow>
      <munder>
        <mrow>
          <mover>
            <mtext>10</mtext>
            <mtext>Month</mtext>
          </mover>
          <mover>
            <mtext>31</mtext>
            <mtext>Day</mtext>
          </mover>
          <mover>
            <mtext>2002</mtext>
            <mtext>Year</mtext>
          </mover>
        </mrow>
        <mtext>Expiration Date</mtext> 
        <!--note that this is centered w.r.t the other <mrow> en-bloc -->
      </munder>
    </mrow>
</math>

Comment 72

[rbs]

> 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="http://www.w3.org/1998/Math/MathML">
  <mrow>
    <munder>
      <mrow>
        <mover>
          <mtext>10</mtext>
          <mpadded depth="+.2em">
            <mphantom><mpadded width="0"><mo>(</mo></mpadded></mphantom>
            <mtext>Month</mtext>
          </mpadded>
        </mover>
        <mover>
          <mtext>31</mtext>
          <mpadded depth="+.2em">
            <mphantom><mpadded width="0"><mo>(</mo></mpadded></mphantom>
            <mtext>Day</mtext>
          </mpadded>
        </mover>
        <mover>
          <mtext>2002</mtext>
          <mpadded depth="+.2em">
            <mphantom><mo>(</mo></mphantom>
            <mtext>Year</mtext>
          </mpadded>
        </mover>
      </mrow>
      <mpadded height="+.2em">
        <mphantom><mpadded width="0"><mo>(</mo></mpadded></mphantom>
        <mtext>Expiration Date</mtext>
      </mpadded>
    </munder>
  </mrow>
</math>

Comment 73

[Stefan [:stefanh]]

*** Bug 232216 has been marked as a duplicate of this bug. ***

Comment 74

[Lapo Luchini]

Just in case someone stumbles in this bug and doesn't notice it, there is a
working extension for it:
http://piro.sakura.ne.jp/xul/_rubysupport.html.en

Comment 75

[Phil Ringnalda (:philor)]

*** Bug 310015 has been marked as a duplicate of this bug. ***

Comment 79

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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 81

[Frédéric Wang (:fredw)]

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

[Hixie (not reading bugmail)]

More than planned, it's already in HTML5.

Comment 84

[Jonathan Stewart]

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)

Source:
http://www.w3.org/TR/xhtml11/changes.html

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

[Micah Gersten]

Ubuntu bug:
https://bugs.launchpad.net/bugs/114441

Comment 86

[Marco Zehe (:MarcoZ)]

Additionally to what is being said in comment#84, the ruby element is part of the Web Content Accessibility Guidelines (WCAG) v2.0 here:
http://www.w3.org/TR/WCAG-TECHS/H62.html
It is recommended for chapter 3.1.6.

Comment 88

[Daniel.S]

Apparently WebKit got a basic implementation of ruby now,
see http://webkit.org/blog/948/ruby-rendering-in-webkit/

Comment 89

[Lars Gunther]

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

[Zéfling]

The XHTML 1.1 RUBY is more complex than the HTML5 version.
<rbc> & <rtc> were not included

Comment 91

[Henri Sivonen (:hsivonen)]

(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 93

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Making this just about HTML5 ruby. XHTML ruby isn't going to happen.

Comment 94

[Oli Studholme]

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:
http://html5doctor.com/ruby-rt-rp-element/

IE 5 in 1998 then Webkit and Chrome 5 in 2010. Who’s going to be next?

Comment 95

[Nomis101]

HTML5 <ruby> is now a highlighted new feature of Safari 5:
http://www.apple.com/safari/whats-new.html#html5

Comment 96

[d]

Will finishing work in bug 256274 make this easy and quick to fix?

Comment 97

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(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

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Shimoda-san, do you have any advice for the invalid cases?

Comment 100

[YUKI "Piro" Hiroshi]

This is a testcase for my XHTML Ruby Support addon. There are some examples of "broken" markups.
http://www.cozmixng.org/repos/piro/rubysupport/trunk/tests/general.html

Input:
<p>1.<ruby>base<rb></rb><rt>rubytext</rt></ruby>
<p>2.<ruby><rb></rb>base<rt></rt>base2</ruby>
<p>3.<ruby>base<rb>base2</rb><rt></rt>base3</ruby>
<p>4.<ruby>base<rb>base2</rb><rt>rubytext</rt>base3</ruby>
<p>5.<ruby><rb>base</rb>base2<rt></rt>base3</ruby>
<p>6.<ruby><rb>base</rb>base2<rt>rubytext</rt>base3</ruby>
<p>7.<ruby>base<rb><rt>rubytextrubytextrubytext</rt>base2</ruby>
<p>8.<ruby><rb>base</rb><rt>rubytext</rt><rb>base2</rb><rt>rubytext2rubytext2rubytext2</rt></ruby>
<p>9.<ruby>base</ruby><ruby><rb>base2</rb></ruby>base3
<p>10.
	<ruby>base<rb></rb><rt>rubytext</rt></ruby>
	<ruby><rb></rb>base<rt></rt>rubytext</ruby>
	<ruby><rb>base</rb><rt>rubytext</rt><rb>base</rb><rt>rubytext</rt></ruby>
</p>

Expected output:
<p>1.<ruby><rb>base</rb><rt>rubytext</rt></ruby>
<p>2.basebase2
<p>3.basebase2base3
<p>4.<ruby><rb>basebase2</rb><rt>rubytext</rt></ruby>base3
<p>5.basebase2base3
<p>6.<ruby><rb>basebase2</rb><rt>rubytext</rt></ruby>base3
<p>7.<ruby><rb>base</rb><rt>rubytextrubytextrubytext</rt></ruby>base2
<p>8.<ruby><rb>base</rb><rt>rubytext</rt></ruby><ruby><rb>base2</rb><rt>rubytext2rubytext2rubytext2</rt></ruby>
<p>9.basebase2base3
<p>10.
	<ruby><rb>base</rb><rt>rubytext</rt></ruby>
	<ruby><rb>baserubytext</rb></ruby>
	<ruby><rb>base</rb><rt>rubytext</rt></ruby><ruby><rb>base</rb><rt>rubytext</rt></ruby>
</p>

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

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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

[aja+bugzilla]

There are some code samples here that might make decent tests, including one with nested simple ruby: 
http://html5doctor.com/ruby-rt-rp-element/

Comment 103

[Oli Studholme]

@aja lol, thanks :) you can get the code used for those examples here btw: http://oli.jp/example/ruby/
No vertical ruby samples though — I never got to that.

Comment 104

[fantasai]

Are you testing IE9 parsing? Because it does not drop the <rb> element, and also the <rb> elements are styleable.

Comment 105

[Henri Sivonen (:hsivonen)]

(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

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

A bunch of work fixing issues with the HTML5 ruby spec has led to:
  http://lists.w3.org/Archives/Public/public-html/2013Oct/0015.html
  http://darobin.github.io/html-ruby/
which is probably what we should be looking at implementing.

Comment 107

[Hixie (not reading bugmail)]

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

[Zéfling]

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

[Richard Ishida]

The W3C i18n WG did discuss this with Hixie but took an action to look into things in more detail. See
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10830#c59
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10830#c75

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 http://www.w3.org/TR/ruby-use-cases/. 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 http://darobin.github.io/html-ruby/ 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 (http://www.w3.org/TR/css3-ruby/) 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

[Hixie (not reading bugmail)]

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

[Hixie (not reading bugmail)]

(Note that I asked for further feedback on this very issue and never received it:
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=20114#c9

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:
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=20115#c6

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

[David]

This is INSANE!! I think calling this a "bug" since late-1999/early-2000 is a complete misnomer: this is simply a part of the HTML5 specification that Mozilla has deemed "ignorable." (Though I have a feeling that if the majority of Mozilla Devs. read Asian text with any frequency, suddenly it would be implemented…)

Why the Ruby tag got the shaft for support is beyond me, but it seems the developers don't want to implement it because it's too "complicated" and would require extra processing time. Well, either put forth the effort and implement it as efficiently as possible, or just admit that Mozilla has no plans to ever implement this part of the HTML5 specs because they're an American-based (read: English-speaking) company which sees no immediate need for Ruby text. This is exactly why IE dominates China: they can actually read their text reliably on the browser!!

Comment 114

[Sylvestre Ledru [:Sylvestre]]

Added to the release notes with "Ruby annotation support" as wording.
With a link to https://hacks.mozilla.org/2015/03/ruby-support-in-firefox-developer-edition-38/

Comment 115

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 116

[Sylvestre Ledru [:Sylvestre]]

I think we can close it now.
Feel free to reopen if I am wrong.

Comment 117

[Chris Mills [:cmills]]

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:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/rb
https://github.com/mdn/browser-compat-data/pull/2422
https://github.com/mdn/interactive-examples/pull/1016

Comment 118

[Gérard Talbot]

(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.
http://www.cozmixng.org/repos/piro/rubysupport/trunk/tests/general.html

http://www.gtalbot.org/BrowserBugsSection/CSS3Ruby/yuki-hiroshi-example.xhtml