bramus / specificity

JavaScript Package to calculate the Specificity of CSS Selectors
MIT License
79 stars 5 forks source link

Feature request: support for nested selectors #20

Open bartveneman opened 1 year ago

bartveneman commented 1 year ago

We've briefly touched on this during CSS Day. Posting here to keep track.

Would it be a good idea for this library to support native CSS nesting? People are starting to use it in production websites, so it would be good for them to have the possibility to calculate the specificity of nested selectors as well.

bramus commented 1 year ago

(Apologies for the late reply, I was OOO the past two weeks)

Am a bit hesitant about this, as I don't want to pass in entire rulesets into this library because that feels like stepping into parser territory a bit too much - something this library offloads to csstree entirely.

Some quick thinking might be to extend .calculate() to accept a multiple arguments, in which a later argument would be the enclosing context. E.g. .calculate("& color", "div, #foo", "body") to indicate a "& color" nested inside a "div, #foo" selector nested inside a "body" selector.

With that, I am not sure about requiring a & inside a nested selector or not. With relative selectors now needing to serialize with an &, it could make sense to do so - it would definitely make things easier :)

bartveneman commented 1 year ago

With https://github.com/w3c/csswg-drafts/issues/8970, it could make sense to do so

Yes, generally I'm a proponent of making things explicit. And since your CSS would require the & already, why not add it here too.


Asking just to be sure: since calculate() accepts both strings and CSSTree objects, would you consider accepting that for all of the arguments?

bramus commented 1 year ago

would you consider accepting that for all of the arguments?

I think it should, unless there’s arguments against that?