Closed Bug 11565 Opened 26 years ago Closed 25 years ago

clip rect() is not compatible with older browsers

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: dbaron, Assigned: troy)

References

Details

(Keywords: css2, css3, Whiteboard: spec clarification needed)

Attachments

(1 file)

patch for nsContainerFrame.cpp and nsFrame.cpp
1.11 KB, text/plain
Details
I'm assigning this to Peter since he's probably the one who should decide what needs to happen here, and then he can decide whether to mark invalid or give to someone else. What follows is basically pasted from an email message I sent to Troy. Currently you support clip rect() values as described in the CSS spec. NN4, IE4, and IE5 all support them the other way around, I think. This problem is described in [1], where Bert Bos said that CSS might be changed to match the legacy behavior. In [2] Tantek Celik agreed with me that rect() might be renamed to something else - so you shouldn't delete the code for the current implementaton! Your current rendering is correct per CSS2, but disagrees with most/all existing browsers and may disagree with CSS3. [1] http://lists.w3.org/Archives/Public/www-style/1999Jun/0054.html [2] http://lists.w3.org/Archives/Public/www-style/1999Jul/0014.html (also see 0013 and 0015)
Status: NEW → ASSIGNED
Ah yes, it was decided in the w/g to revert the behavior of rect() to that described in the original CSSP w/d. And to re-introduce the behavior described by CSS2 under a new function name in CSS3. I need to add some state in the style context telling us how to interpret the clip info, then we need to add the other behavior also.
OS: other → All
Hardware: Other → All
Blocks: 11559
Peter, adding to this the issue of whether the clip rect is relative to the border edge, padding edge, or content edge. Also adding that bug #11559 depends on this bug
Moving non-beta 1 items to M15
QA Contact: petersen → chrisd
Summary: clip rect() is not compatible with older browsers → {css2} {css3} clip rect() is not compatible with older browsers
Reassigning peterl's bugs to myself.
Accepting peterl's bugs that have a Target Milestone
FYI: the current behavior, which is conform to the spec, has been in effect after bug 9282 was fixed by Kipp on 05-jul-99 in nsFrame.cpp v3.117.
I asked Troy: > Was there anything decided about 'clip' at the working-group? > Should we still interpret rect(0,100%,100%,0) as completely > invisible instead of completely visible and unlike what the > current browsers have implemented? It was decided that clip should behave as defined in the positioning working draft and as implemented by Navigator and IE, i.e., not as defined by the CSS2 spec We shouldn't delete the existing code we have because it's likely CSS3 will add another type of clip rect, call it insetClip for example, that behaves the way the current CSS2 spec defines
Pushing my M15 bugs to M16
Blocks: 22537
Keywords: css2
Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz} radars should now be considered deprecated in favour of keywords. I am *really* sorry about the spam...
Keywords: css3
Summary: {css2} {css3} clip rect() is not compatible with older browsers → clip rect() is not compatible with older browsers
Blocks: 10915
This issue is currently under consideration by the W3C CSS WG.
No longer blocks: 10915
Whiteboard: spec clarification needed
Target Milestone: M16 → M20
Notice that at the end of the CSS2 errata, this change officially has working draft status. See http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html
I'm going to attach a patch that makes ClipRect work like in the older browsers and as described in the CSS2 errata. Problem: I can't check in that code because it breaks the dropdown lists, the selected item doesn't show. Reassigned to rods. Rod: could you install that patch and make the dropdown lists work with it? When it's done, you can either checkin everything, or send me back your changes and I'll do the checkin after some more testing. Thanks.
Assignee: pierre → rods
Status: ASSIGNED → NEW
Text fields too show some problems if the clipping is reverted to the legacy behavior: when a page is first displayed, you have to click on the text fields to see their contents. You can try it on any Bugzilla bug page.
Whoa, I am not touching clipping for nsFrame and ContainerFrame. That is for Troy or Buster. Reassigning to Troy, cc me.
Assignee: rods → troy
Rod, pierre isn't asking you to make changes to nsFrame and nsContainerFrame. The problem is that when he fixes the clip rect the dropdown lists no longer work (the selected item doesn't show). Did you take a look at that problem? > Rod: could you install that patch and make the dropdown lists work with it? > When it's done, you can either checkin everything, or send me back your > changes and I'll do the checkin after some more testing. Thanks.
Assignee: troy → rods
Rod- if you can make the dropdown lists work with the attached patched, just send me back your changes. I'll do much more testing and digging before checking in... and take the heat if something's broken.
Nominating for beta2 since this is reasonably important for backwards and IE-wards compatibility. It *must* be fixed by FCS, but I think it would be a good idea to get it in for beta2, since I expect people will complain if it changes at the last minute (and about the current behavior).
Keywords: nsbeta2
Troy fixed the clipping per the CSS2 errata last week. Obviously the dropdown lists are still working correctly so this bug is a bit moot. Reassigning to Troy and marking fixed.
Assignee: rods → troy
Fixed
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I have run into a major problem with this bug that I am hoping one of you can help me with. I have a Mozilla demo site called Gecko's Realm (http://www.narain.com/gecko/) The home page combines the clip property with a little JavaScript to create pseudo-transition special effects. The clip property is constructed as per the CSS2 specifications. Viewing the site with Netscape 6.0 PR1 or any *pre-April 27* build, you will see that everything works the way it is supposed to. The moment things went wrong for my site occured when this bug was "fixed". Viewing the site with any *post-April 27* build you will see (or more accurately not see) any of the transitional effects. I feel there is a connection between this bug and the problems I am having. Pierre Saslawsky wrote on 1999-11-12 08:26: >We shouldn't delete the existing code we have because it's likely CSS3 will add >another type of clip rect, call it insetClip for example, that behaves the way >the current CSS2 spec defines If the existing code has not been deleted, my site should be working as normal. If the code is really there, then the problem exists in the DOM. When the "new" clip was introduced into Mozilla, where changes made to the DOM which might be causing this problem??? PS - I feel this bug should be re-opened but I can't do it via Bugzilla because the only option given to me is "Leave as RESOLVED FIXED". Is there another way???
Make sure you are using the definition of rect as given at the bottom of this page: http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html
My code is in compliance with the original CSS2 specs, not the errata. But the errata states "... may not be considered definitive unless incorporated into a revised Recommendation." So strictly speaking, the code I have is valid.
Right. But we are implementing the draft revision, because that is what IE5 has implemented and it is diametrically opposed to the spec, and people seem to expect it to work that way. I suggest asking on www-style@w3.org if you have any questions about which way this is going to go...
>But we are implementing the draft revision If Mozilla wants to incorporate the draft definition, it's fine by me. But I was under the impression, after reading previous comments within this report, that *BOTH* definitions will be supported. Pierre made the point that CSS3 will have some new stuff that will be based on the original CSS2 definition. So this seems to be in conflict with the current draft revision that we are going with. Is it not possible for both definitions to co-exist??? I'm talking about something along the lines of strict vs quirk mode. If it's possible we cover all our bases and everybodies happy :-) The bottom line is that my code is in 100% compliance with the current standards and I feel that Mozilla should render them correctly.
Whta pierre meant is that we will introduce a new keyword, say "sides()", that acts like the old "rect()" did. But we need the WG to decide what that will be called before we can do so.
Correct. Last I heard from the WG, the issue is settled for clip: we are going to use the old (IE) interpretation. We don't have a syntax yet AFAIK for the new behavior.
Thank you Ian and Pierre for clearing up my misunderstanding :-) I have changed the code at my site to comply with the errata, but in doing so have stumbled upon two rather nasty bugs. One deals with the DOM while the other is a re-paint problem. I'll post new reports for these two.
Verified fixed
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: