W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2019

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

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Mon, 25 Feb 2019 22:44:50 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-467214837-1551134689-sysbot+gh@w3.org>
The CSS Working Group just discussed `new generated content pseudo :between/:separator`.

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: new generated content pseudo :between/:separator<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/2960<br>
&lt;fantasai> fantasai: I don't wanna do another generated content pseudo....<br>
&lt;fantasai> TabAtkins: Gonna discuss the problem<br>
&lt;fantasai> TabAtkins: Ppl want to address generated content siblings of an element<br>
&lt;fantasai> TabAtkins: There's a few variants that ppl want, but usually you want to address siblings, and before/after address children<br>
&lt;fantasai> TabAtkins: Sometimes it's about wrappersT<br>
&lt;fantasai> TabAtkins: There appear to be several different possibilities to address this<br>
&lt;fantasai> TabAtkins: First one, is a ::between pseudo<br>
&lt;fantasai> TabAtkins: It's like ::before/::after in that it creates children of an element. They sit between the children rather than before/after.<br>
&lt;fantasai> TabAtkins: Solves problem of ordered list with separators<br>
&lt;fantasai> TabAtkins: ul::between { content: " | "; }<br>
&lt;fantasai> TabAtkins: right now have to be careful about not styling last element or first element or whatever.<br>
&lt;fantasai> TabAtkins: Next one is ::contents, which is a wrapper element around all of the real children.<br>
&lt;fantasai> TabAtkins: This has a number of use cases. Ppl want extra wrappers and have asked for this before.<br>
&lt;fantasai> TabAtkins: Have to do it by putting more elements in the DOM<br>
&lt;fantasai> TabAtkins: Can be used like ::between in some cases, if you set the actual element to be 'display: contents'<br>
&lt;fantasai> TabAtkins: and then style the ::contents instead of the element itself<br>
&lt;fantasai> TabAtkins: Next one is ::parent/::wrapper, inverse of ::contents<br>
&lt;fantasai> TabAtkins: Creates a pseudo outside the element. More complicated wrt inheritance, because it flows uprward from originating element<br>
&lt;fantasai> TabAtkins: Last suggestion is ::outer-before/::outer-after. Creates siblings of originating element.<br>
&lt;fantasai> TabAtkins: travels sideways<br>
&lt;fantasai> TabAtkins: I think we should not have all of these. maybe one of these. Maybe none of these<br>
&lt;fantasai> TabAtkins: 'display: contents' makes some of these easier<br>
&lt;fantasai> TabAtkins: Question is do we want to do any of these, and if so which one?<br>
&lt;astearns> fantasai: I really don't like the way ::contents hides the thing<br>
&lt;astearns> fantasai: bad cascade ergo<br>
&lt;astearns> fantasai: between seems simplest<br>
&lt;astearns> fantasai: solves some use cases very cleanly<br>
&lt;fantasai> The ::contents solution affects how every part of your stylesheet interacts with this particular element. You want to solve this separator problem in this corner of your style sheet, but because you do it by hiding the actual element and moving all styles to the ::contents pseudo<br>
&lt;fantasai> every other part of your style sheet need to know that it has to style the ::contents pseudo of that element instead of the actual element.<br>
&lt;fantasai> This is fragile cascading and bad ergonomics for the author.<br>
&lt;tantek> Cascading is already too hard for authors, I tend to agree with fantasai that this would make the model worse (harder) for authors to predictably use / style etc.<br>
&lt;fantasai> emilio: Can we agree that whatever we do, that doesn't affect inheritance of the children? If you do ::wraper { color: green; } doesn't affet children of the elmeent<br>
&lt;fantasai> emilio: Because ::first-line has that weird thing and I prefer not having it<br>
&lt;fantasai> dydz: So the problem is that you had that horizontal list and you wanted separators, and you wanted vertical bar or character, and currently the person is syaying htere's no easy way to get at every other element, don't want to put a bar before the first one and not after last one<br>
&lt;fantasai> fantasai: That's part of it, it's nicer that it's easier to express but hte main problem is existing ::before/::after is child of the item, but you want a sibling of the item.<br>
&lt;fantasai> dydz: Why can't you use ::marker?<br>
&lt;fantasai> TabAtkins: Markers are also children<br>
&lt;fantasai> TabAtkins: They're inside the list item. If I put a border around it, it'll include the marker<br>
&lt;fantasai> myles_: So you want a sibling<br>
&lt;fantasai> TabAtkins: Yeah, at least in the box tree<br>
&lt;fantasai> jensimmons: To dydz's point, ppl who write CSS have a workaround for the specific case in the thread<br>
&lt;fantasai> jensimmons: but when we talk about possibility of creating a new pseudo element<br>
&lt;fantasai> jensimmons: My brain starts spinning about all the dissatisfactions we have about this<br>
&lt;fantasai> jensimmons: Sometimes we wish we had much more than ::before/::after<br>
&lt;fantasai> jensimmons: Sometimes we wish we had ones that were sblings<br>
&lt;fantasai> jensimmons: If we go down this road, think about all the ways that we want to have pseudo-elements, that's great.<br>
&lt;fantasai> jensimmons: But let's come up with something tha'ts robust and elegant, and solves this use case without creating new problems.<br>
&lt;fantasai> jensimmons: The scope of this problem is too small. It's a hint to a bigger scope. Coming up with a quasi-hack that solve sthis one thing is not as robust or complex as what we really need<br>
&lt;fantasai> futhark: What Jen is saying is, before and after can be same alis of ::between?<br>
&lt;fantasai> fantasai: Child list of an element is ::before, first child, ::between, second child, ::between, third child, ::after<br>
&lt;dbaron> We had something like this before, but I think concluded we wanted XBL (or its successor) instead.<br>
&lt;fantasai> jensimmons: Wouldn't be between, would be somehting else. You could have as many as you want. Like 17 of them. could determine if children or siblings<br>
&lt;fantasai> jensimmons: We have gaps in flexbox and grid, another way would be to style gaps or empty grid cells<br>
&lt;fantasai> jensimmons: would allow authors to style those things without them being real<br>
&lt;bkardell_> would it make sense to try to tackle the definitions there  in houdini?<br>
&lt;fremy> q+<br>
&lt;fantasai> myles_: General solution to boxes is really interesting. But we don't want to go so far and make a whole DOM in CSS.<br>
&lt;fantasai> myles_: A competing proposal that is morepowerful and general would be interesting, woudl want to hear about it.<br>
&lt;fantasai> jensimmons: Most common case for pseudos that are siblings is decorating empty grid cells without putting empty markup in the DOM<br>
&lt;fantasai> TabAtkins: That one we definitely need to solve, I agree.<br>
&lt;fantasai> TabAtkins: That one is easier because it doesn't require where to insert between elements, can be a pile of ::befores<br>
&lt;fantasai> TabAtkins: I fear that a general solution would just re-implement the DOM, though.<br>
&lt;fantasai> fremy: I was going to say, I feel like in what we provide in CSS, I would be very glad if we have ::between which isreasonable for most use cases<br>
&lt;fantasai> fremy: If you want custom boxes, use Houdini<br>
&lt;fantasai> fremy: If you need 17 boxes, you need specific stylings for each<br>
&lt;fantasai> fremy: 17 random boxes is not useful<br>
&lt;fantasai> fremy: Grid is a good example of where we can describe this, but in the general case I think it will get more and more obscure<br>
&lt;dauwhe> https://www.w3.org/TR/2003/WD-css3-content-20030514/#inserting0<br>
&lt;fantasai> fremy: But if we do decoratively in CSS, seems nice, ::between is very similar to what we already have and it solves a lot of cases that people have<br>
&lt;fantasai> fremy: Having something simpler solution is better<br>
&lt;fantasai> fremy: I think ::between is the best way to solve this case. If you need more complex, Selectors is maybe not the right solution.<br>
&lt;fantasai> TabAtkins: We're talkign about boxes, but it's about elmeents.<br>
&lt;fantasai> TabAtkins: And custom layout is about fragments, not boxes.<br>
&lt;fantasai> TabAtkins: Let's look more into stuff.<br>
&lt;fantasai> TabAtkins: Jen brought up more possibilites, we should pay attention before tackling this.<br>
&lt;fantasai> jensimmons: The need is to ahve a way to lightwight put styling on things, like dividers between things or bg colors on particular grid cells<br>
&lt;fantasai> jensimmons: Want to do that in an elegant way, not limited to one or two.<br>
&lt;fantasai> jensimmons: We've been usign ::before/::after. We're reaching limit of those hacks.<br>
&lt;fantasai> jensimmons: I don't want to solve one use case. I want to solve the systematic problem at the right level.<br>
&lt;fantasai> jensimmons: I don't think it's just about lines between navigation elements, I think it's styling things on the page that don't exist in the content.<br>
&lt;fantasai> dauwhe: I run into this all the time. We want multiple borders in my world. Just nest a bunch of divs.<br>
&lt;fantasai> myles_: which is contrary to the possibility of CSS.<br>
&lt;myles_> S/possibility/philosophy/<br>
&lt;fantasai> TabAtkins: That feels a little different htan what Jen was talking about<br>
&lt;TabAtkins> s/TabAtkins/tantek/<br>
&lt;fantasai> tantek: Jen was talking about ways to style the negative spaces in CSS.<br>
&lt;fantasai> fantasai: Wrt multiple borders, we should solve that by actually having multiple borders.<br>
&lt;fantasai> astearns: Sounds like we're done for now, keep discussing later.<br>
&lt;fremy> q-<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2960#issuecomment-467214837 using your GitHub account
Received on Monday, 25 February 2019 22:44:51 UTC

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