Closed
Bug 33339
(ruby)
Opened 24 years ago
Closed 5 years ago
[meta] HTML5 <ruby> support
Categories
(Core :: Layout, defect, P4)
Core
Layout
Tracking
()
RESOLVED
FIXED
Future
Tracking | Status | |
---|---|---|
relnote-firefox | --- | 38+ |
People
(Reporter: bobj, Assigned: smontagu)
References
(Depends on 2 open bugs, Blocks 1 open bug, )
Details
(10 keywords, Whiteboard: [adt2])
Attachments
(9 files, 1 obsolete file)
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•24 years ago
|
||
Changed URL field to location of current official document: http://www.w3.org/TR/ruby/
Comment 2•24 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → REMIND
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.
Keywords: helpwanted
Updated•24 years ago
|
Summary: HTML <RUBY> support → XHTML <RUBY> support
Taking bobj's advice and reopening to leave it on M21-sound good? Smack me later if not.
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
Target Milestone: --- → M21
Fine. Open if you want. I'm marking it future, though, to make it clear that it's not a 6.0 feature.
Status: REOPENED → ASSIGNED
Priority: P3 → P4
Target Milestone: M21 → Future
Comment 8•23 years ago
|
||
CC'ing nhotta who is also looking into the issues surrounding ruby.
Updated•23 years ago
|
Assignee: rickg → nhotta
Status: ASSIGNED → NEW
Comment 9•23 years ago
|
||
nhotta- why don't you own it for now.
Updated•23 years ago
|
Status: NEW → ASSIGNED
Comment 10•23 years ago
|
||
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
Reporter | ||
Comment 12•23 years ago
|
||
Update: On April 6, 2001: Ruby Annotation became a W3C Proposed Recommendation. See http://www.w3.org/TR/ruby/
Reporter | ||
Comment 13•23 years ago
|
||
For rendering we also need to deal with "CSS3 module: Ruby", W3C Working Draft: http://www.w3.org/TR/2001/WD-css3-ruby-20010216/
Reporter | ||
Comment 14•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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>
Comment 17•23 years ago
|
||
Added ftang.
Comment 18•23 years ago
|
||
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•23 years ago
|
||
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.
Comment 20•23 years ago
|
||
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•23 years ago
|
||
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$.
Reporter | ||
Comment 22•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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
Reporter | ||
Comment 25•23 years ago
|
||
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•23 years ago
|
||
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
Updated•22 years ago
|
Component: HTML Element → Layout
SPAM. HTML Element component deprecated, changing component to Layout. See bug 88132 for details.
Comment 28•22 years ago
|
||
make this a meta bug and add it to the 104930
Comment 29•22 years ago
|
||
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•22 years ago
|
||
<RUBY> isn't valid XHTML ;-) fixing summary
Keywords: mozilla1.0
Summary: XHTML <RUBY> support → XHTML <ruby> support
Comment 31•22 years ago
|
||
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
Assignee | ||
Comment 32•22 years ago
|
||
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.
Assignee | ||
Comment 33•22 years ago
|
||
Kitamura Akatsuki has given me permission by email to use his style sheet freely. It would be great if we could get this in to mozilla 1.0. Because all it does is add CSS styles, the risk of causing regressions is minimal.
Keywords: nsbeta1
Assignee | ||
Comment 34•22 years ago
|
||
Comment 35•22 years ago
|
||
Is our 'inline-table' code well tested? I'm surprised we even support it.
Assignee | ||
Comment 36•22 years ago
|
||
These examples are condensed from http://dfj.cool.ne.jp/html/ruby.html, with some corrections to the markup.
Assignee | ||
Comment 37•22 years ago
|
||
Assignee | ||
Comment 38•22 years ago
|
||
See http://bugzilla.mozilla.org/show_bug.cgi?id=18217#c19 on |inline-table|. It's a mystery.
Assignee | ||
Comment 39•22 years ago
|
||
Thanks to Roy Yokoyama for translating the comments from the original Japanese
Attachment #78241 -
Attachment is obsolete: true
Comment 40•22 years ago
|
||
Reassign to smontagu@netscape.com.
Assignee: nhotta → smontagu
Status: ASSIGNED → NEW
Assignee | ||
Comment 41•22 years ago
|
||
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.
Status: NEW → ASSIGNED
Assignee | ||
Comment 42•22 years ago
|
||
It may be useful to attach the rendering of the examples without the CSS, to test fallback, or to compare with other browsers.
Assignee | ||
Comment 43•22 years ago
|
||
Comment 44•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
Assignee | ||
Comment 47•22 years ago
|
||
rbspan is indeed very broken and I can't see a way to save it in the context of this implementation.
Assignee | ||
Comment 48•22 years ago
|
||
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•22 years ago
|
||
The another example from zdnet.co.jp. http://www.zdnet.co.jp/help/tips/html/010925ruby/index.html
Assignee | ||
Comment 50•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
Oh, wait, I didn't notice all the improperly nested tags. Or the fact that the document was HTML and not XHTML...
Assignee | ||
Comment 53•22 years ago
|
||
Yes, <rp> and <rt> are never closed, and <rb> is omitted throughout. IE accepts this, apparently.
Comment 54•22 years ago
|
||
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 56•22 years ago
|
||
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?
Updated•22 years ago
|
Whiteboard: [adt2]
Assignee | ||
Comment 57•22 years ago
|
||
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.
Assignee | ||
Comment 58•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
| 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•22 years ago
|
||
Oops. I misread the tags in the "may" example. Please disregard my comment about ill-formedness.
Comment 62•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
chang it to m1.2alpha nsbeta1+ for m1.2final release
Updated•22 years ago
|
Alias: ruby
Comment 65•22 years ago
|
||
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•22 years ago
|
||
I've been also fooling around with an xbl version, but xbl has serious bugs with html tables/xul grids
Comment 67•22 years ago
|
||
There is now a seperate bug to investigate the XBL version for <ruby>-support, see bug 159855 ("investigate ruby support via xbl") ...
Comment 69•21 years ago
|
||
*** Bug 192435 has been marked as a duplicate of this bug. ***
Comment 70•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
> 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•20 years ago
|
||
*** Bug 232216 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Keywords: mozilla1.0
Comment 74•19 years ago
|
||
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•18 years ago
|
||
*** Bug 310015 has been marked as a duplicate of this bug. ***
Comment hidden (spam) |
Updated•18 years ago
|
Target Milestone: mozilla1.2alpha → Future
Comment hidden (spam) |
Comment hidden (spam) |
Comment 79•17 years ago
|
||
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 hidden (spam) |
Comment 81•15 years ago
|
||
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•15 years ago
|
||
More than planned, it's already in HTML5.
Comment hidden (spam) |
Comment 84•15 years ago
|
||
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•15 years ago
|
||
Ubuntu bug: https://bugs.launchpad.net/bugs/114441
Updated•14 years ago
|
QA Contact: moied → layout
Comment 86•14 years ago
|
||
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.
Keywords: access
Comment hidden (spam) |
Comment 88•14 years ago
|
||
Apparently WebKit got a basic implementation of ruby now, see http://webkit.org/blog/948/ruby-rendering-in-webkit/
Comment 89•14 years ago
|
||
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•14 years ago
|
||
The XHTML 1.1 RUBY is more complex than the HTML5 version. <rbc> & <rtc> were not included
Comment 91•14 years ago
|
||
(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 hidden (spam) |
See Also: → https://launchpad.net/bugs/114441
Comment 93•14 years ago
|
||
Making this just about HTML5 ruby. XHTML ruby isn't going to happen.
Comment 94•14 years ago
|
||
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•14 years ago
|
||
HTML5 <ruby> is now a highlighted new feature of Safari 5: http://www.apple.com/safari/whats-new.html#html5
Updated•14 years ago
|
Whiteboard: [adt2] → [adt2][parity-webkit][parity-IE]
Comment 96•13 years ago
|
||
Will finishing work in bug 256274 make this easy and quick to fix?
Comment 97•13 years ago
|
||
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.
Comment 99•13 years ago
|
||
Shimoda-san, do you have any advice for the invalid cases?
Comment 100•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
@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•13 years ago
|
||
Are you testing IE9 parsing? Because it does not drop the <rb> element, and also the <rb> elements are styleable.
Comment 105•13 years ago
|
||
(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•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
(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 hidden (abuse-reviewed) |
Updated•9 years ago
|
Keywords: dev-doc-needed
Comment hidden (spam) |
Comment 114•9 years ago
|
||
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/
relnote-firefox:
--- → 38+
![]() |
||
Comment 115•6 years ago
|
||
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-ie,
parity-safari
Whiteboard: [adt2][parity-webkit][parity-IE] → [adt2]
Comment 116•5 years ago
|
||
I think we can close it now. Feel free to reopen if I am wrong.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 5 years ago
Keywords: feature
Resolution: --- → FIXED
Comment 117•5 years ago
|
||
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
Keywords: dev-doc-needed → dev-doc-complete
Comment 118•3 years ago
|
||
(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
Updated•3 years ago
|
Summary: HTML5 <ruby> support → [meta] HTML5 <ruby> support
You need to log in
before you can comment on or make changes to this bug.
Description
•