Gecko Engine does not support the XHTML 1.1 ruby tag

[Terry 'Mongoose' Hendrix]

Binary package hint: epiphany-browser

Visit a website such as http://icculus.org/~mongoose/index-jp2.html -- notice Ruby tags are ignored. This works in IE and can work with a plugin in firefox ( http://piro.sakura.ne.jp/xul/_rubysupport.html.en ). Ruby is part of the XHTML 1.1 standard.

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

ProblemType: Bug
Architecture: amd64
Date: Sun May 13 11:42:29 2007
DistroRelease: Ubuntu 7.04
ExecutablePath: /usr/bin/epiphany
Package: epiphany-browser 2.18.1-0ubuntu1
PackageArchitecture: amd64
ProcCmdline: /usr/bin/epiphany
ProcCwd: /home/mongoose
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: epiphany-browser
Uname: Linux namie 2.6.20-14-generic #2 SMP Thu Apr 12 22:25:02 UTC 2007 x86_64 GNU/Linux

[L. David Baron (dbaron)]

I would think an 'inline-table' would act like an inline replaced element, but
this isn't completely clear from the spec. Should it instead have a baseline?
If so, where?

[Ian-hixie (ian-hixie)]

I think the closest the spec gets to helping us is:

# inline-table (In HTML: TABLE)
# Specifies that an element defines an inline-level table: it is a
# rectangular block that participates in an inline formatting context).

Personally, I would say render it like an inline-block -- unfortunately, the
CSS3 UI spec is just as vague as CSS2's inline-table definition on this issue!
David, I suggest one of us posts about this to www-style.

In the meantime, however, I think we should assume that inline-table is just
a replaced element as far as the line formatting model rules are concerned.

[Ian-hixie (ian-hixie)]

Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

[Pierre-formerly-netscape (pierre-formerly-netscape)]

IMPORTANT: Like 'compact', 'run-in' and 'marker', a declaration containing
'display:inline-table' is now entirely ignored by the CSS parser. See bug 18218
and bug 15432 for more info.

If you are planning to implement 'inline-table', you will have to re-enable the
declaration in nsCSSParser.cpp. If you have no plans to implement it for this
release, you may want to mark the bug "Later" like the other ones.

[Bobj (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>

[Erik-vanderpoel (erik-vanderpoel)]

Changed URL field to location of current official document:

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

[Erik-vanderpoel (erik-vanderpoel)]

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.

[Rickg-formerly-netscape (rickg-formerly-netscape)]

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

[Bobj (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 <email address hidden>? (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.

[Karnaze (karnaze)]

I'm chaning the summary from "display: inline-table makes contents dissappear"
to "display: inline-table not implemented and marking "remind". The contents are
not disappearing for the reasons Pierre mentions.

[Gerardok (gerardok)]

massive update for QA contact.

[Ian-hixie (ian-hixie)]

Reopening and moving to Future to keep this bug on our "potential dups" radar.

[Bugzillaabuse (bugzillaabuse)]

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

[Rickg-formerly-netscape (rickg-formerly-netscape)]

Fine. Open if you want. I'm marking it future, though, to make it clear that
it's not a 6.0 feature.

[Ian-hixie (ian-hixie)]

Taking QA per managerial policy.

[Ian-hixie (ian-hixie)]

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

[Momoi (momoi)]

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

[Bernd (bernd-mozilla)]

Ian, your testcase gives a 404. Could you attach the testcase to the bug.

[Ian-hixie (ian-hixie)]

It's temporary, the university is upgrading their UPS or something...
If you need the testcase Right Now give me a yell and I'll throw it up on
damowmow.com or hixie.ch somewhere.

[Ftang (ftang)]

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

[Ian-hixie (ian-hixie)]

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

[Djw (djw)]

As far as I can tell, there is no way of imitating <table align="center"> in
CSS2/HTML 4 strict, without using display: inline-table on the table element,
as table is treated as a block element and there appears no way to centre block
elements other than by setting percentage widths and margins. See:
<http://lists.w3.org/Archives/Public/www-style/2001Feb/0082.html>

[L. David Baron (dbaron)]

margin-left: auto; margin-right: auto;

[Chrispetersen (chrispetersen)]

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

[Bsharma (bsharma)]

qa contact updated.

[Cmattar (cmattar)]

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

[Bobj (bobj)]

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

[Bobj (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/

[Bobj (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

[C-c07 (c-c07)]

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

[Erich (eiseli)]

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.

[Erich (eiseli)]

<email address hidden> 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>

[Momoi (momoi)]

Added ftang.

[Hobbit-mak (hobbit-mak)]

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>

[Erich (eiseli)]

<email address hidden>,
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.

[Hobbit-mak (hobbit-mak)]

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.

[Erich (eiseli)]

<email address hidden>,
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$.

[Bobj (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.

[Fred-wang (fred-wang)]

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.

[Ian-hixie (ian-hixie)]

More than planned, it's already in HTML5.

[Zéfling (zefling)]

But it's also in XHTML 1.1.

[Jonathan Stewart (reaper-fudo)]

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.

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

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

[Micah Gersten (micahg)]

Moving to 3.5 as that's the next likely milestone for this.

[Marco-zehe (marco-zehe)]

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.

[Tszkin-chan (tszkin-chan)]

Why Firefox does not imply the W3C standard?!

[Crazy-daniel (crazy-daniel)]

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

[Webmaster-keryx (webmaster-keryx)]

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)

[Zéfling (zefling)]

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

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

[Zéfling (zefling)]

I use they in XHTML 1.1 whit CSS hack for Firefox.(In reply to comment #91)
> 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.
I use them in XHTML 1.1 with a CSS hack.
But the hack is not perfect.

[Ms2ger (ms2ger)]

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

[Mozilla-org-boblet (mozilla-org-boblet)]

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?

[Nomis101 (nomis101)]

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

[Bugzilla-zirro (bugzilla-zirro)]

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

[Masayuki (masayuki)]

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

[Roc-ocallahan (roc-ocallahan)]

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

[Masayuki (masayuki)]

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

[Shimoda (shimoda)]

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.

[Masayuki (masayuki)]

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!

[Aja+bugzilla (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/

[Mozilla-org-boblet (mozilla-org-boblet)]

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

[fantasai (fantasai)]

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

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

[L. David Baron (dbaron)]

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.

[Ian-hixie (ian-hixie)]

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.

[Zefling-r (zefling-r)]

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.

[Ishida-8 (ishida-8)]

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.

[Ian-hixie (ian-hixie)]

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

[Ian-hixie (ian-hixie)]

(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.)

[David-kostyk (david-kostyk)]

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

[Jim Park (jim-scratchpaper)]

Please consider supporting ruby tags soon. Firefox is the only major browser that does not support ruby tags.

[Sledru (sledru)]

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/

[Jonathan Watt (jwatt)]

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

[Sledru (sledru)]

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

[Cmills-4 (cmills-4)]

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

[Paul White (paulw2u)]

Upstream bug showing "RESOLVED FIXED" on 2018-05-31
Included in Firefox Dev 38 - see comment #159
Marking "Fix Released" to close

[Bugzilla-gtalbot (bugzilla-gtalbot)]

(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