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