Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specificity cannot be represented by an integer #25

Open
robinpokorny opened this issue Apr 24, 2014 · 2 comments
Open

Specificity cannot be represented by an integer #25

robinpokorny opened this issue Apr 24, 2014 · 2 comments

Comments

@robinpokorny
Copy link

Problem

When counting the specificity of a selector Parker does:

  • count the number of ID selectors in the selector (= a)
  • count the number of class selectors, attributes selectors, and pseudo-classes in the selector (= b)
  • count the number of type selectors and pseudo-elements in the selector (= c)

correctly as specified by Selectors Level 3: 9. Calculating a selector's specificity.

Then it concats the thee numbers into a string which it then converts into an integer using Number object.

I feel this is fundamentally wrong approach.

Example

The result of such is that having the following CSS:

w v u t s r q p o n m l k j i h g f d c b a {
    color: black
}

.foo .bar a {
    color: white;
}

Parker would count specificity 22 for the first one and 21 for the second. And then it would write out:

Top Selector Specificity: 22
Top Selector Specificity Selector: w v u t s r q p o n m l k j i h g f d c b a

But, clearly, the second selector has higher specificity!

The problem is Number object transforms the string into a base 10 number. Whereas the above mentioned specification precisely states that:

Concatenating the three numbers a-b-c (in a number system with a large base) gives the specificity.

Proposed solutions

There are two solutions I am aware of:

Base 16 like

Use letters to represent digits larger that 9, forming a sequence: 0-9a-zA-Z. That is the first selector in the example would get specificity n. Base 64 uses almost the same approach (with different order).

This would only move the problem to base 62, which would be more usable and would be (IMHO) enough in the vast majority of cases.

Three separated numbers

Show the result as three (dot?) separated numbers, making the first selector specificity 0.0.22. This reintroduces the way CSS2 deal with this. Such solution is vivid and complete.

It would however introduce a question how to count specificity per selector and related metrics. Counting average for each part would resolve this. Maybe it would even carry more information, as I have no idea what Specificity Per Selector: 9.48506151142355 truly represents.

@guilhermehn
Copy link

+1

@bartveneman
Copy link

So what if we could represent specificity like this: { a: 1, b: 0, c: 0 }? This would mean that we have a selector that has a single id-selector, like #my-selector. For displaying purposes we could use the proposed 0.0.22 notation, but for comparisons or averages I would use the object notation, because I think

{
  a: 0.493, 
  b: 2.509, 
  c: 1.208 
}

is easier to comprehend than 0.493,2.509,1.208. It's also more clear for further analysis as sorting specificities would be done by first sorting a, then b and then c.

Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants