CSS rules without declarations should be ignored by the style system

RESOLVED WONTFIX

Status

()

Core
CSS Parsing and Computation
RESOLVED WONTFIX
9 years ago
9 years ago

People

(Reporter: Kai de Leeuw, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
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
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.
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.
Summary: CSS clauses without styles should be ignored by the style system → CSS rules without declarations should be ignored by the style system
(Reporter)

Comment 3

9 years ago
(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.
> 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.
In any case, I'd rather fix the real underlying problem (which means wanting a testcase in bug 535618) than add hackarounds.
Marking as wontfix.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.