[css-pseudo-4] new generated content pseudo :between/:separator

[hfhchan]

When building toolbars, navbars and lists, often there needs to be separators. They are currently implemented by using :before and/or :after but this is a hacky:

(1) the separator is not semantically a part of the toolbar item or list item itself;
(2) the separator messes with hit-testing i.e. hovering the separator would either select the previous or next item which may not be preferred
(3) relying on more specific selectors to turn off the selector at the start and/or end of the list.

The effect could be more elegantly accomplished by providing a way to insert generated content between a given node's children.

Example:

ul.recycler::between {
display: block;
content: "";
border-bottom: 1px solid #ccc;
margin: 0 40px
}

[frivoal]

Something like this could also be used for some cases of list styling:

li {display :inline;}
ul::between { content: ", "; }
ul::after { content: "."; }
:lang(jp) ul::between { content: "、"; }
:lang(jp) ul::after { content: "。"; }

You can do that with existing selectors though.

If what you're trying to put separators between is a bunch of buttons or a bunch of links (without a wrapping element), it's true that ::after would insert the separator inside of the buttons/links, which is not what you'd want.

[Loirooriol]

My ::contents proposal (#2406) would solve your use-case:

ul.recycler {
  display: contents;
}
ul.recycler::contents {
  display: block;
}
ul.recycler + ul.recycler::before {
  display: block;
  content: "";
  border-bottom: 1px solid #ccc;
  margin: 0 40px
}

[tabatkins]

...huh, ::between isn't a bad idea at all. ::contents isn't either. Both of them involve adding a substantial chunk of complexity in different ways.

Really I think there's been four variants of this idea proposed in the past, all with different strengths and weaknesses:

• ::between adds an unbounded number of additional child nodes to the element, one per "real" child, which means that any internal operations that add or remove nodes have to also add or remove the pseudo-element node (this makes editing more complicated, for example). If we allow ::between(an+b) you also have to store an arbitrary amount of additional style data. At least recalculating it won't be more complex than handling :nth-child() pseudos (which is to say, relatively expensive). As a plus, ::between is a child of its originating node, which makes inheritance saner.
• ::contents adds only a single node, but changes the parent/child relationships of nodes. While engines can now handle parent/child relationships getting changed arbitrarily within the styling engine due to display:contents, this is still a weird thing to do. Then again, it's probably similar to anonymous box creation. Again, it's a plus that the pseudo-element is at least a child of its originating element, for inheritance reasons.
• ::parent/::wrapper is the inverse of ::contents, wrapping around the originating element. Mostly the same issues, but with the weirdness that inheritance flows "upward" from the originating element.
• ::outer-before/::outer-after, which create siblings of the originating element. One each per element, which is nice, no parent/child fiddling, but inheritance is slightly messy as it travels "sideways". Does complexify the tree-walking, by adding another two ifs to every element.

I suspect we'll want to add one of these at some point in the future, so it would be good to see which of these are easier/harder in the various engines.

[frivoal]

If we only go for one, my vote probably goes for ::contents, it seems more powerful and generally applicable. And if you add that, I agree we shouldn't get ::parent/::wrapper or ::outer-before/::outer-after, I am not sure it cancels the argument for ::between

[tabatkins]

@Loirooriol's example shows how you can achieve the ::between effect with ::contents. You can produce similar code with any of the others, too.

[jonjohnjohnson]

I don't think @Loirooriol's example cover's the 2nd point laid out by @hfhchan where ::between could make it so hit-testing is on the actual children items. The example might just need to alter ul.recycler + ul.recycler::before to ul.recycler li + li::before, adding in the li to the selectors? But still don't think that fully covers that point. Say, if it's not a ul with li inside, and instead just a div with a tags inside, I think forcing the use of ::before would make styling a:hover cumbersome, instead having to style a::contents:hover as well as clicking on the ::before would execute the link, unless it had pointer-events: none set?

All in all, I'm a huge fan of the ::contents proposal and am more excited to see that land. But it doesn't seem to cover the possibility of generated content being truly between siblings.

[frivoal]

Right. either I'm misunderstanding @Loirooriol 's example, or it doesn't work. His css seems to assume that there'd be multiple ul.recycler and puts pseudos between them, but the original example assumed a single ul.recycler with multiple children, and put pseudos between the children.

And I agree with @jonjohnjohnson's point: using the foo::contents with foo + foo::before does not fully replace ::between when foo is an interactive element like a link, as that interactiveness would still apply to the ::before.

[tabatkins]

Yeah, I was assuming that @Loirooriol's code was corrected to refer to the lis, not the ul. ^_^

[Loirooriol]

I fat-fingered the delete button of a previous comment, basically I said that I misread the proposal and that the code with ::contents needs some small modifications:

ul.recycler > * {
  & { display: contents }
  &::contents { display: block }
  & + ::before { /* ... */ }
}

It's true that proper hit-testing may need some refinements, like using ul.recycler > ::contents:hover instead of just ul.recycler > :hover, or playing with pointer-events. But I think it's mostly doable.

This table summarizes the relationships between the related proposals:

Feature	Can be simulated with
	::between	::contents	::wrapper	::outer-before / ::outer-after
::between	-	Yes, with display: contents and ::before / ::after.	Only if ::wrapper::before / ::wrapper::after are allowed.	Yes.
::contents	Mostly not.	-	Only for use-cases without ::before nor ::after	Mostly not.
::wrapper	Mostly not.	Only for use-cases without ::before nor ::after	-	Mostly not.
::outer-before / ::outer-after	Mostly not.	Yes, with display: contents and ::before / ::after.	Only if ::wrapper::before / ::wrapper::after are allowed.	-

IMO the best and most complete one is ::contents. ::wrapper may be good enough if pseudo-element nesting is allowed, but this would allow generating arbitrarily-deep structures which I suspect will be more difficult to implement.

[jonjohnjohnson]

From what I've gathered, ::contents has the best (if not only) shot at gaining implementor interest, because of it's nearly seamless use of display: contents and inheritance. So in my mind, the others aren't really on the docket.