The spec has been updated. https://github.com/w3c/csswg-drafts/commit/c996510d75544786a5361127e69c71a5fc725785
—Myles > On Jun 20, 2016, at 2:26 PM, Myles C. Maxfield <mmaxfi...@apple.com> wrote: > > All stable and nightly browsers that I could find[1] agree on the return of > getComputedStyle() in this situation. Therefore, I opened this issue[2] to > update the spec to match the implementations. > > —Myles > > [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 > > [2] https://github.com/w3c/csswg-drafts/issues/203 > <https://github.com/w3c/csswg-drafts/issues/203> > >> On Jun 16, 2016, at 7:38 AM, Deokjin Kim <dj0...@gmail.com >> <mailto:dj0...@gmail.com>> wrote: >> >> Hello, >> >> I asked this issue and W3C WG said that it means "used value". >> (https://github.com/w3c/csswg-drafts/issues/190 >> <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 >> <https://drafts.csswg.org/cssom/#resolved-values>) >> >> Therefore, I think my >> implementation(https://bugs.chromium.org/p/chromium/issues/detail?id=601118 >> <https://bugs.chromium.org/p/chromium/issues/detail?id=601118>) is correct. >> In this test case(http://jsfiddle.net/xu5b7rLq/6/ >> <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 >> <mailto: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 >>> <mailto:dj0...@gmail.com>> wrote: >>> >>> Hello, >>> >>> I'm working on blink engine as deokjin81....@samsung.com >>> <mailto: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 >>> <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 >>> >>> <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 <mailto:webkit-dev@lists.webkit.org> >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>> <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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
