Bug 20454 – getPropertyValue() for clip returns wrong value

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: CSS

[Garrett Smith]

When reading clip value using getComputedValue, the wrong value is returned. 

The clip value should be returned, but instead, if the element is not clipped, all 0's are returned.

See also: Bug 17433

[Garrett Smith]

Created attachment 22884 [details]
Testcase showing problem

[Mark Rowe (bdash)]

<rdar://problem/6160816>

[Jeffery To]

Can someone have a look at this bug? As it stands, it is impossible to tell (from JavaScript) whether an element is visible or completely clipped.

Currently, when an element has no "clip" CSS declaration, getComputedStyle correctly returns "auto". ("auto" meaning the element is not clipped)

But when an element has "clip: auto" or "clip: rect(auto, auto, auto, auto)", getComputedStyle returns "rect(0px 0px 0px 0px)". This is a valid clip value, but this value means the element is completely clipped.

[Jeffery To]

In other words, when I get "rect(0px 0px 0px 0px)" from getComputedStyle, I can't tell if the clip value is actually "auto" and the element is visible, or if the clip value is "rect(0px 0px 0px 0px)" and the element is completely clipped.

[Garrett Smith]

(In reply to comment #4)
> In other words, when I get "rect(0px 0px 0px 0px)" from getComputedStyle, I can't tell if the clip value is actually "auto" and the element is visible, or if the clip value is "rect(0px 0px 0px 0px)" and the element is completely clipped.

That was what they called a "fix" for bug 17433. See bug 17433 comment 2. The problem is demonstrated in this bug, to attachment 22884 [details].

What Gecko does is to return "auto" which is different than a rect value, but the CSS 2.1 spec specifies a rect value. This makes sense and fortunately now too does CSS 2.1, which standardizes this behavior.

| Computed value:  'auto' if specified as 'auto', 
| otherwise a rectangle with four values, each of 
| which is 'auto' if specified as 'auto' and the 
| computed length otherwise

[Garrett Smith]

(In reply to comment #5)
> (In reply to comment #4)
> > In other words, when I get "rect(0px 0px 0px 0px)" from getComputedStyle, I can't tell if the clip value is actually "auto" and the element is visible, or if the clip value is "rect(0px 0px 0px 0px)" and the element is completely clipped.
> 
> That was what they called a "fix" for bug 17433. See bug 17433 comment 2. The problem is demonstrated in this bug, to attachment 22884 [details].
> 
> What Gecko does is to return "auto" which is different than a rect value, but the CSS 2.1 spec specifies a rect value. 

Correction: previous version of CSS 2.1 specified that clip computed style must be a rect. The current version of CSS 2.1 matches what Gecko does and returns "auto" when clip is "auto". Again:
> 
> | Computed value:  'auto' if specified as 'auto', 
> | otherwise a rectangle with four values, each of 
> | which is 'auto' if specified as 'auto' and the 
> | computed length otherwise

[Mike Petrovich]

We're rewriting a lot of core effects in jQuery UI to use the CSS clip property, and being able to differentiate between "clip: rect(auto, auto, auto, auto)" and "clip: rect(0px, 0px, 0px, 0px)" is needed for a complete and correct implementation with Webkit browsers.

Has there been any progress towards a resolution or workaround for this issue?

[Ahmad Saleem]

I am unable to reproduce this bug using attached test case in Safari 15.6 on macOS 12.5 and it shows "green background" on text with blue border and I zoomed into find any clipping but I was not able to find. Also it matches with other browsers (Chrome Canary 106 and Firefox Nightly 105). I think this can be marked as "RESOLVED CONFIGURATION CHANGED". Thanks!