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




19 years ago
18 years ago


(Reporter: scollick, Assigned: attinasi)



Windows NT

Firefox Tracking Flags

(Not tracked)




(2 attachments)



19 years ago
In rendering 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.

Comment 1

19 years ago
Created attachment 2918 [details]


19 years ago
Whiteboard: [TESTCASE]

Comment 2

19 years ago
The problem seems to be the ":active" style.

Comment 3

19 years ago
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.

<body onload="myfn()">
<div id="l0" style="position:absolute; visibility:hidden;">
<table border=0>

<script language="JavaScript" type="text/javascript">
function myfn() {
  var lyr=document.getElementById("l0").style;
  lyr.width = 138; lyr.height = 10;
  lyr.visibility = "visible";


19 years ago
Assignee: karnaze → pierre

Comment 4

19 years ago
Pierre, can you take a look at the attachment. Start by clicking outside of
everything and notice that the text changes color.


19 years ago
Target Milestone: M14

Comment 5

19 years ago
It looks like the table gets the style that should have been applied to the edit
field. M14.


19 years ago
Target Milestone: M14 → M15

Comment 6

19 years ago
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

Comment 8

19 years ago
Block-moved to attinasi the bugs related to style inside tables
Assignee: pierre → attinasi


19 years ago

Comment 9

19 years ago
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 
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]

Comment 10

19 years ago
Created attachment 6580 [details]
pseudo-class selector problem illuminated

Comment 11

19 years ago
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 

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.)

Comment 13

19 years ago
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

Comment 14

19 years ago
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...)

Comment 16

19 years ago
In quirks mode the global pseudos are restricted to leaf-elements now. In 
standard mode, no change (bug 5693 still exists).
Last Resolved: 19 years ago
Resolution: --- → FIXED
By leaf elements, you mean a certain list of elements, right?  (An A element
isn't always a leaf element.)

Comment 18

19 years ago
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
You need to log in before you can comment on or make changes to this bug.