Bug 19828 - Computed style for margin right is incorrect.
Summary: Computed style for margin right is incorrect.
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows XP
: P2 Normal
Assignee: Nobody
URL:
Keywords: HasReduction
Depends on:
Blocks:
 
Reported: 2008-06-30 11:17 PDT by Erik Arvidsson
Modified: 2009-03-02 15:42 PST (History)
3 users (show)

See Also:


Attachments
The computed margin should be 10px (384 bytes, text/html)
2008-06-30 11:19 PDT, Erik Arvidsson
no flags Details
test case (841 bytes, text/html)
2009-01-06 05:10 PST, Robert Blaut
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Arvidsson 2008-06-30 11:17:51 PDT
The computed style value for margin right is not correct and it does not match Firefox nor Opera.

el.style.marginRight = '10px';
document.defaultView.getComputedStyle(el, '').marginRight // != 10px

The value returned seems to be related to the computed distance between the offsetParent right edge and the right border of the element.  However it is not equal to:

el.offsetParent.clientWidth - el.offsetLeft - el.offsetWidth

Test case coming.
Comment 1 Erik Arvidsson 2008-06-30 11:19:01 PDT
Created attachment 22008 [details]
The computed margin should be 10px

Sometimes a reload is required to get the faulty margin value.
Comment 2 Paul Bakaus 2008-11-24 03:12:28 PST
I can confirm this for all platforms. Additionally, this only happens if margin right is set through stylesheets - if set using inline styles, the correct value is reported.
Comment 3 Robert Blaut 2009-01-06 05:09:40 PST
CSS 2.1 specification says: "The following constraints must hold among the used values of the other properties:
'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-width' + 'margin-right' + scrollbar width (if any) = width of containing block"

[...]

If all of the above have a computed value other than 'auto', the values are said to be "over-constrained" and one of the used values will have to be different from its computed value. If the 'direction' property of the containing block has the value 'ltr', the specified value of 'margin-right' is ignored and the value is calculated so as to make the equality true. If the value of 'direction' is 'rtl', this happens to 'margin-left' instead."

<http://www.w3.org/TR/CSS21/visudet.html#blockwidth>

In my opinion WebKit correctly prints other than 10px *computed* value. Firefox is wrong in this case. 

Check attached test case.
Comment 4 Robert Blaut 2009-01-06 05:10:01 PST
Created attachment 26458 [details]
test case
Comment 5 Robert Blaut 2009-01-06 05:11:24 PST
This bug report is invalid.
Comment 6 Humberto Madeira 2009-03-02 15:42:23 PST
I believe this bug was rejected because the specification is being misread. 

The specification speaks of "computed values" and "used values" as being distinct from each other. 

e.g. in section 10.3
 "(The value used for layout is sometimes referred to as the used value.) In principle, the values used are the same as the computed values, with 'auto' replaced by some suitable value, and percentages calculated based on the containing block, but there are exceptions."

With respect to the constraints, they refer to the "used values" and not the computed values.

e.g. in section 10.3.3 
"The following constraints must hold among the used values of the other properties:

'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-width' + 'margin-right' + scrollbar width (if any) = width of containing block"

So according to the specification, the computed values are under no constraints of any sort other than the usual CSS precedence rules.  It is the "used values", which are used for layout purposes, that are constrained.

I believe, after a closer look at the specification, that this bug is actually valid.