Re: Proposal: CSS `specificity` Property for Explicit Selector Weight

I do understand the highlighted issues but CSS properties apply to selected elements or pseudo-elements and do not affect the selector(s) selecting these elements.
That’s why each property definition includes a « Applies to » line.
Furthermore, you say, I quote, that 'developers must manually calculate specificity scores’; I think your proposal is going to increase the problem instead of fixing it, let me explain...
Imagine a sheet of 2 rules. First rule does not set your specificity property. Second rule, with exact same selector as 1st one, sets it to a specificity different from the selector’s one.
Developers reading only the first rule cannot have any idea reading it that the selector’s specificity is not the right one.
Ok, you could say that the developer can also easily read the second rule… Now imagine 100 rules between these two ones. Dang!

Best regards,

Daniel



> Le 12 août 2025 à 18:06, José Arturo Cano Melani <jose@activisual.net> a écrit :
> 
> Hi CSSWG,
> 
> I propose a new CSS property, `specificity`, to allow developers to explicitly set a selector's weight, addressing the pain points of the current specificity system that force artificial selector conditions.
> 
> Problem
> -------
> The current CSS specificity system (IDs=100, classes=10, elements=1) often requires developers to use hacks to achieve desired precedence, such as:
> - Repeating classes (e.g., `td.status.status.status` for 0-3-1) to override selectors like `.table td.status` (0-1-1).
> - Adding artificial selectors (e.g., `#dummy`, `.body .table td.status`) to boost specificity.
> - Overusing `!important`, which creates maintenance issues and lacks granularity.
> 
> These practices lead to:
> - Unmaintainable, verbose CSS that obscures intent.
> - Semantic noise from meaningless selector chains.
> - Debugging challenges, as developers must manually calculate specificity scores.
> - Escalating specificity wars in large or legacy codebases.
> 
> Proposed Solution
> -----------------
> Introduce a `specificity` property to set a selector's weight directly:
> 
>   td.status {
>     specificity: 300;
>     border: solid 1px blue;
>   }
> 
> - Value: `<integer>` (non-negative, e.g., 300 = three classes) or `auto` (default, uses traditional specificity).
> - Applies to: All elements.
> - Computed value: As specified.
> - Cascade: Overrides the selector's calculated specificity in the cascade algorithm.
> 
> Examples
> --------
> 1. Override a more specific selector:
>    .table td.status { /* Specificity: 0-1-1 = 110 */
>      border: solid 1px red;
>    }
>    td.status { /* Specificity: 300 */
>      specificity: 300;
>      border: solid 1px blue;
>    }
>    Result: `td.status` wins without hacks like `td.status.status.status`..
> 
> 2. Fine-grained control:
>    td.status { /* Specificity: 200 */
>      specificity: 200;
>      border: solid 1px blue;
>    }
>    .table td.status { /* Specificity: 0-1-1 = 110 */
>      border: solid 1px red;
>    }
>    Result: `td.status` overrides without artificial selectors.
> 
> Benefits
> --------
> - Eliminates hacks like class repetition or dummy IDs.
> - Simplifies debugging by making specificity explicit.
> - Offers precise control without altering selector semantics.
> - Complements `@layer` and `@scope` for comprehensive cascade management.
> 
> Challenges and Mitigations
> -------------------------
> 1. Backward Compatibility:
>    - Default to `auto` for traditional specificity.
>    - Unsupported browsers ignore `specificity`, falling back to standard rules.
>    - Use `@supports` for progressive enhancement.
> 
> 2. Potential Abuse:
>    - Cap maximum value (e.g., 10000) to prevent excessive weights.
>    - Encourage `@layer` for large-scale priority management.
> 
> 3. Implementation:
>    - Treat `specificity` as an override to calculated specificity, applied before cascade resolution.
>    - Display in DevTools alongside traditional specificity scores.
> 
> Integration with Cascade
> -----------------------
> - Sort rules by origin and importance (`!important` vs. non-`!important`).
> - Within each group, use `specificity` property (if set) or traditional specificity.
> - Resolve ties by source order.
> 
> Prior Art
> ---------
> - Issue #5057 (Selector Boundary): Related but focuses on selector matching, not explicit weights.
> - `@layer`: Manages group priority, not individual selectors.
> - `:is()`/`:where()`: Adjusts specificity indirectly, not numerically.
> 
> Call to Action
> --------------
> I propose adding `specificity` to CSS Cascade Level 6 or a new spec. Seeking feedback on:
> - Syntax (`specificity` vs. `weight`/`rule_weight`).
> - Interaction with `@layer`, `@scope`, and `!important`.
> - Implementation feasibility and browser concerns.
> 
> 
> Thanks,
> Jose A. Cano
> 
> P.S. I’m sharing this on X and DEV Community to gather developer feedback. Suggestions welcome!