Skip to content

Conversation

@oliverklee
Copy link
Collaborator

This constructor parameter is not used, and having the specificity calculation always done lazily is not a problem.

@coveralls
Copy link

coveralls commented Feb 27, 2025

Coverage Status

coverage: 54.655%. remained the same
when pulling b2e2267 on task/deprecate/selector-specificity
into a06211d on main.

@oliverklee oliverklee force-pushed the task/deprecate/selector-specificity branch from 69278ac to b2c5b62 Compare February 27, 2025 11:16
This constructor parameter is not used, and having the
specificity calculation always done lazily is not a problem.
@oliverklee oliverklee force-pushed the task/deprecate/selector-specificity branch from b2c5b62 to b2e2267 Compare February 27, 2025 11:19
Copy link
Collaborator

@JakeQZ JakeQZ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, it can be done on first-time access without loss of performance.

@JakeQZ JakeQZ merged commit e0392d0 into main Feb 27, 2025
21 checks passed
@JakeQZ JakeQZ deleted the task/deprecate/selector-specificity branch February 27, 2025 11:47
oliverklee added a commit that referenced this pull request Feb 27, 2025
This constructor parameter is not used, and having the
specificity calculation always done lazily is not a problem.

This is the V8.x backport of #1018.
JakeQZ pushed a commit that referenced this pull request Feb 27, 2025
This constructor parameter will no longer be used;
having the specificity calculation always done lazily is not a problem.

This is the V8.x backport of #1018.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants