Re: bidi embedding for block-level


From: Asmus Freytag <> 
Date: Fri, 23 Jul 2010 17:37:32 -0700

> 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
> . . .

> 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.
I like this!  In subsequent emails -- you continue to insist that there are indeed many insanely nested inline lists --
but then, if I understand, you indicate that such algorithms are not worth wasting code on.
So are deferred embeddings still on the table?
> This would still isolate the <div> from the directionality of the 
> surrounding text - or have I missed something here?

> A./

* * *


From: Asmus Freytag <> 
Date: Fri, 23 Jul 2010 22:25:54 -0700
Message-ID: <> 
 "L. David Baron" <>, fantasai <>, Ian Hickson <>, Simon Montagu <>,, WWW International <>, "" <>, "" <> 

> On 7/23/2010 9:51 PM, Boris Zbarsky wrote:
>> On 7/24/10 12:41 AM, Asmus Freytag wrote:
>>> On 7/23/2010 6:31 PM, Tab Atkins Jr. wrote:
>>>> No, inline elements don't trigger this. Only block elements,
>>>> list-items, and table elements. The only way to trigger problems is
>>>> to take a ton of block-level elements, make them display:inline, and
>>>> nest them.
>>> Like insanely nested lists...
>> Lists are not display:inline by default.  If you take insanely nested 
>> lists and make them display:inline.... then they become unreadable, 
>> for the most part.
> OK. You've got to work at it.
Yes (unless perhaps you are a Faulkner type; I don't know).  So is or is it not worth the code and testing for "deferred embeddings" and/or warnings?

C. E. Whitehead

Received on Monday, 26 July 2010 02:36:53 UTC