W3C home > Mailing lists > Public > public-i18n-bidi@w3.org > January to March 2010

Re: bidi proposal

From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Date: Thu, 18 Mar 2010 15:43:52 +0900
Message-ID: <4BA1CBA8.5050509@it.aoyama.ac.jp>
To: fantasai <fantasai.lists@inkedblade.net>, "Aharon (Vladimir) Lanin" <aharon@google.com>
CC: public-i18n-bidi@w3.org
Hello Aharon, fantasai, others,

See below.

On 2010/03/18 6:32, fantasai wrote:
> On 03/17/2010 07:05 AM, Aharon (Vladimir) Lanin wrote:

> On 02/24/2010 06:08 AM, Aharon (Vladimir) Lanin wrote:

>  > > A related problem is block elements that are rendered as display:
> inline.
>  > > The CSSWG has an issue filed on having these default to
> unicode-bidi: embed
>  > > in our sample HTML4 style sheet. (Looking at your document, they
> might also
>  > > need bdi=yes.)
>  >
>  > If I remember correctly, all browsers until very recently treated text
>  > in a <div style="display:inline"> as if it were in a <span>. I now see
>  > that Firefox 3.6 has indeed broken ranks and is now treating it as if it
>  > were a <span style="unicode-bide:embed">. I am not sure what the
>  > rationale for this is. IMO, using unicode-bidi:embed without specifying
>  > direction, i.e. defaulting to the parent's direction, is a technique in
>  > search of a purpose. I think I liked the old behavior better.
> The old behavior would cause things like
> abcd.
> <div style="display:inline">efg HIJK.</div>
> LMNOP qrst.
> which is normally rendered as
> abcd
> efg KJIH.
> PONML qrst.
> to be rendered as
> abcd. efg PONML .KJIH qrst.
> Since the author chose a block-level element, it's reasonable to assume
> that they meant for that string of text to stay together as one unit.

Yes indeed! That was the reason why we specified it that way in HTML4. Using
   <div style='display: inline">
as given here (i.e. with a style *attribute*) is good to make the 
example short, but isn't the way this would usually be used. What we 
imagined is use cases such as being able to change e.g. a <ol> to an 
inline list such as "1) apple; 2) orange; 3) pear."

However, when we wrote the text in HTML4 

"When a block element that does not have a dir attribute is transformed 
to the style of an inline element by a style sheet, the resulting 
presentation should be equivalent, in terms of bidirectional formatting, 
to the formatting obtained by explicitly adding a dir attribute 
(assigned the inherited value) to the transformed element."

we were not aware of the fact that embeddings have the kind of side 
effects that the attribute currently named 'bdi' intends to address. So 
my current guess is that this should be fixed to say: "explicitly 
addiing a dir attribute (assigned the inherited value) and a bdi 
attribute (with value yes)". Aharon, would that make more sense to you 
that the current Firefox behavior?

> Applying "unicode-bidi: embed" to all HTML block-level elements was
> actually in an earlier version of the CSS2 sample style sheet for HTML.
> I suspect it was removed because it's redundant with "display: block" --
> but it becomes relevant when the display type is changed. The CSSWG
> currently has an open issue about adding it back.

It should be added back. The split of the bidi functionality into the 
two properties 'unicode-bidi' and 'direction' (that was Hakon's idea)

>  > I agree that it would be best to come up with an explicit spec of what
>  > the expected bidi behavior is in all these strange combinations of
>  > element type and display type.
> Yes.

What are the other combinations that we have to look at?

Regards,   Martin.

#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp
Received on Friday, 19 March 2010 01:15:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:24:37 UTC