521 bytes, text/html
508 bytes, text/html
The 'clip' property seems to work fine on Windows 2000, but on Linux and Macs it just hides everything when set. Tested with the 2000090608 comm builds. See testcase. Nominating for nsbeta3 as this is a *major* bug with our clip support (it basically kills the clip property in fact), and it works fine on one third of our tier 1 platforms.
Created attachment 14167 [details] Simple and self explanatory testcase. Output should be green, not red.
cc'ing beard, kevin, robert -- this is a major platform parity bug with clip. Do we know about it? Is it a problem with the GFX layer? Can we fix it? ;-)
I'm getting the following assertions on WinNT and Linux when viewing the testcase: ###!!! ASSERTION: bad clip values: 'aLeft <= aRight && aTop <= aBottom', file s:\mozilla\view\src\nsView.cpp, line 654 ###!!! ASSERTION: bad clip values: 'aLeft <= aRight && aTop <= aBottom', file s:\mozilla\view\src\nsView.cpp, line 654 After, the rendering is correct on NT and wrong on Linux. Sending to Kevin to check out - it seems like a platform-specific clipping problem to me...
The clip: property does not appear until css2. Changing css1 keyword to css2 The current implementation on WIN32 is working but the interpretation of the rect values appears to be incorrect. The spec indicates that the rect specifies offsets from the outside of the box. The WIN32 implementation is interpreting the rect values as rect(left, top, width, height).
The behavior has been changed. Check the CSS2 errata. I think Mozilla's interpretation is now correct WRT the errata, and it's "rect(top, right, bottom, left)". That's was a rather dumb move if you ask me, but no-one did :-).
I believe that, in fact, this testcase is invalid. I'll attach another testcase...
Thanks Robert: I see that we DO match the CSS2 errata, and the original test case is incorrect. With your new test case it works correctly on both WIN32 and Linux.
Changing summary from: clip: rect(...) hides everything on Linux and Macs to: clip: rect(...) property with bad values is inconsistent between platforms I could condition the rect in nsView::SetChildClip so it behaves consistently between platforms, but firstname.lastname@example.org wants to look at the possibility of catching the bad values when the property is parsed (This would allow us to provide feedback to the author) Changed component to Style System. Marking nsbeta3-. Reassigning to email@example.com
I need to look at the CSS requirements on parsing a rect - namely, can we enforce that the rect never has a negative height or width, or does each property have its own independent restrictions? In either case, the CSSParser can deal with illegal rect values (per property if required) and can throw the rule away.
Added relnote keyword.
Cleaning up the keywords, priority, severity, and platforms. In particular, I removed the dataloss keyword because we don't lose data if the rect is valid.
bah, the spec changes so often that I got all confused!!! Sorry about that.
Moving out to future: still need to investigate to see if this is INVALID or not, but later.
Adding myself to cc. Since that in all platforms I have tested since and including Netscape 6, Mozilla clip:rect property is not working. All becomes invisible. Not tested with Win2000. But all pages with style="clip:rect(,,,,)" are not working. My note is here because I am investigating workaround, if you know some workaround please e-mail me. Working on a document to help web developers make pages with clipping in Netscape 6 and Mozillas.
Thanks Robert and sorry to all, my last comments I was not updated with the Errata and right now I am tuned and also saw Robert's notes about the CSS errata. I am updating all demostrations that are published at http://www.mozilla.org/docs/dom/samples/ that are using CSS clip, because it looks like there is a problem with clip. I'll be evangelizing at geckonnection.com also about the correct way to use clip.
IIUC, the content author workaround for this bug is simply to avoid using incorrect values, yes? Not nominating for nsbeta1 based on this assumption; please nominate for nsbeta1 if I've misunderstood this.
> but firstname.lastname@example.org wants to look at the possibility of catching the bad > values when the property is parsed That's impossible to do since the rect validity depends on things like the computed font size if relative size units are used. Perhaps the layout code that actually sets the clip rect could look at the computed values and set the rect's size to 0 if rect.IsEmpty() tests true?
The behavior here should be consistent now. Could someone test on Linux?