Re: Bidi, HTML5 and CSS3, test bidi-html5-019

>  since the isolated element has the same effect on that paragraph as an
ON-class character (not B).

A better way of putting it would have been "since the isolated element has
the same effect on that paragraph as an ON-class character, regardless of
its actual content".

On Sat, Mar 10, 2012 at 8:16 PM, Aharon (Vladimir) Lanin
<aharon@google.com>wrote:

> >  What does that mean in terms of implementation?
>
> I am not sure what you mean.
>
> The Writing Modes spec says that unicode-bidi:embed on an element
> "corresponds to adding a LRE (U+202A), for ‘direction: ltr’, or RLE
> (U+202B), for ‘direction: rtl’, at the start of the element and a PDF
> (U+202C) at the end of the element." Similarly, unicode-bidi:bidi-override
> "corresponds to adding a LRO (U+202D), for ‘direction: ltr’, or RLO
> (U+202E), for ‘direction: rtl’, at the start of the element and a PDF
> (U+202C) at the end of the element." This is a plausible implementation of
> these unicode-bidi values.
>
> Now, when elements with these unicode-bidi values include a paragraph
> break (like <br>), the Writing Modes spec says that "the bidi control codes
> corresponding to the end of the element are added before the interruption
> and the codes corresponding to the start of the element are added after
> it." This is referring to the LRE|RLE|LRO|RLO|PDF specified above.
>
> > <span style='direction:d; unicode-bidi:u'>...<br>...</span>
> > is equivalent to:
> > <span style='direction:d; unicode-bidi:u'>...<span><br><span
> style='direction:d; unicode-bidi:u'>...</span>
>
> That is correct (in terms of bidi ordering) for unicode-bidi:embed,
> unicode-bidi:bidi-override, and (in a null sort of way) unicode-bidi:normal.
>
> It is not correct for unicode-bidi:isolate and unicode-bidi:plaintext,
> which specify that "for the purpose of bidi resolution in its containing
> bidi paragraph (if any), the element itself is treated as if it were an
> Object Replacement Character (U+FFFC)." U+FFFC is in ON bidi class. Thus, a
> <br> inside a unicode-bidi:isolate element acts as a paragraph separator
> within that isolated element (with the same "reopening" as above), but the
> paragraph around the isolated element remains unbroken, since the isolated
> element has the same effect on that paragraph as an ON-class character (not
> B).
>
> (This is implemented correctly in Firefox, but not in WebKit)
>
> On Fri, Mar 9, 2012 at 6:28 PM, Eric Muller <emuller@adobe.com> wrote:
>
>>  Thanks for the answer.
>>
>> I now understand that <br> is really intended to be a paragraph
>> separator, as far as bidi is concerned.
>>
>> I also understand better the relationship between HTML and CSS.
>>
>> I am still a bit confused but before I can express that, a couple of
>> questions:
>>
>>
>> 'If an inline element is
>> broken around a bidi paragraph boundary (e.g. if split by a block or
>> forced paragraph break), then the bidi control codes corresponding to
>> the end of the element are added before the interruption and the codes
>> corresponding to the start of the element are added after it. (In
>> other words, any embedding levels or overrides started by the element
>> are closed at the paragraph break and reopened on the other side of it.)
>>
>>
>> What does that mean in terms of implementation?
>>
>> - that in the bidi computation, the state after X1-X6 processing of the
>> paragraph before the paragraph boundary is used as the initial state for
>> the X1-X6 processing of the paragraph after that boundary (really,
>> overriding the second X1)? That state being: the current embedding level,
>> the directional status override, the stack of underlying X1-X6.
>>
>> - that only some of that state is carried over? if so, how much?
>>
>> - the meaning is in terms of HTML/CSS only, something like:
>>
>> <span style='direction:d; unicode-bidi:u'>...<br>...</span>
>>
>>
>> is equivalent to:
>>
>> <span style='direction:d; unicode-bidi:u'>...<span><br><span
>> style='direction:d; unicode-bidi:u'>...</span>
>>
>>
>> (with the property present on the second only if it is present on the
>> first; and of course, with the similar treatment of relevant HTML elements
>> attributes). If that is the case, what are the exact rules?
>>
>> - something else?
>>
>>
>> Also, what is the eor of the last run of the paragraph before, and the
>> sor of the first run of the paragraph after?
>>
>>
>> Thanks,
>> Eric.
>>
>>
>