RE: Interop issues regarding tables and css tables

 > This is explicitly undefined in CSS 2.1, per the sentence:
> >
> >   # If such boxes are tall enough, there are multiple solutions and
> >   # CSS 2.1 does not define the position of the line box's baseline
> >   # (i.e., the position of the strut, see below).
> >
> > in http://www.w3.org/TR/CSS21/visudet.html#line-height .  In other
> > words, when an aligned subtree with vertical-align: top or bottom is
> > present that is taller than the aligned subtree associated with the
> > strut for the block, then the position of the strut for the block (and
> > everything aligned to it) is undefined.
> >
> > I think when we agreed to make it undefined in 2.1 we may have agreed
> > on what we wanted it to be defined as for level 3, but I don't
> > remember the details.
> 
> The minutes I can find are the discussion of
> http://wiki.csswg.org/spec/css2.1#issue-117 in
> http://lists.w3.org/Archives/Public/www-style/2010May/0312.html , and I
> don't see any resolution of what behavior we want for that case.
> 
> The discussion of the desired behavior seems to be minuted in:
> http://lists.w3.org/Archives/Public/www-style/2009Jun/0184.html

> but I don't think it looks like we reached a conclusion.
> 
> There was also an earlier resolution to leave it undefined in
> http://lists.w3.org/Archives/Public/www-style/2004Feb/0148.html

> 
> -David

Those were the very specs that we read and said, "Hey we're all right" because it's undefined  :) 

The reason I'm trying to address this however is this has been brought to us by a bug from a live site and also developers hitting the CSS equivalent. I'm partial to ours only for the sake of consistency, but if reasons can be brought out as to why Blink/Gecko are moving the baseline then we don't mind changing our implementation if that is the best route.

Thanks for your prompt help on this.

Greg

Received on Friday, 13 June 2014 15:51:28 UTC