Closed Bug 19046 Opened 25 years ago Closed 25 years ago

Pseudo-class selectors with no subject are not working correctly in Quirks Mode

Categories

(Core :: CSS Parsing and Computation, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: scollick, Assigned: attinasi)

References

()

Details

(Keywords: css2)

Attachments

(2 files)

In rendering http://www.theatredb.com the table borders appear randomly on the page even though all table borders are set to zero. This occurs on all pages (plain HTML and CGI created pages) in this site. What's even weirder is that if I click on random areas of the screen the borders will "shift" in that some will disappear and others will appear in another place. Sometimes a page will appear without the table borders, but if I click the scroll bar or a random place on the page, they appear again. This is the only web site I've found where this occurs. I do know that there are nested tables on each of the pages, but I've gone to other pages with nested tables without problems. I've only been able to test the NT release of Mozilla M11, and don't know if this problem exists on other platforms.
Attached file testcase
Whiteboard: [TESTCASE]
The problem seems to be the ":active" style.
This also happens with the following File (should be a bit easier to debug). Btw, if you remove "visibility:hidden" and/or the layer positioning in the JavaScript, the table appears correctly. <html> <body onload="myfn()"> <div id="l0" style="position:absolute; visibility:hidden;"> <table border=0> <tr><td>Blah</td><td>Blub</td></tr> </table> </div> <script language="JavaScript" type="text/javascript"> function myfn() { var lyr=document.getElementById("l0").style; lyr.width = 138; lyr.height = 10; lyr.visibility = "visible"; } </script> </body> </html>
Assignee: karnaze → pierre
Pierre, can you take a look at the attachment. Start by clicking outside of everything and notice that the text changes color.
Status: NEW → ASSIGNED
Target Milestone: M14
It looks like the table gets the style that should have been applied to the edit field. M14.
Target Milestone: M14 → M15
Moving table bugs to M15 just to see how many we have.
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Block-moved to attinasi the bugs related to style inside tables
Assignee: pierre → attinasi
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
The problem of the table borders coming and going is no longer apparent (I'm pretty sure karnaze and myself fixed this several weeks ago). There is a nast problem that karnaze mentioned on 1999-12-17 11:28 where clicking in open-space causes text to change colors. This is a real bug and I have narrowed it down to a problem with pseudo-class selectors with no selector subject, like ':active' instead of 'A:active'. We are matching *everything* it appears in this case... I will attach a test case for this bug, and I'm chaning the summary to reflect the issue. Reiterating: The old issue about the table border=0 causing borders to appear is resolved.
Keywords: testcase
Summary: Table borders appear even though the border is set to zero. → Pseudo-class selectors with no subject are not working correctly
Whiteboard: [TESTCASE]
I have a fix that restricts global :active, :focus, :dragOver and :hover pseudo classes to apply to the following elements: a, button, img, input, li, label, select, textarea and also the internally created textPseudo and textTagName. If the rule selector is not global, meaning it has a subject, then there is no restriction. for example, if the rule is written as: :hover {color:blue} // global then it can only apply to elements of the type listed above. If, however, the rule is written as: div:hover {color:blue} // subjected then it is applied to all DIV elements (even though they are not supported for global event pseudo class selectors). This fixes the majority of the problems with the :active, :hover and :focus selectors with no subject. There are still some problems where textarea and input type=text and type=password fields do not respond correctly to the hover because the events are not fired, but this will have to be dealt with seperately. Furthermore, it still allows for the most flexibility when a designer specifies the subject, notably supporing containers as well as the normal leaf-elements.
So you know, bug 5693 has been open on this subject for ages... I think your solution might be necessary for quirks mode. However, in standard mode, the pseudos should work correctly. (Note that :active and :focus may be changed by the CSS3 UI draft, but :hover will note.)
Thanks for making the point David. This change should be for Quirk mode only. In Standard mode, if an author wants a global rule to apply to every element on the page then they can have it. This change is to help for existing pages that rely on the :hover and :active rules applying only to a small subset of elements (links).
Component: HTMLTables → Style System
Updating summary to reflect Quirkage
Summary: Pseudo-class selectors with no subject are not working correctly → Pseudo-class selectors with no subject are not working correctly in Quirks Mode
They're not working correctly in standard mode either, unless it's been fixed very recently. That's what bug 5693 has been about, although it might not have the right owner. (I don't know why Ian changed the title of bug 5693...)
In quirks mode the global pseudos are restricted to leaf-elements now. In standard mode, no change (bug 5693 still exists).
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
By leaf elements, you mean a certain list of elements, right? (An A element isn't always a leaf element.)
Yes, you are correct, I was beeing lazy with my description. here are the elements that support global event pseudo selectors in NavQuirks mode (extracted from the code): return PRBool ((nsHTMLAtoms::a == aContentTag) || (nsHTMLAtoms::button == aContentTag) || (nsHTMLAtoms::img == aContentTag) || (nsHTMLAtoms::input == aContentTag) || (nsHTMLAtoms::li == aContentTag) || (nsHTMLAtoms::label == aContentTag) || (nsHTMLAtoms::select == aContentTag) || (nsHTMLAtoms::textarea == aContentTag) || (nsHTMLAtoms::textPseudo == aContentTag) || // We require a Layout Atom too (nsLayoutAtoms::textTagName == aContentTag) );
Netscape's standard compliance QA team reorganised itself once again, so taking remaining non-tables style bugs. Sorry about the spam. I tried to get this done directly at the database level, but apparently that is "not easy because of the shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian
quirk now exists
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: