<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">The spec has been updated.<div class=""><br class=""></div><div class=""><a href="https://github.com/w3c/csswg-drafts/commit/c996510d75544786a5361127e69c71a5fc725785" class="">https://github.com/w3c/csswg-drafts/commit/c996510d75544786a5361127e69c71a5fc725785</a><div class=""><br class=""></div><div class="">—Myles<br class=""><div><blockquote type="cite" class=""><div class="">On Jun 20, 2016, at 2:26 PM, Myles C. Maxfield <mmaxfield@apple.com> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">—Myles<br class=""><div class=""><div class=""><br class=""></div><div class="">[1] - Microsoft Edge 25.10586.0.0 / Microsoft EdgeHTML 13.10586</div><div class="">- Firefox 50.0a1 (2016-06-20)</div><div class="">- Firefox 47.0</div><div class="">- Chrome 53.0.2773.0 canary</div><div class="">- Chrome 51.0.2704.103</div><div class="">- Safari 9.1.1</div><div class="">- WebKit r202242</div><div class=""><br class=""></div><div class="">[2] <a href="https://github.com/w3c/csswg-drafts/issues/203" class="">https://github.com/w3c/csswg-drafts/issues/203</a></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On Jun 16, 2016, at 7:38 AM, Deokjin Kim <<a href="mailto:dj0152@gmail.com" class="">dj0152@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hello,</div><div class=""><br class=""></div><div class="">I asked this issue and W3C WG said that it means "used value". (<a href="https://github.com/w3c/csswg-drafts/issues/190" class="">https://github.com/w3c/csswg-drafts/issues/190</a>)</div><div class=""><br class=""></div><div class="">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. (<a href="https://drafts.csswg.org/cssom/#resolved-values" class="">https://drafts.csswg.org/cssom/#resolved-values</a>)</div><div class=""><br class=""></div><div class="">Therefore, I think my implementation(<a href="https://bugs.chromium.org/p/chromium/issues/detail?id=601118" target="_blank" class="">https://bugs.chromium.org/p/chromium/issues/detail?id=601118</a>) is correct. In this test case(<a href="http://jsfiddle.net/xu5b7rLq/6/" class="">http://jsfiddle.net/xu5b7rLq/6/</a>), bottom and right should be negative.</div><div class=""><br class=""></div><div class="">What do you think about this issue?</div><div class=""><br class=""></div><div class="">Thank you,</div><div class="">Deokjin Kim</div><div class=""><br class=""></div><div class="gmail_extra"><div class="gmail_quote">2016-06-01 15:03 GMT+09:00 Myles C. Maxfield <span dir="ltr" class=""><<a href="mailto:mmaxfield@apple.com" target="_blank" class="">mmaxfield@apple.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Do you know if this issue has been discussed in the W3C?</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Myles</div><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="h5"><div class="">On May 27, 2016, at 5:59 AM, 김덕진 <<a href="mailto:dj0152@gmail.com" target="_blank" class="">dj0152@gmail.com</a>> wrote:</div><br class=""></div></div><div class=""><div class=""><div class="h5"><div dir="ltr" class="">Hello, <div class=""><br class=""></div><div class="">I'm working on blink engine as <a href="mailto:deokjin81.kim@samsung.com" target="_blank" class="">deokjin81.kim@samsung.com</a>.</div><div class="">And I have a question about implementation plan for getComputedStyle.</div><div class="">As I know, getComputedStyle does not handle over-constrained properties correctly.</div><div class="">So I implemented it(<a href="https://bugs.chromium.org/p/chromium/issues/detail?id=601118" target="_blank" class="">https://bugs.chromium.org/p/chromium/issues/detail?id=601118</a>) according to spec(<a href="https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#relative-positioning" title="" rel="nofollow" style="font-size:11.726px;white-space:pre-wrap;color:rgb(0,0,204);word-wrap:break-word" target="_blank" class="">https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#relative-positioning</a>) on blink engine.</div><div class=""><br class=""></div><div class="">Below paragraphs(from spec) describe detail operation to handle over-constrained properties.</div><div class=""><br class=""></div><div class="">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.<br class=""></div><div class=""><div class=""><br class=""></div><div class="">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').</div></div><div class=""><br class=""></div><div class="">I would like to know Webkit have any plan for this.</div><div class=""><br class=""></div><div class="">Thank you in advance,</div><div class="">Deokjin Kim</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><span style="font-family:sans-serif;font-size:inherit" class=""><br class=""></span></div></div></div></div>
_______________________________________________<br class="">webkit-dev mailing list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" target="_blank" class="">webkit-dev@lists.webkit.org</a><br class=""><a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank" class="">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></div></div></div>_______________________________________________<br class="">webkit-dev mailing list<br class="">webkit-dev@lists.webkit.org<br class="">https://lists.webkit.org/mailman/listinfo/webkit-dev<br class=""></div></blockquote></div><br class=""></div></div></body></html>