Webcore-bits: Height merge for RenderBox

[Germain Garand]

Le Samedi 16 Octobre 2004 20:39, Allan Sandfeld Jensen a écrit :
> Hi again
>
> Next webcore-patch. The reason I this time post to the mailing list is not
> confusion, but more than 2600 changed regression-outputs.
> The patch introduces an IE-quirk where the body ends up with the same size
> as the canvas, this ofcourse affects a lot of regression-tests (but fixes
> bug 76759)
>
> The patch also fixes bugs: 76759 (height 100%), 59502(min-height) and 59503
> (max-height). And naturally the quirk-height and minheight tests in the
> regressionstests from WebCore.
>

Hi Allan,
the min max-height/percentage calculation part looks all fine, but the body 
quirk needs some discussion.
Namely, if we are going to follow MSIE/WebCore on such a major quirk, then it 
means we must fix our"quirk mode vs. almost standard vs. standard mode" 
behaviour in the same go.

MSIE/WebCore would only do such a hack on real basic quirk mode, whereas 
currently, this would also apply to all transitional DTDs for us.

There was already an attempt to change that, but it came too late in the 
release cycle and was reverted (see #83129, still open).

Also, it's interesting to note that Gecko/Opera don't apply this quirk as a 
whole, but only when there are percentage calculations involved.

I tend to find this solution much smoother (it would then need the attached 
modification to your patch, that still solves the same bugs), but that is 
debatable. Depends whether we are leaning more on the IE or the Gecko side...

Other topic:  in the min/max width part, this bit:
-    cw = containingBlock()->width();
+    cw = containingBlockWidth() + cb->paddingLeft() + cb->paddingRight();

would need to be merged separately to track specific regressions. 
Our containingBlockWidth() method is not ready yet...
(see meyerweb.com/css2-tests/ horizontal alignment regressions)

> I should note I also saw a few cases of OverhangingContent flags
> disappearing, but the cases didn't seem to have overhanging content.

In the patch, it is only set for Percent widths, whereas
it was also set for Fixed widths before. But it looks strange even in our 
current version (it checks for the previous m_width, right? so it must be 
wrong on the first layout... mmh...).
The flag is used to avoid some calculations at painting time, but seeing
WC wiped it out altogether, it would be worth doing some timing tests to see 
if we may remove it as well.

Greetings,
Germain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: text/x-diff
Size: 2495 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20041018/580df982/attachment.diff>