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)
Tracking
()
VERIFIED
FIXED
M15
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.
Comment 1•25 years ago
|
||
Updated•25 years ago
|
Whiteboard: [TESTCASE]
Comment 2•25 years ago
|
||
The problem seems to be the ":active" style.
Comment 3•25 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.
<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>
Updated•25 years ago
|
Assignee: karnaze → pierre
Comment 4•25 years ago
|
||
Pierre, can you take a look at the attachment. Start by clicking outside of
everything and notice that the text changes color.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M14
Comment 5•25 years ago
|
||
It looks like the table gets the style that should have been applied to the edit
field. M14.
Updated•25 years ago
|
Target Milestone: M14 → M15
Comment 6•25 years ago
|
||
Moving table bugs to M15 just to see how many we have.
Comment 7•25 years ago
|
||
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Comment 8•25 years ago
|
||
Block-moved to attinasi the bugs related to style inside tables
Assignee: pierre → attinasi
Status: ASSIGNED → NEW
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 9•25 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
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]
Assignee | ||
Comment 10•25 years ago
|
||
Assignee | ||
Comment 11•25 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
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.)
Keywords: css2
Assignee | ||
Comment 13•25 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
Assignee | ||
Comment 14•25 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
Assignee | ||
Comment 16•25 years ago
|
||
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.)
Assignee | ||
Comment 18•25 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)
);
Comment 19•24 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•