Bug 60609 – Implement CSSPropertyMargin and CSSPropertyPadding in CSSStyleApplyProperty.

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Luke Macpherson]

Implement CSSPropertyMargin and CSSPropertyPadding in CSSStyleApplyProperty.

[Luke Macpherson]

Created attachment 93072 [details]
Patch

[Eric Seidel (no email)]

Comment on attachment 93072 [details]
Patch

OK.  How does this do the resetPadding stuff?  Or does it call each of the reset funtions individually (thus obsoleting the resetPadidng function?)

[Luke Macpherson]

resetMargin is equivalent to setting the top, left, bottom and right margins to RenderStyle::initialMargin()

however,

resetPadding sets top, left, bottom, right to AUTO, while the individual cases are setting them to FIXED. This smells a lot like a bug in the existing code - in every case I've seen so far initializing the shorthand is exactly equivalent to initializing the individual values.

[Eric Seidel (no email)]

Comment on attachment 93072 [details]
Patch

Since we're changing behavior, we'll need a test.  You can break out the non-behavior change from the behavior chagne if you like.  r=me on landing the non-behavior change w/o further review!

[Luke Macpherson]

For reference, http://www.w3.org/TR/CSS21/box.html#propdef-padding says
"Initial:  	see individual properties"

[Luke Macpherson]

(In reply to comment #5)
> For reference, http://www.w3.org/TR/CSS21/box.html#propdef-padding says
> "Initial:      see individual properties"

It appears that because of the way these values are used, Length(AUTO) and Length(FIXED) are treated equivalently.

for example:
int RenderBoxModelObject::paddingLeft(bool) const
{
    int w = 0;
    Length padding = style()->paddingLeft();
    if (padding.isPercent())
        w = containingBlock()->availableLogicalWidth();
    return padding.calcMinValue(w);
}

Will return 0 for both. Using AUTO in RenderStyle means that we are depending on the w=0 above for correct behavior. RenderStyle would better reflect the CSS spec by using RenderStyle::initialPadding() for its initial value.

FYI, this is passing DRT and pixel tests for me, and I count 949 uses of "padding:" under LayoutTests/fast, so we already have good coverage there.

[Eric Seidel (no email)]

Can we detect this change with getComputedStyle?

[Luke Macpherson]

(In reply to comment #7)
> Can we detect this change with getComputedStyle?

I just tested setting "padding: 0px;", "padding: auto;", "padding: 10%". In all cases getComputedStyle(e).getPropertyValue("padding-left") returns a px value; in the first two cases is 0px.
I think that means this change is not detectable from JS because it always returns the calculated pixel value.

[Eric Seidel (no email)]

Comment on attachment 93072 [details]
Patch

Ok.  It's possible it might still be reachable from CSSStyleDeclaration. getPropertyCSSValue() somehow, but that's even more obscure.  Sounds fine.

[WebKit Commit Bot]

Comment on attachment 93072 [details]
Patch

Clearing flags on attachment: 93072

Committed r86308: <http://trac.webkit.org/changeset/86308>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[WebKit Review Bot]

http://trac.webkit.org/changeset/86308 might have broken Windows XP Debug (Tests)
The following tests are not passing:
editing/deleting/delete-ligature-001.html
editing/deleting/delete-ligature-002.html
editing/deleting/delete-ligature-003.html