[webkit-dev] getComputedStyle does not handle over-constrained properties correctly
dj0152 at gmail.com
Thu Jun 16 07:38:47 PDT 2016
I asked this issue and W3C WG said that it means "used value". (
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. (
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
What do you think about this issue?
2016-06-01 15:03 GMT+09:00 Myles C. Maxfield <mmaxfield at 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?
> On May 27, 2016, at 5:59 AM, 김덕진 <dj0152 at gmail.com> wrote:
> I'm working on blink engine as deokjin81.kim at samsung.com.
> And I have a question about implementation plan for getComputedStyle.
> As I know, getComputedStyle does not handle over-constrained properties
> So I implemented it(
> https://bugs.chromium.org/p/chromium/issues/detail?id=601118) according
> to spec(
> 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 at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev