Re: table-height-algorithm-026 invalid

On Friday 2010-12-03 19:07 +0000, Arron Eicholz wrote:
> On Friday, December 03, 2010 10:32 AM L. David Baron wrote:
> > On Friday 2010-12-03 17:32 +0000, Arron Eicholz wrote:
> > > On Saturday, October 16, 2010 3:04 PM L. David Baron wrote:
> > > > http://test.csswg.org/suites/css2.1/20101001/html4/table-height-algo
> > > > rithm-
> > > > 026.htm
> > > > http://test.csswg.org/suites/css2.1/20101001/xhtml1/table-height-
> > > > algorithm-026.xht
> > > > claim to be testing the assertion:
> > > >   The baseline of a cell is determined by the bottom content edge of
> > > >   a cell when in-flow line boxes and table rows are not present.
> > > >
> > > > However, both cells actually have in-flow line boxes.  Furthermore,
> > > > the two cells should only align if the default padding and border of
> > > > a button exactly match the half-leading that results from the normal
> > > > line-height, which is not guaranteed by the spec.
> > >
> > > Fixed based on Gérard Talbot's feedback
> > 
> > I think the current version is still slightly off.  In particular, the new version
> > appears to work by using margin-left:-10px to cause two runs of _ characters
> > to overlap.  However, with subpixel antialiasing, the part where they overlap
> > can be darker because it's been double-drawn, which makes the line not
> > quite continuous.
> 
> Fixed changed the color to black.

That's not sufficient to make the line continuous.

(And I shouldn't have specifically mentioned subpixel antialiasing;
it's an issue with any type of antialiasing.)

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Friday, 3 December 2010 19:30:16 UTC