W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2018

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

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Mon, 30 Jul 2018 21:58:04 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-409025233-1532987883-sysbot+gh@w3.org>
...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 `if`s 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.

GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2960#issuecomment-409025233 using your GitHub account
Received on Monday, 30 July 2018 21:58:06 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:33 UTC