Update css3/flexbox/auto-margins.html after r177774
Created attachment 243783 [details] Patch
Comment on attachment 243783 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=243783&action=review > LayoutTests/ChangeLog:12 > + This is a subpixel problem. Flexbox uses SimpleLineLayout for the entire > + box and therefore does all its math in floating point, while the > + -expected uses the regular renderer hierarchy and therefore fixed-point > + math. This patch updates the test to use Ahem so that the character > + widths divide the same way in both cases. Does that mean that I could see a difference if a page dynamically changed layout between these two techniques? That sounds like a bug! I understand the desire to not make this test sensitive to this bug, but what about fixing the bug?
Comment on attachment 243783 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=243783&action=review > LayoutTests/ChangeLog:10 > + This is a subpixel problem. Flexbox uses SimpleLineLayout for the entire > + box and therefore does all its math in floating point, while the > + -expected uses the regular renderer hierarchy and therefore fixed-point Simple line layout snaps content to pixels at painting time the same way as any other InlineBox/RenderBox does. Whether it uses float or LayoutUnit while layouting shouldn't make any difference (other than in some edge cases caused by precession loss -where we might push content to the wrong position at halfway values). I think this is more about table layout vs. rest of the rendering layout, where table still uses integral positioning.
Committed r178063: <http://trac.webkit.org/changeset/178063>
Zalan says we already have a few bugs about subpixelifying tables, so I'm going to land this.
(In reply to comment #5) > Zalan says we already have a few bugs about subpixelifying tables, so I'm > going to land this. bug 132010