Re: bidi embedding for block-level

 


From: Asmus Freytag <asmusf@ix.netcom.com> 
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 <asmusf@ix.netcom.com> 
Date: Fri, 23 Jul 2010 22:25:54 -0700
Message-ID: <4C4A7962.3010207@ix.netcom.com> 
 "L. David Baron" <dbaron@dbaron.org>, fantasai <fantasai.lists@inkedblade.net>, Ian Hickson <ian@hixie.ch>, Simon Montagu <smontagu@smontagu.org>, www-html@w3.org, WWW International <www-international@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>, "www-style@w3.org" <www-style@w3.org> 

> 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?
Thanks! 
Best,

C. E. Whitehead
cewcathar@hotmail.com