Re: bidi embedding for block-level elements

On Fri, 23 Jul 2010, 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.

On Fri, 23 Jul 2010, L. David Baron wrote:
> 
> 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">.

On Fri, 23 Jul 2010, Boris Zbarsky wrote:
> 
> For what it's worth, Gecko has had "div { unicode-bidi: embed; }" in the 
> UA stylesheet for about a year now in nightlies and for close to half a 
> year in a shipping release (Firefox 3.6).  I don't believe we've had a 
> single issue reported in that time.

Done:

  http://html5.org/tools/web-apps-tracker?from=5283&to=5284

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'