Re: [webkit-dev] getComputedStyle does not handle over-constrained properties correctly

2016-06-21 Thread Myles C. Maxfield 
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  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 
> 
> 
>> On Jun 16, 2016, at 7:38 AM, Deokjin Kim > > wrote:
>> 
>> 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 > >:
>> 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, 김덕진 >> > 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

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] getComputedStyle does not handle over-constrained properties correctly

2016-06-20 Thread Myles C. Maxfield 
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 


> On Jun 16, 2016, at 7:38 AM, Deokjin Kim  wrote:
> 
> 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  >:
> 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, 김덕진 > > 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

Re: [webkit-dev] getComputedStyle does not handle over-constrained properties correctly

2016-06-16 Thread Deokjin Kim 
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 :

> 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, 김덕진  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

Re: [webkit-dev] getComputedStyle does not handle over-constrained properties correctly

2016-06-01 Thread Myles C. Maxfield 
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, 김덕진  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

[webkit-dev] getComputedStyle does not handle over-constrained properties correctly

2016-05-27 Thread 김덕진 
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