[Bug 10829] i18n comment : ruby code samples

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 the QA contact for the bug.

Received on Thursday, 30 September 2010 19:53:05 UTC