- From: <bugzilla@jessica.w3.org>
- Date: Thu, 30 Sep 2010 19:53:02 +0000
- To: public-i18n-cjk@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10829 I18n Core WG <public-i18n-core@w3.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |public-i18n-core@w3.org --- Comment #4 from I18n Core WG <public-i18n-core@w3.org> 2010-09-30 19:53:01 UTC --- If drop the code in the example into a file and look at it in Chrome, the white-space disappears, but look at it in IE (on which this markup is supposed to be modelled) and you see the spaces in the text (see attachment just above). I wasn't able to tell from the spec why this should be treated differently from other phrasing content elements, such as span, where white-space is not automatically removed. This also brings into question the intended use of ruby markup. Some people view ruby markup as a mechanism that could be used for things like linguistic glosses (in fact i had a query from a member of the public just today about exactly that). In such cases they may want to annotate a string of words separated by spaces. If spaces are removed automatically from the outside edges of the base text, they would be forced to use separate <ruby> elements for each word annotated in such a sentence - which seems counter to the change in the HTML5 ruby markup model that allows several ruby base/text pairs within a single <ruby> element vs the more cumbersome Ruby Annotation model, where each simple ruby pairing had to have it's own <ruby> element. In other words, if white space is removed from around the base of HTML5 ruby, then presumably several pairs of ruby+ruby text should only be used with Japanese and Chinese. It's beginning to appear to me that this reveals a substantive rather than a merely editorial issue. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You reported the bug.
Received on Thursday, 30 September 2010 19:53:05 UTC