Re: bidi embedding for block-level elements

On 7/23/2010 4:44 PM, L. David Baron wrote:
> On Friday 2010-07-23 16:16 -0700, Asmus Freytag wrote:
>> The ceiling on embeddings in the bidi algorithm was invented in an
>> attempt to prevent implementations from taking shortcuts and setting
>> their own ceiling. 60 some levels was thought to be small enough
>> that any implementation could handle it, and yet inconceivably large
>> for practical cases. However, the limit is on bidi levels, not on
>> the number of embeddings. It occurs to me that in some contexts,
>> levels could increment by 2. Might be worth someone checking in the
>> bidi specification under what circumstances that occurs, and whether
>> that means the worst case nesting limit is lower.
> In the case Ian raised, I'd think embedding level would normally
> increment by 2, since there are no directionality changes, and an
> LTR (RTL) embedding bumps the embedding level to the next higher
> even (odd) embedding level.
> So bidi would start breaking down inside the 32nd nested <div
> style="display:inline">.
> -David
Sorry, I didn't pay attention to this discussion earlier, but allow me 
to ask a few questions.

Forcing an embedding regardless of directionality change seems not quite 
the right solution to me. If I understand this correctly, merely by 
nesting inline elements in a completely RTL document, you suddenly would 
need to run the bidi reordering - with no visible effect.

HTML/CSS could allow other mechanisms that don't have an explicit 
counterpart in the bidi algorithm, for example, something like a 
deferred embedding. Has a mechanism like that been discussed? A deferred 
embedding would be inactive if the embedding direction of the outer 
scope matched the embedding direction. When rendering, or when 
converting to plain text, the embedding would be ignored, unless there 
was a change in embedding direction. You would then need 60 nested 
scopes of opposite directionality to hit the ceiling.

Likewise, when you convert from plain text, you could convert to 
deferred embeddings, in an effort from keeping invisible embeddings from 
piling up unnecessarily.

This would still isolate the <div> from the directionality of the 
surrounding text - or have I missed something here?


Received on Saturday, 24 July 2010 00:38:12 UTC