535622 - CSS rules without declarations should be ignored by the style system

Status: RESOLVED WONTFIX

(Core :: CSS Parsing and Computation, defect)

Description

[Kai de Leeuw]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091217 Minefield/3.7a1pre
Build Identifier: 

In bug 535618 the issue is that a non matching sibling selector makes the performance of a page adding many elements dynamically terribly slow.

I think I am correct in my assumption that a CSS clause without styles is of no use to anyone and therefore should be ignored by the style system.

The following CSS clause makes several problems in our project:
.service-unit #content #primary .unit-type h3 + div{
}

1. It doesn't match any element but still affects the page performance
2. It doesn't add any style and should therefore be completely ignored, but as it is now it is considered and harms performance

Reproducible: Always

Comment 1

[Boris Zbarsky [:bzbarsky]]

This seems like a very rare edge case.  In practice, I doubt empty style rules appear much, if ever, so slowing everything down a bit by checking for them doesn't seem worth it.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Checking in CascadeRuleEnumFunc probably wouldn't be that bad; I actually thought we already did.

Rules that contain only properties we don't understand might not be all that much of an edge case.



However, the bigger problem is that if we ever exposed an API to show what rules matched, we'd either have to rerun matching for that API or we'd have to remove this optimization.  I think such an API is probably more important.

Comment 3

[Kai de Leeuw]

(In reply to comment #2)
> However, the bigger problem is that if we ever exposed an API to show what
> rules matched, we'd either have to rerun matching for that API or we'd have to
> remove this optimization.  I think such an API is probably more important.

Wouldn't the solution to that be having a bit indicating whether the rule matched? If we already keep the rule in memory that shouldn't be adding much overhead, if any.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> Wouldn't the solution to that be having a bit indicating whether the rule
> matched?

Sure, but then you have the performance problems you were apparently trying to avoid, since you have to maintain the state of that bit.

Comment 5

[Boris Zbarsky [:bzbarsky]]

In any case, I'd rather fix the real underlying problem (which means wanting a testcase in bug 535618) than add hackarounds.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Marking as wontfix.