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>
Changed URL field to location of current official document: http://www.w3.org/TR/ruby/
Adding Roger Sidje to Cc list. In some ways, Ruby is similar to some of the things that MathML requires. In Ruby, the main text is in one normal size, and the Ruby text is smaller and drawn above or below the main text (in the horizontal case; left or right in the vertical case). In math, we also have superscripts and subscripts, and various things drawn at various sizes above and below other things, and so on. It is quite possible that Roger and the other MathML folks could have some good ideas for Ruby too, or perhaps whoever implements Ruby could get some ideas from the MathML code. Then again, Ruby is simpler, and is somewhat similar to a plain table, so perhaps we don't need anything as complicated as MathML's implementation.
Ruby is not a gecko 1.0 feature. I'll put it on the remind list in case we have time.
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 nobody@mozilla.org? (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.
massive update for QA contact.
Taking bobj's advice and reopening to leave it on M21-sound good? Smack me later if not.
Fine. Open if you want. I'm marking it future, though, to make it clear that it's not a 6.0 feature.
CC'ing nhotta who is also looking into the issues surrounding ruby.
nhotta- why don't you own it for now.
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
qa contact updated.
Update: On April 6, 2001: Ruby Annotation became a W3C Proposed Recommendation. See http://www.w3.org/TR/ruby/
For rendering we also need to deal with "CSS3 module: Ruby", W3C Working Draft: http://www.w3.org/TR/2001/WD-css3-ruby-20010216/
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
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.
bobj@netscape.com 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>
Added ftang.
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>
hobbit.makoto@nifty.ne.jp, I don't think it would be "enough". Because this takes away a lot of the ruby feature. And your example isn't quite the same like the one above: where would you put (and how?) "Expiration Date"? You can't make it span 3 ruby elements. As mentioned already, supporting ruby should not be that hard since it is working like mathML is working. And if we support simple ruby, then I guess it would be silly to not support the complex one as well.
If you can support full specification of <ruby> as early as IE spec, I would like to say nothing. But I saw such complex ruby only in the recommendation. Do you saw such example??? Please show the example other tahn the recommendation. I think engineering sense of IE is good.
hobbit.makoto@nifty.ne.jp, I haven't seen ruby anywhere. But there is an obvious reason for it: if you have no browser supporting it, why would you use it anyways? The first step is on the browser's side to support it, then the webmasters will start to use it. Only then. And of course, while it was only a proposed recommendation, developpers wouldn't care of it. Now that it is part of the new XHTML 1.1 spec, now it will catch a broader audience. My 0.02$.
My philosophy is that we should design to support Ruby "fully". When we implement, we can choose to phase in the work (e.g., first support "simple" Ruby). But understanding the design for "full" support will influence how we implement the first phase, and hopefully prevent us from going down too many wrong paths that might give us headaches in the next phase. WG3 stuff specifies the technology level, but we also need to specify the application requirements and features. For some ideas, see my comment from 2001-04-27.
Ruby was not made for HTML. Ruby has long history in printings in Japan. I said that I did not see an example of complex ruby in books and magazines of paper.
Note that ruby is now part of the offical XHTML 1.1 rec. And Netscape has commited to supporting it <URL: 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
Wow, people actually read those testimonials. :-) Unfortunately, Ruby won't make it for Mozilla 1.0. or the impending Netscape 6.1 release. Netscape is sincere in what we wrote, and intend to get really moving on this after we complete our near-term priorities. But we'll also take any help we can get from other Mozilla developers! -Bob (testimonial ghost writer)
For reference, the XHTML 1.1 spec declares its use of the Ruby Annotation module at http://www.w3.org/TR/2001/REC-xhtml11-20010531/doctype.html
SPAM. HTML Element component deprecated, changing component to Layout. See bug 88132 for details.
make this a meta bug and add it to the 104930
Re Comment #16 ] Becaouse rbc and rtc gives no additional feature to represent ruby. ] For example above, I would like to write as below. The feature they give is clean fallback to non-ruby browsers, although the existence of the pre-simple ruby in IE5.5, confuses the issue. With rbc and rtc you can arrange for the base text and annotation to interleave on a line by line basis, not just a word by word basis (more accurately, paragraph by paragraph, for good XHTML. This clean fallback will also mean that search engine indexing will work properly without the search engine needing to understand ruby. Incidentally, IE 5.5. doesn't implement simple ruby without rb; it coalesces multiple rt's, rather than putting the first above and second below - this does mean it recovers from simple use of rbc and rtc slightly better (although not well).
<RUBY> isn't valid XHTML ;-) fixing summary
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
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.
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.
Created attachment 78238 [details] Examples of ruby with CSS
Is our 'inline-table' code well tested? I'm surprised we even support it.
Created attachment 78239 [details] More examples These examples are condensed from http://dfj.cool.ne.jp/html/ruby.html, with some corrections to the markup.
Created attachment 78241 [details] [diff] [review] Patch to html.css
See http://bugzilla.mozilla.org/show_bug.cgi?id=18217#c19 on |inline-table|. It's a mystery.
Created attachment 78269 [details] [diff] [review] New patch with comments Thanks to Roy Yokoyama for translating the comments from the original Japanese
Reassign to smontagu@netscape.com.
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.
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.
Created attachment 78280 [details] Attachment 78239 [details] without the CSS
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.
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?
Created attachment 78380 [details] example showing problems with rbspan
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.
Created attachment 78448 [details] 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.
The another example from zdnet.co.jp. http://www.zdnet.co.jp/help/tips/html/010925ruby/index.html
Ouch! If that zdnet page is typical of the way <ruby> is deployed in the real world, we are probably better off doing nothing and relying on <rp> for fallback. (BTW, it displays well enough if I normalize the markup and produce a page that validates as XHTML 1.1)
That looks like a way people allow it to gracefully degrade. ruby > * { display: none; } would probably help. (Perhaps also rbc>* and rtc>*.) (You'd then have to make sure it's overridden for the appropriate things.) The rbspan problem seems a little harder to fix, though. We could implement '-moz-col-span: attr(X)' to designate which attribute contains the column span information.
Oh, wait, I didn't notice all the improperly nested tags. Or the fact that the document was HTML and not XHTML...
Yes, <rp> and <rt> are never closed, and <rb> is omitted throughout. IE accepts this, apparently.
yes, original CSS only implementation by Kitamura-san has that probrem, and the ContextMenu Extension by piro http://www.cc-net.or.jp/~piro/works/moz/help-en.html use DOM to handle these well.
nsbeta1+
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?
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.
I have downloaded Piro's context-menu extensions, which include backwards compatibility as described in the previous comment, and also better handling of rbspan. Rather than working in parallel, I have emailed Piro suggesting that he submit a patch.
Personally I think this is a bad idea for three reasons, first because it doesn't get Mozilla any closer to a real Ruby implementation (it is not a step along the way, it is a stop gap implementation), second because it uses very under-tested code and is therefore likely to be unstable (namely 'inline-table') and thirdly because it will require QA resources that would be better spent testing the table code itself or writing tests for a real Ruby implementation. Why don't we work on a real implementation?
| The former markup is not conforming to this specification, but user agents that | care about compatibility with documents generated by such authoring tools may | treat the former markup as if it were written like the latter. Oh, no! How can that that sort of "MAY" appear in a document that is about a language that purports to be XML-based an therefore the document instances MUST be well-formed? Ruby is part of XHTML 1.1. Assuming that XHTML 1.1 shouldn't be served as text/html, Mozilla probably shouldn't support it as text/html--at least not the old ill-formed syntax. I share dbaron's concern about potentially making the proper use of later implementations more difficult if Mozilla 1.0 ships with and inline-table-based hack. How would the upcoming Ruby-related CSS properties interact with an inline-table-based UA stylesheet implementation?
Oops. I misread the tags in the "may" example. Please disregard my comment about ill-formedness.
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.
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;
chang it to m1.2alpha nsbeta1+ for m1.2final release
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)
I've been also fooling around with an xbl version, but xbl has serious bugs with html tables/xul grids
There is now a seperate bug to investigate the XBL version for <ruby>-support, see bug 159855 ("investigate ruby support via xbl") ...
take out "nsbeta1+, " from this
*** Bug 192435 has been marked as a duplicate of this bug. ***
Is it just me or is this taking a long time to add a very easy feature? Ruby can easily be convereted to mathml. as such I am sure a bit of the math ml code can be copied over. Now the trick is that new code would be needed for vertical support (or so i suspect). but horizontal is easy. 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.
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>
> 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>
*** Bug 232216 has been marked as a duplicate of this bug. ***
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
*** Bug 310015 has been marked as a duplicate of this bug. ***
The target milestone needs to change to future.
Come on, it would be great for Gecko to be the first rendering engine to fully support this spec. Many people can be benefited if ruby annotation is supported by browsers. This can change the web text for millions of Chinese, Japanese, and Korean people. I wish someone could try to implement this into Gecko as soon as possible~
(In reply to comment #0) > 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> This seems like a nasty bug any idea on when it might be avaiable for Gecko because Roberto is right it would help millions of people whn it does get fixed I hope the post from the W3 blog finds someone with a fix http://www.w3.org/QA/2006/02/ruby_annotation_to_change_the.html http://www.britneysimpson.com
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.
I just discovered Ruby annotation, and then discovered FF 3.0.6 (current stable) does not support it. I also found this add-on: https://addons.mozilla.org/en-US/firefox/addon/1935 This add-on appears to implement ruby, though with what robustness or completeness i do not know. Does anyone know what the current thinking on ruby support is? Why isn't it mainline, it is an official W3C recommendation, since 2001, as found: http://www.w3.org/TR/2001/REC-ruby-20010531/
Amaya displays and allows to edit ruby annotations and I believe Internet Explorer has a support of simple annotation. I don't think other browsers support ruby annotations. XHTML2 has a Ruby module and I read somewhere that a support is planned for HTML5.
More than planned, it's already in HTML5.
But it's also in XHTML 1.1.
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.
Ubuntu bug: https://bugs.launchpad.net/bugs/114441
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.
Why Firefox does not imply the W3C standard?!
Apparently WebKit got a basic implementation of ruby now, see http://webkit.org/blog/948/ruby-rendering-in-webkit/
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)
The XHTML 1.1 RUBY is more complex than the HTML5 version. <rbc> & <rtc> were not included
(In reply to comment #90) > The XHTML 1.1 RUBY is more complex than the HTML5 version. > <rbc> & <rtc> were not included It probably doesn't make sense to add support for <rbc> or <rtc> at this point. It would make sense to support ruby as specced in HTML5, since that's what works in IE and now in WebKit, too.
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.
Making this just about HTML5 ruby. XHTML ruby isn't going to happen.
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?
HTML5 <ruby> is now a highlighted new feature of Safari 5: http://www.apple.com/safari/whats-new.html#html5
Will finishing work in bug 256274 make this easy and quick to fix?
it should be easier than bug 256274. * Implement DOM APIs for ruby related elements * Add default style rules of ruby related elements to browser default style sheet And if it's needed, we should check the behavior of IE when some ruby related close tags are not there (i.e., invalid document's behavior).
(In reply to comment #97) > And if it's needed, we should check the behavior of IE when some ruby related > close tags are not there (i.e., invalid document's behavior). That should already be covered by the HTML5 parser, which is now on by default. You could write tests for invalid ruby and check that we're constructing the correct DOM.
Shimoda-san, do you have any advice for the invalid cases?
This is a testcase for my XHTML Ruby Support addon. There are some examples of "broken" markups. 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.
Odd... IE separates *ruby* box if there is rt element. We can/should not emulate this behavior. Furthermore, IE doesn't apply any style rules to rb element... Under current spec, rb element is dropped. So, all cases aren't problem of the list without any hacks in gecko. Thank you, Shimoda-san!
There are some code samples here that might make decent tests, including one with nested simple ruby: http://html5doctor.com/ruby-rt-rp-element/
@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.
Are you testing IE9 parsing? Because it does not drop the <rb> element, and also the <rb> elements are styleable.
(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.
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.
The HTML spec's ruby model was designed with the i18n group at the W3C (in person, even), and, to my knowledge, handles every single use case ever brought up, with the simplest possible markup. It would be a huge mistake to instead implement something over-engineered like the above spec, IMHO.
For me, the suppression of rtc (XHTML 1.1) and rb elements in HTML5 is a real problem. I still use regularly. And for the moment, the only solution is CSS hacks for desired rendering.
The W3C i18n WG did discuss this with Hixie but took an action to look into things in more detail. See 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.
The only use case the ruby-use-cases document lists as not handled by HTML is the one specifically targeting browsers that don't implement Ruby at all. Are we really going to add two whole elements and so significantly complicate the processing algorithm just to easing the short-term transition pain as we wait for implementations to appear? (Incidentally, it looks like the markup in some of the examples is missing and has "•" instead. Is that intentional? I'm not really sure what it means, if so.)
(Note that I asked for further feedback on this very issue and never received it: 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.)
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!!
Please consider supporting ruby tags soon. Firefox is the only major browser that does not support ruby tags.
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/
or
