A default namespace declared in a stylesheet whould be applied to all selectors that do not have their own namespace declaration. ID, Class, :psuedoclass and attribute selectors are not getting the default namespace set and are always considered to have the 'unknown' namespace. This is really really bad, as the namespace is suppossed to restrict the application of the rule, and selectors that are assigned the 'unknown' namespace are applied to elements in all namespaces. The root of the problem is in CSSParserImpl::ParseSelector where the namespace is generally applied to the selector. See bug 53620, where this was first discovered.

Accepting: see the patch in bug 53620

This was actually first discovered in bug 35847. Note that if you fix this, you should change the html.css file to replace every occurance of an implied universal selector with '*|*'. That's right, this will *not* fix bug 53620. More comments in that bug.

Marking future: we will fix this after RTM of NS6.

RELEASE NOTE ITEM: When used in conjunction with the proposed CSS3 namespace selectors, simple selectors that do not include a universal selector or a type selector will be erroneously assumed to match elements in namespaces, instead of only the default namespace. Workaround: explicitly give the universal selector in those cases as recommended by the CSS Specification. For example, instead of: @namespace url(http://www.w3.org/1999/xhtml); :link, :visited { text-decoration: underline; } ...which would also match X-Links, you should use: @namespace url(http://www.w3.org/1999/xhtml); *:link, *:visited { text-decoration: underline; } ...which will correctly match only HTML links (<a>, <area>, and <link>).

Failure to apply namespaces causes pseudo-class rules from html.css and quirks.css to be applied to all XUL elements. This results in a ~5% overhead while scrolling in the mailnews threadpane, for example. Marking "perf".

Even if we want to continue to apply :link rules to all namespaces, shouldn't we put the universal selector in front of the other pseudos in html.css and quirk.css to keep them from being applied to non-HTML namespaces until this gets fixed? It would help speed up XUL performance a bit, I imagine.

yes, I agree. Let's patch the others.

Can somebody profile with the '*' in front of the :psuedos (except :link and :visited rules) and see if it help performance enough to get approval for the change?

I think everybody agrees that it is a good thing which cannot hurt. Attach a patch, you will have 4 enthusiastic reviewers and possibly an approval.

Somebody put a patch into the bug and I will profile, etc.

I've attached a patch that puts a universal selector on all of the pseudo-selectors execpt the :link and :visited selectors. It is worth checking that none of those need to apply outside of the html namespace, I could not be sure. I need to test it more thoroughly tomorrow, but I put it up for review and profiling now anyway.

This is IMHO an extremely high risk change. First of all, we cannot place all the table pseudo-ELEMENTS into the HTML namespace, as this would kill CSS tables in XML on the spot, assuming our implementation is as I imagine it to be. Similarly for :-moz-list-bullet. We cannot put the :-moz-singleline-textcontrol-frame into the HTML namespace, as the code itself doesn't consider it to be HTML (see bug 35847). I would guess that the other form element pseudo-ELEMENT rules have the same problem. :-moz-command and :-moz-pi are DEFINITELY not only going to appear in HTML. In fact, I can't see how :-moz-pi will ever be in the HTML namespace at all! Similarly with the viewport, canvas, page and *-frame psuedos, are they really in the HTML namespace?? That would surprise me. (In the case of the quirk stylesheet, and in the case of the case of the quirk stylesheet _only_, r=ianh. The elements covered by the quirks stylesheet can only be in the HTML namespace, by definition.)

Another possibility is to break out all the pseudo-elements into a separate stylesheet, and we make sure the stylesheet isn't loaded by XUL. BTW, things like this are the reason hierarchical hover had to be turned off. 5% in IsSimpleXLink, 10% examining all the pseudos... now imagine you have to do that on every parent in a chain as you move around, and you see why hierarchical hover kicked our ass. We have to make pseudos faster. We need some way of providing a hint that the pseudo is irrelevant for certain tags or something, so that we can quickly ignore them for those tags we know don't care about any of the pseudos.

Hmmm. A can of worms, just as I feared. We need to muck through this soup of rules slowly and carefully, eh? Thanks for the detailed analysis, Ian. Sorry I threw that patch out so hastily.

We should split pseudo-elements and pseudo-classes up into two buckets. We can then skip the pseudo-elements for all cases except when we are trying to match a pseudo-element frame.

Thanks for the idea, Ian. It deserves more thought than I can afford it right now...

For the record, I'm just repeating something Peter Linss told me around 18 months ago... ;-)

Targeting for M0.8

Is this a dup of bug 62895 or of bug 35847? This bug has gotten very confused, assuming one of the above is indeed what this bug morphed into, I strongly recommend we mark this of a duplicate and start working on a solution in the respective other bug.

This is actually a dup of bug 35847 - no sense in having two bugs on the same problem... *** This bug has been marked as a duplicate of 35847 ***

*** Bug 61244 has been marked as a duplicate of this bug. ***

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

VERIF DUP