- From: CE Whitehead <cewcathar@hotmail.com>
- Date: Sun, 25 Jul 2010 22:36:19 -0400
- To: <www-international@w3.org>, <www-html@w3.org>
- CC: <asmusf@ix.netcom.com>, <ian@hixie.ch>, <fantasai.lists@inkedblade.net>, <dbaron@dbaron.org>, <jackalmage@gmail.com>
- Message-ID: <SNT142-w21CBD6FFD710ED57CC4DDEB3A60@phx.gbl>
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
Received on Monday, 26 July 2010 02:36:53 UTC