Bug 19828 – Computed style for margin right is incorrect.

• Status: RESOLVED
• Resolution: INVALID
• Component: DOM

[Erik Arvidsson]

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.

[Erik Arvidsson]

Created attachment 22008 [details]
The computed margin should be 10px

Sometimes a reload is required to get the faulty margin value.

[Paul Bakaus]

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.

[Robert Blaut]

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.

[Robert Blaut]

Created attachment 26458 [details]
test case

[Robert Blaut]

This bug report is invalid.

[Humberto Madeira]

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.