| Summary: | misalignment because of float:left of <div> tag | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Anantha Keesara <anantha> | ||||||||||
| Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> | ||||||||||
| Status: | RESOLVED FIXED | ||||||||||||
| Severity: | Normal | CC: | mitz, webkit | ||||||||||
| Priority: | P2 | Keywords: | HasReduction | ||||||||||
| Version: | 528+ (Nightly build) | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | All | ||||||||||||
| URL: | http://rc.9you.com/info_car_01.html | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Anantha Keesara
2007-11-06 21:10:16 PST
Created attachment 17082 [details]
reduced testcase
Created attachment 17083 [details]
screenshot
Created attachment 19544 [details] reduced test case #2 This test case is pretty interesting if you run it in Gecko. Setting 2px border in Gecko imply proper table positioning :D. The first example is incorrectly rendered. Webkit r30780 fails in both cases. The latter shows incorrect overflow table outside a parent DIV. Presto (Opera 9.50) correctly displays both cases. Definitely bug. This is Live DOM Viewer version of the test case #2 This is one of two or three bugs about this quirk. See RenderBlock.cpp:2820. (In reply to comment #6) > This is one of two or three bugs about this quirk. See RenderBlock.cpp:2820. > But reduced test case #2 is in strict mode (CSS1Compat) and the issue is still visible. Yup, there also seems to be an exception for percent-width objects, while on the other hand table widths are computed as if tables always clear floats. Created attachment 34774 [details]
Use computed width for float avoidance and unify the rules across parsing modes
This appears to match Firefox and IE8 with the exceptions that in Firefox, <hr>s just overflow instead of clearing the float, and in IE, the <hr>’s percent sizes are computed relative to the available width next to the float (so 100% or less never needs to clear the float).
Comment on attachment 34774 [details] Use computed width for float avoidance and unify the rules across parsing modes > + (WebCore::RenderBlock::getClearDelta): Changed to apply the same float > + avoisame logic in strict mode and in compatibility mode, which avoisame -> avoidance > - // Do not allow tables to wrap in quirks or even in almost strict mode > - // (ebay on the PLT, finance.yahoo.com in the real world, versiontracker.com forces even almost strict mode not to work) Did you try these test sites? > int result = clearSet ? max(0, bottom - yPos) : 0; > - if (!result && child->avoidsFloats() && child->style()->width().isFixed() && > - child->minPrefWidth() > lineWidth(yPos, false) && child->minPrefWidth() <= availableWidth() && > - document()->inStrictMode()) > - result = max(0, floatBottom() - yPos); > + if (!result && child->avoidsFloats()) { > + int oldYPos = child->y(); > + int oldWidth = child->width(); > + child->setY(yPos); > + child->calcWidth(); > + if (child->width() > lineWidth(yPos, false) && child->minPrefWidth() <= availableWidth()) > + result = max(0, floatBottom() - yPos); > + child->setY(oldYPos); > + child->setWidth(oldWidth); > + } I'd love to say r=me, but this may be a little out of my league. Probably needs a Hyatt review or some other layout expert. Comment on attachment 34774 [details] Use computed width for float avoidance and unify the rules across parsing modes > Index: WebCore/ChangeLog > =================================================================== > + * rendering/RenderBlock.cpp: > + (WebCore::RenderBlock::getClearDelta): Changed to apply the same float > + avoisame logic in strict mode and in compatibility mode, which Avoidance? (In reply to comment #10) > > - // Do not allow tables to wrap in quirks or even in almost strict mode > > - // (ebay on the PLT, finance.yahoo.com in the real world, versiontracker.com forces even almost strict mode not to work) > > Did you try these test sites? VersionTracker and Yahoo! Finance in their current form appear to be unaffected by the change. The version of ebay on the PLT is affected, and with the change it looks like it looks in Firefox 3.5. The current version of ebay is unaffected as far as I can tell. |