W3C home > Mailing lists > Public > www-style@w3.org > March 2004

Re: bidirectionality with white-space collapsing

From: Mark Davis <mark.davis@jtcsv.com>
Date: Tue, 9 Mar 2004 13:19:56 -0500 (EST)
Message-ID: <005501c40603$04c626e0$6401a8c0@DAVIS1>
To: "Tex Texin" <tex@XenCraft.com>, "Richard Ishida" <ishida@w3.org>
Cc: <www-style@w3.org>, <w3c-i18n-ig@w3.org>
The problem is that neutrals around bidi may get reordered in interesting ways. So where possible, exterior spaces should be excluded. For attributes that essentally make no difference when applied to spaces (like bold, color, italic), they should definitely be excluded. For others, like underline, it may be necessary, but should be approached with caution.

Example. Suppose the abc below, plus the following space is underlined. You will see

ABC abc def DEF

It will display as

FED abc def CBA

Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄
 
----- Original Message ----- 
From: "Tex Texin" <tex@XenCraft.com>
To: "Richard Ishida" <ishida@w3.org>
Cc: <www-style@w3.org>; <w3c-i18n-ig@w3.org>
Sent: Tue, 2004 Mar 09 10:01
Subject: Re: bidirectionality with white-space collapsing


> 
> Richard Ishida wrote:
> > 
> > The last line of http://www.w3.org/TR/2003/WD-CSS21-20030915/text.html#q9 says "This is best avoided by using the natural bidirectionality of characters instead of explicit embedding levels."
> > 
> > My view is the following (also expressed perhaps slightly too succinctly in the FAQ http://www.w3.org/International/questions/qa-bidi-space.html that gave rise to the section in the CSS spec):
> > 
> > 1. As a general principle it is best to put white space on the outside of markup rather immediately inside (ie. "XXX <markup>YYY</markup> ZZZZ" is better than "XXX<markup> YYY </markup>ZZZZ" or "XXX <markup> YYY </markup> ZZZZ"); and such an approach would solve the problem here.
> 
> 
> I don't think you can say this "solve's the problem better" or that one
> approach is better than another in this instance.
> If the problem is the span sets text-decoration:underline, and you want the
> space underlined, the solution is to remove the
> space ahead of the markup and keep the space inside.
> 
> It should just make clear how it works, and the user needs to decide what they
> are attempting to author.
> 
> 
> > 2. Also, *if* the required presentation would be achieved by the bidirectional algorithm alone, and without markup that creates a new embedding level, then it is better to omit the directional attribute from the markup or remove the markup altogether (depending on how the markup is used) (which I think was what the CSS spec was trying to say). Eg. a single word in arabic or hebrew in an English sentence usually requires no markup to achieve the correct visual ordering in an XHTML document. You may want to surround it by something like a span element to apply font styling, but you don't need the dir attribute.
> 
> It is not clear to me that the statistics support this statement. Although the
> majority of words and text end in strong direction characters, there are many
> situations, especially if the text ends in punctuation or parentheses, where
> having direction is helpful. I understand the alternative to add a format where
> needed, but where is the harm in associating direction with a style, given that
> not only direction but many other aspects of style are associated with language
> and many authors will create styles for language, and it alleviates the need to
> examine the endings of text runs and treat case by case.
> 
> 
> 
> 
>  
> > Hope that helps,
> > RI
> > 
> > ============
> > Richard Ishida
> > W3C
> > 
> > contact info: http://www.w3.org/People/Ishida/
> > 
> > http://www.w3.org/International/
> > http://www.w3.org/International/geo/
> 
> -- 
> -------------------------------------------------------------
> Tex Texin   cell: +1 781 789 1898  mailto:Tex at XenCraft.com
> Xen Master         XenCraft           http://www.XenCraft.com
> Making e-Business Work Around the World
> -------------------------------------------------------------
> 
> 
Received on Wednesday, 10 March 2004 08:06:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:27 GMT