Summary: | Premature line break in heading at openclipart.org | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | mitz | ||||||
Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | Keywords: | HasReduction | ||||||
Priority: | P2 | ||||||||
Version: | 523.x (Safari 3) | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.4 | ||||||||
URL: | http://www.openclipart.org/ | ||||||||
Attachments: |
|
Description
mitz
2007-04-17 07:02:35 PDT
Created attachment 14060 [details]
Reduction
<http://trac.webkit.org/projects/webkit/changeset/21093> (bug 13431) fixed the site but not the reduction. The maxwidth is definitely larger now after my change. The padding appears to be growing the maxwidth. Need to understand why. Ah, I understand. The width of the positioned block's container has been computed by the time calcPrefWidths gets called. That means the padding can actually respect the width of the containing block. A nice improvement! Some interesting observations if we want to fully support this system: (1) An object with percentage padding actually needs to recompute its min/max width if the width of its container changes in addition to receiving a relayout. (2) A container with percentage padding needs to set relayoutChildren to true in situations where its contentWidth changes. Created attachment 14189 [details]
Patch that fixes the reduction
Comment on attachment 14189 [details]
Patch that fixes the reduction
Looks good!
I will land the reduction as a test case. |