Re: bidi embedding for block-level elements

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.

A./

On 7/23/2010 2:42 PM, fantasai wrote:
> On 07/23/2010 01:35 PM, Ian Hickson wrote:
>> On Wed, 17 Mar 2010, fantasai wrote:
>>>
>>> <selector representing all HTML5 block-level elements>  {
>>>    display: block;      /* I assume you already have this somewhere */
>>>    unicode-bidi: embed; /* This is the new rule to add. */
>>> }
>>>
>>> <selector representing all HTML5 list-item elements>  {
>>>    display: list-item;  /* Assumed to exist already */
>>>    unicode-bidi: embed; /* This is the new rule to add. */
>>> }
>>>
>>> title, table, tbody, thead, tfoot, tr, td, th {
>>>    unicode-bidi: embed;
>>> }
>>
>> This would mean you couldn't have more than about 60 inline<div>s nested
>> inside each other without bidi breaking down. Is that an acceptable 
>> risk?
>> It seems like it would be a weird thing to tell authors.
>
> I think it's an acceptable risk. 60 levels of nesting on a block
> element that's been set to "display: inline" seems like a rather
> odd case to hit.
>
> The risk of messed up reordering due to /not/ isolating the block
> content is, I suspect, much higher than the risk of running out
> of bidi embedding levels due to nested "display: inline" DIVs.
>
> I agree it's a weird thing to tell authors. But hardly any of them
> will ever need to care.
>
> ~fantasai
>
>

Received on Friday, 23 July 2010 23:17:38 UTC