RESOLVED FIXED 139975
Update css3/flexbox/auto-margins.html after r177774 
https://bugs.webkit.org/show_bug.cgi?id=139975
Summary Update css3/flexbox/auto-margins.html after r177774
Myles C. Maxfield
Reported 2014-12-28 10:32:01 PST
Update css3/flexbox/auto-margins.html after r177774
Attachments
Patch (4.30 KB, patch)
2014-12-28 10:35 PST, Myles C. Maxfield 		darin: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Myles C. Maxfield
Comment 1 2014-12-28 10:35:28 PST
Created attachment 243783 [details] Patch
Darin Adler
Comment 2 2014-12-28 11:12:46 PST
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?
zalan
Comment 3 2014-12-28 11:45:14 PST
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.
Myles C. Maxfield
Comment 4 2015-01-07 15:56:01 PST
Committed r178063: <http://trac.webkit.org/changeset/178063>
Myles C. Maxfield
Comment 5 2015-01-07 15:56:32 PST
Zalan says we already have a few bugs about subpixelifying tables, so I'm going to land this.
zalan
Comment 6 2015-01-07 16:10:22 PST
(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
Note You need to log in before you can comment on or make changes to this bug.