[css21] 9.4.3 Relative positioning(getComputedStyle does not handle over-constrained properties correctly)

[deokjinkim]

Hello,

I have a question about css 2.1 spec.(https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#relative-positioning)

1. Background

I'm working on blink engine as deokjin81.kim@samsung.com.
As I know, getComputedStyle does not handle over-constrained properties correctly.
So I implemented it(https://bugs.chromium.org/p/chromium/issues/detail?id=601118) according to spec on blink engine.

2. Spec(https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#relative-positioning)

Below paragraphs(from spec) describe detail operation to handle over-constrained properties.

If neither 'left' nor 'right' is 'auto', the position is over-constrained, and one of them has to be ignored. If the 'direction' property of the containing block is 'ltr', the value of 'left' wins and 'right' becomes -'left'. If 'direction' of the containing block is 'rtl', 'right' wins and 'left' is ignored.

The 'top' and 'bottom' properties move relatively positioned element(s) up or down without changing their size. 'Top' moves the boxes down, and 'bottom' moves them up. Since boxes are not split or stretched as a result of 'top' or 'bottom', the used values are always: top = -bottom. If both are 'auto', their used values are both '0'. If one of them is 'auto', it becomes the negative of the other. If neither is 'auto', 'bottom' is ignored (i.e., the used value of 'bottom' will be minus the value of 'top').

3. Question

The spec text uses the verb “becomes.” I don’t know if this means that either 1) the rendering and the computed style should reflect this, or 2) just the rendering should reflect this.
Current implementation reflects second option("2) just the rendering should reflect this.").
I would like to know exact meaning of the verb "becomes.". Which one did you intend, 1) or 2)?

Thank you in advance,
Deokjin Kim

[upsuper]

From the context, I would suggest it is just about used value. I think if it is mentioning computed value, the phase "is computed to" is generally used instead. Also it says "'xxx' is ignored", which may indicate that it is simply not handled, rather than be computed to something else.

Actually, it seems to me computing it to something else would still make it hit the condition here, so treating it as a "used value" looks like the correct way.

[tabatkins]

Yes, 2.1 and some older specs still use fairly ambiguous terminology. Treat it as dictating what happens to the used values.

(fantasai and I are switching over to using the phrase "behaves as" for this kind of thing now. Hopefully that's less confusing?)

[upsuper]

I don't think it is changed in CSS 2.2 either, though :)

[bzbarsky]

@tabatkins The real point is that for these properties "used value" doesn't actually match any existing implementations.

[upsuper]

@bzbarsky As far as I can see, treating it as "used value" matches all existing implementations. Why do you think it doesn't? The fiddle provided by @deokjinkim shows all browsers have the same behavior in terms of what the computed value should be.

[bzbarsky]

The used value of "bottom" in that fiddle is "-5px", no? But the value reported by getComputedStyle is "5px" in all browsers as far as I can tell...

[upsuper]

Yes, used value and computed value are two different values of a property, so it is possible they have different numbers. What's wrong with that?

[bzbarsky]

The spec for getComputedStyle at https://drafts.csswg.org/cssom/#dom-window-getcomputedstyle says that it returns the "resolved value", which is defined at https://drafts.csswg.org/cssom/#resolved-value to be the "used value" for the "bottom" property of a positioned element that does not have display: none. That does not match any implementation on the fiddle in question.

[upsuper]

OK, I wasn't aware that getComputedStyle could return used values rather than always computed values. Then I have no idea what should be done. Probably browsers should fix?

[bzbarsky]

What makes you think what the spec says right now is web-compatible? Given that this API already returns computed values in various cases, it seems to me a better option is fixing the spec.

But note that it's not just about returning computed values, because if the computed "bottom" were "auto" then the used value would be returned in browsers.

[litherum]

All stable and nightly browsers that I could find[1] agree on the result of that fiddle. Therefore, the spec should be updated to adhere with the implementations.

[1]

• Microsoft Edge 25.10586.0.0 / Microsoft EdgeHTML 13.10586
• Firefox 50.0a1 (2016-06-20)
• Firefox 47.0
• Chrome 53.0.2773.0 canary
• Chrome 51.0.2704.103
• Safari 9.1.1
• WebKit r202242

[litherum]

Regarding my previous comment, I opened this new issue: #203