Re: [CSS21] selector's specificity issues.

> It is arguably more specific, but is the difference enough to make it
> worth complicating the specificity hierarchy?  Right now, specificity
> depends roughly on a) style attribute vs. element, b) IDs, c)
> classes, d) everything else.  Where in that hierarchy would you place
> this difference?  Why do you think the added complication would be
> worth the addition?

My solution is pretty simple.

If we will update second specificity rule:

1) count the number of ID attributes in the selector (= b)
2) count the number of other attributes and pseudo-classes in the selector
(= c)
   *plus number of  '>' and '+' in the selector*
3) count the number of element names and pseudo-elements in the selector (=
d)

Then we will have:

case "UL LI":
   d = 2

case "UL>LI":
   c = 1
   d = 2

I don't think that it is difficult to implement and to understand.

Andrew Fedoniouk.


From: "Adam Kuehn" <akuehn@nc.rr.com>
>
> Andrew Fedoniouk wrote:
>
> >Algortihm described in [1] for counting style selector's specificity
> >does not distinguish cases:
> >
> >"ul li" and "ul>li"
> >
> >Obviously second case is more strong/specific therefore it should have a
> >bigger weight.
>
> It is arguably more specific, but is the difference enough to make it
> worth complicating the specificity hierarchy?  Right now, specificity
> depends roughly on a) style attribute vs. element, b) IDs, c)
> classes, d) everything else.  Where in that hierarchy would you place
> this difference?  Why do you think the added complication would be
> worth the addition?
>
> Sure, a child selector is logically more specific than a descendent
> selector.  Arguably, so is an adjacent sibling selector.  And the
> selector e[foo="bar"] is more specific than e[foo].  But is noting
> those differences worth the cost in user overhead in remembering
> those differences?
>
> Personally, I'd say, "No."
>
> --
>
> -Adam Kuehn
>