:parent, :next and :prev specificity and necessity?

[adrianhelvik]

First of all: I love the proposal!

One thing that I couldn't figure out is what specificity :parent, :next and :prev have.

I am also wondering wether they are needed. :parent is by far the most useful of them, but the only one you'd really need is :self.

Overall it feels like these selectors should be in a separate proposal.

I am only commenting this because I love the proposal and hope it will be accepted. Additional complexity could prevent that.

[tomhodgins]

Hi @adrianhelvik! Thanks for the questions/suggestions.

One thing that I couldn't figure out is what specificity :parent, :next and :prev have.

This wasn't defined in the spec, but for implementations of this spec out there in the wild it's been implemented as an attribute selector (the lowest we can create a unique identifier for CSS) so something like :parent would end up becoming something with the specificity of [parent], but of course we also need to make it unique enough to only apply to the elements in the document we need, so it might end up something like [eqcss-parent_0_1] or something like that in practice. This spec actually followed some implementations of a way of doing things (documenting implementations) rather than being a purely academic definition from which implementations have grown.

Though an attribute selector is the weakest selector we can create, that still gives authors a nice range of specificity they can create, consider how :parent, div:parent, .class:parent and #id:parent might have a broader range of specificity than would be possible if :parent came out with the specificity of #id already :)

I am also wondering wether they are needed. :parent is by far the most useful of them, but the only one you'd really need is :self.

I would say that when you're dealing with the idea of 'scoped CSS', defining those direct relationships: :self, :prev, :next, and :parent are useful. We could always think of :next as :self + * so it's a shorthand, but I think the idea and relationship has merit enough to include. In JavaScript these would be equivalent to:

• element
• element.previousElementSibling
• element.nextElementSibling
• element.parentElement

Overall it feels like these selectors should be in a separate proposal.

I am only commenting this because I love the proposal and hope it will be accepted. Additional complexity could prevent that.

That could be, I've already cut some things out of this proposal like eval() :D However I don't worry about trying to pare it down to make it more acceptable, I think by including these ideas it serves to map out otherwise uncharted territory, and future spec writers who are working on more specific specs can come through and cherry-pick the parts they like from this document.

I'm part of the WICG effort that is trying to brainstorm something to propose for container queries. Whatever we come up with there likely won't include things like :parent, but I don't want to remove it here for the implementations and users of the way of doing things that do make use of it, especially since modifying this document won't affect the new document being prepared specifically for the purpose of being proposed.

If you'd like to help with the WICG in coming up with a Use Cases & Requirements document, or the specification we come up with after that, feel free to check out either of these repositories and their issues:

• https://github.com/WICG/cq-usecases
• https://github.com/WICG/container-queries

That's where the current work relating to this topic is taking place, and with a much larger group of people :D