W3C home > Mailing lists > Public > public-i18n-bidi@w3.org > July to September 2012

Re: Proposal for isolation characters in Unicode and the unicode-bidi:isolate and unicode-bidi:plaintext definitions

From: Dov Grobgeld <dov.grobgeld@gmail.com>
Date: Tue, 3 Jul 2012 15:16:27 +0300
Message-ID: <CA++fsGE6ciXLT3M2t=ZVrXjApm0j76gNDsy2D1dMoyjfB980uQ@mail.gmail.com>
To: "Aharon (Vladimir) Lanin" <aharon@google.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, Matitiahu Allouche <matitiahu.allouche@gmail.com>, asmusf@ix.netcom.com, mohiem@eg.ibm.com, duerst@it.aoyama.ac.jp, public-i18n-bidi@w3.org
Note the following discussion that discussed something similar back in 2004:

http://www.digipedia.pl/usenet/thread/13266/252/

Regards,
Dov


On Tue, Jul 3, 2012 at 3:07 PM, Aharon (Vladimir) Lanin
<aharon@google.com>wrote:

> I have compared the content of
> http://www.w3.org/TR/2012/WD-css3-writing-modes-20120501/ with that of
> http://dev.w3.org/csswg/css3-writing-modes/, and I do not think that the
> changes are at all related to this thread. The isolates are still described
> in the terms of a higher-level protocol that treats the isolate's content
> as if it were in a separate document. The list of major changes does not
> make any reference to Unicode isolates either.
>
> Please note that using the new codepoints instead of treating the
> isolate's content as if it were in a separate document does introduce two
> significant changes in behavior:
> - Paragraph breaks (e.g. <br>) within the isolate break the paragraph
> within which the isolate appears. This appears to be an improvement over
> the spec as it stands.
> - The embedding level goes up inside an isolate, instead of being reset to
> 0 or 1. This is not an improvement over the spec as it stands, but is
> unavoidable if isolates are implemented in terms of Unicode codepoints.
>
> I am not pushing to change the CSS spec now, before the new isolate
> codepoints have been approved and added to Unicode. I am not at all sure
> that it can change in this respect until then.
>
> However, I do want to make sure of two things:
> 1. That the CSS spec changes I outlined in my original message look
> reasonable, so that if the new Unicode codepoints were to be approved
> today, the spec could be changed as outlined.
> 2. That the CSS spec of unicode-bidi:isolate, isolate-override, and
> plaintext will not become frozen before it has been changed to use the new
> Unicode codepoints.
>
> The great benefit for changing the spec to be based on the new codepoints
> is that it will make it much easier to implement isolates. Current browser
> implementations have different, serious, difficult-to-solve bugs stemming
> precisely from the fact that they had to work around the UBA instead of
> just letting it do its job.
>
> It would also be pretty terrible if the Unicode and CSS specs offered very
> similar features that nevertheless behaved quite differently in certain
> perfectly valid cases.
>
> I would be very happy to discuss the details of the CSS spec changes I
> proposed. (Actually, if anyone is interested in such a discussion, I should
> probably start by update that proposal given that both the CSS spec and the
> Unicode isolates proposal have changed in the meantime.)
>
> Aharon
>
>
> On Tue, Jun 26, 2012 at 9:01 AM, fantasai <fantasai.lists@inkedblade.net>wrote:
>
>> On 05/17/2012 05:16 AM, Matitiahu Allouche wrote:
>>
>>> I am in favor of Aharon Lanin's proposal for 3 new characters: LRI, RLI
>>> and FSI, with Martin Duerst's addition of a fourth
>>> character to terminate the scope of the last unclosed RI, RLI or FSI.
>>>
>>> I also agree that the HTML/CSS behavior for the BDI element should be as
>>> similar as possible to the behavior of those 4
>>> characters in plain text.
>>>
>>
>> I've attempted to work this proposal into the Writing Modes specification.
>> Here's the editor's draft:
>>   http://dev.w3.org/csswg/css3-**writing-modes/#bidi<http://dev.w3.org/csswg/css3-writing-modes/#bidi>
>>
>> ~fantasai
>>
>
>
Received on Tuesday, 3 July 2012 12:16:58 UTC

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