Open bartveneman opened 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 :)
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
?
would you consider accepting that for all of the
arguments
?
I think it should, unless there’s arguments against that?
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.