Hello,
I asked this issue and W3C WG said that it means "used value". (
https://github.com/w3c/csswg-drafts/issues/190)
When I checked spec for getComputedStyle(), some properties('bottom',
'left', 'right', 'top')'s resolved value is the used value if the property
applies to a positioned element. (
https://drafts.csswg.org/cssom/#resolved-values)
Therefore, I think my implementation(
https://bugs.chromium.org/p/chromium/issues/detail?id=601118) is correct.
In this test case(http://jsfiddle.net/xu5b7rLq/6/), bottom and right should
be negative.
What do you think about this issue?
Thank you,
Deokjin Kim
2016-06-01 15:03 GMT+09:00 Myles C. Maxfield <mmaxfi...@apple.com>:
> It looks like WebKit visually renders the result correctly according to
> the spec text. Therefore, we are only interested here with the computed
> style of the over-specified element.
>
> 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.
>
> Do you know if this issue has been discussed in the W3C?
>
> Thanks,
> Myles
>
> On May 27, 2016, at 5:59 AM, 김덕진 <dj0...@gmail.com> wrote:
>
> Hello,
>
> I'm working on blink engine as deokjin81....@samsung.com.
> And I have a question about implementation plan for getComputedStyle.
> 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(
> https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#relative-positioning)
> on blink engine.
>
> 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').
>
> I would like to know Webkit have any plan for this.
>
> Thank you in advance,
> Deokjin Kim
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
