- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Sep 2021 14:58:33 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Decorative grid-cell pseudo-elements`, and agreed to the following: * `RESOLVED: jensimmons and rachelandrew to write up use cases, examples, and syntax for this proposal` <details><summary>The full IRC log of that discussion</summary> <astearns> topic: Decorative grid-cell pseudo-elements<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/499#issuecomment-926122734<br> <castastrophe> @fantasai This is largely prompting from @jensimmons going over use-cases for this<br> <castastrophe> @fantasai There was a syntax in the original context that was grid-area pseudo element as the grid area shorthand<br> <castastrophe> @fantasai so we asked what are the questions we need to answer in the spec to have somethign that works<br> <astearns> s/@fantasai/fantasai:/<br> <castastrophe> +1<br> <astearns> fantasai: (summarized comment)<br> <fantasai> [ fantasai summarizes comment https://github.com/w3c/csswg-drafts/issues/499#issuecomment-926122734 ]<br> <castastrophe> fantasai: would not accept the grid-placement properties<br> <castastrophe> fantasai : ...a whole pile of details that we think makes this into something we can possibly spec up<br> <castastrophe> :)<br> <emilio> q+<br> <Rossen_> q+<br> <castastrophe> jensimmons : the goal here is to create a pseudo element without having to place empty divs in a cell;<br> <rachelandrew> q+<br> <chrishtr> q+<br> <chris> rrsagent, here<br> <RRSAgent> See https://www.w3.org/2021/09/29-css-irc#T14-13-09<br> <castastrophe> jensimmons : this really is about creating a way to target a track an area or a cell directly and not need empty divs<br> <castastrophe> jensimmons : this felt like the simplest approach without having all the craziness<br> <castastrophe> Rossen_ : we'll go through the queue, circle back to the specifics and knock out some of the bullets<br> <Rossen_> ack emilio<br> <castastrophe> emilio : are they tree-abiding pseudo elements?<br> <castastrophe> fantasai : yes<br> <castastrophe> emilio : seems a bit weird, imagine you have a bunch of conditions ...<br> <castastrophe> (sorry missed some parts)<br> <castastrophe> emilio : need to go through all the grid area selectors independent of all the<br> <astearns> emilio: concerned about creating multiple boxes per selector<br> <castastrophe> emilio : it can possibly work, it's just weird to do that<br> <castastrophe> emilio : you can have a first-line style, if the page doesn't use them at all, just skip this mess<br> <castastrophe> emilio : I need to work out all the details<br> <fantasai> i/emilio : it can/fantasai: Not sure, but are you referring to how you need to do placement before deciding which/how many boxes you have?<br> <castastrophe> emilio : multiple of these selectors can match ; the fact that this happens before box construction<br> <castastrophe> iank_ this would invalidate layout potentially right?<br> <castastrophe> fantasai : placement first but then layout second<br> <castastrophe> fantasai just impacts box-tree and auto-placement<br> <fantasai> s/match/match, and their declarations need to cascade/<br> <fantasai> s/fantasai/fantasai:/<br> <fremy> @emilio: you mean like table backgrounds and borders ^_^<br> <castastrophe> jensimmons there are use-cases where it could be helpful to do more than borders and backgrounds<br> <Rossen_> q<br> <castastrophe> jensimmons if there's a hard limit, that would make things too many paints, too many cycles; then bring it in. I'd like to see if we can not limit it right out of the gate<br> <iank_> q+<br> <fantasai> s/jensimmons/jensimmons:/<br> <castastrophe> Rossen_ : feedback is creating grid cells starts off with this very simple and seemingly very easy expectation that oh we'll just put a background<br> <castastrophe> Rossen_ : then as soon as you go down the rabbit hole, you're talking about having user expectations that are matching that of focus-handling, all kinds of eventing and capabilities<br> <castastrophe> Rossen_ : for example focus and app development management that make sense, especially in the grid layout which can vary vastly<br> <florian> q?<br> <castastrophe> Rossen_ : as we approach this kind of solution, it is in a way that we are not ignoring everything coming down the line in expectations<br> <Rossen_> ack Rossen<br> <castastrophe> Rossen_ : multi-column columns where people want to be able to target and style individual columns<br> <castastrophe> Rossen_ : the difference there is that multi-column is a scoped use-case to grid<br> <castastrophe> Rossen_ : if we start going down the path again, if we don't have great answers from the get-go for the use-cases I enumerated, then all we are doing here is solving the easy use-case of "let's put a little bit of background"<br> <castastrophe> Rossen_ : I'm concerned about trying to fit functionality and user expectations of elements into pseudo-elements<br> <Rossen_> q?<br> <florian> q?<br> <castastrophe> rachelandrew : I like the idea of being able to do this; my concern if we don't solve the borders on grid-cells issues first<br> <castastrophe> rachelandrew : authors will use this to style the gaps<br> <astearns> Rossen's concerns all sound like separate issues to raise on spec text that we need to write - yes, this will be complicated, we shouldn’t minimize the effort. But it will be worth the work<br> <Rossen_> ack rachelandrew<br> <castastrophe> rachelandrew : I kind of like this idea, I understand where Rossen_ is coming from<br> <castastrophe> rachelandrew : We add all these pseduo-elements and authors use it to add borders because authors want to use them to style the gaps<br> <castastrophe> rachelandrew : that comes up for me far more often than trying to s tyle the grid<br> <jensimmons> I agree with rachelandrew 's point — let's make sure we spec styling gaps before finishing this... and encourage implementors to ship gap styling before or with cell styling.<br> <castastrophe> rachelandrew : if people can do this grid, why can't we do this with multi-column?<br> <castastrophe> rachelandrew : it's the same in their minds; is this not something we'll need to do in multi-column too?<br> <castastrophe> rachelandrew : for authors, it could reduce mental load<br> <Rossen_> ack fantasai<br> <Zakim> fantasai, you wanted to react to rachelandrew to respond to the concern about gaps<br> <castastrophe> fantasai : +1 to rachelandrew<br> <castastrophe> fantasai : gaps issue is coming<br> <castastrophe> fantasai: I agree with the prioritization of shipping order<br> <castastrophe> chrishtr : it sounds like this is a feature that allows you to do something you can already do in a more convenient way<br> <florian> q+<br> <castastrophe> chrishtr : it sounds like it would be quite - in addition to the issues Rossen_ mentioned, could be quite complicated - could slow down interactions on implementation in the browser<br> <castastrophe> chrishtr : does this use-case justify complexity<br> <Rossen_> ack chrishtr<br> <castastrophe> jensimmons : I think there are quite a few use-cases that this could solve for<br> <TabAtkins> I'm not sure what would slow things down more than adding those elements as real HTML<br> <castastrophe> Rossen_ : you can do that if you add elements there<br> <castastrophe> chrishtr : you can do all this with adding the elements<br> <Rossen_> ack iank_<br> <castastrophe> jensimmons : there's a big difference between having the space and targeting the space with CSS<br> <castastrophe> iank_ : I want to bring up how this interacts with a11y<br> <fremy> @TabAtkins: you have to add them during layout, and their order in the "DOM" depends on the grid placement which can change depending on container queries etc...<br> <fantasai> s/having the space/having elements in the tree/<br> <castastrophe> iank_ : currently we have before and after markup, depending on the context<br> <castastrophe> iank_ : I'd be concerned that people would use the content property<br> <Rossen_> q?<br> <castastrophe> iank_ : to add more content in CSS<br> <chrishtr> Don't pseudo-elements affect layout and take up space?<br> <Rossen_> ack florian<br> <emilio> yeah, that's my understanding<br> <castastrophe> florian : from an author standpoint, this syntax seems spot-on<br> <castastrophe> florian : this makes it extremely learnable<br> <fantasai> s/spot-on/spot-on, once I've seen it can't think of anything else/<br> <castastrophe> florian : when you start thinking about pointer events, etc. - on the one hand yes, on the other, we're overdue on discussing these issues<br> <castastrophe> florian : I'd like to hear from jensimmons about use-cases that go beyond border and background<br> <castastrophe> florian : without needing a subtree or a pseduo-element<br> <Rossen_> q?<br> <castastrophe> jensimmons : <pulling up slides><br> <castastrophe> jensimmons : I feel unprepared to answer this question<br> <castastrophe> jensimmons : it would be great to allow an element to tilt without an nth-child<br> <emilio> q+<br> <florian> q+<br> <castastrophe> jensimmons : there's this idea that content can flow automatically, especially with responsive design<br> <Rossen_> q?<br> <castastrophe> jensimmons : not wanting to write a bunch of breakpoints; need a way to separate particular areas on the grid without manipulating the way content is flowing<br> <castastrophe> jensimmons : this is not about creating more content, this is about styling<br> <astearns> ack emilio<br> <castastrophe> emilio : the example shared jensimmons, I thought the idea was creating boxes / grid-items and being able to style them<br> <castastrophe> emilio : what you showed was that these items would exist inside the grid<br> <castastrophe> fantasai : I don't think we can do that example in the proposal that we have<br> <castastrophe> fantasai : we could possibly do that if you didn't want the content to rotate<br> <castastrophe> fantasai : you could do that with the pseudo-items and have the grid-item on top of that<br> <castastrophe> emilio : if I understand, then you can do this with regular elements<br> <castastrophe> fantasai : the problem is that with a regular element, you would have to inject a bunch of empty divs<br> <rachelandrew> https://github.com/w3c/csswg-drafts/issues/1943 is more like that first use case<br> <castastrophe> emilio : i agree, I just wanted to wrap my head around it<br> <castastrophe> emilio : a syntax to inject a bunch of elements onto the grid in a particular order to style them<br> <castastrophe> fantasai : if we could select things by their placement in the grid, that would also be awesome<br> <florian> q-<br> <castastrophe> fantasai : that has a problem of the selection being dependent on a layout<br> <castastrophe> fantasai : change as the size of the page changes<br> <castastrophe> fantasai : part of what this is trying to solve is a handful of cases that don't involve styling the element itself<br> <castastrophe> iank_ : variable content types, want content on a diagonal, how does this work for that case? It seems like you want to insert pseudo-elements based on the size of the grid<br> <castastrophe> fantasai : block out the cells you want to block out by making them<br> <castastrophe> iank_ : wouldn't that expand out the grid<br> <castastrophe> fantasai : yes, you wouldn't use that when you only have a few items<br> <castastrophe> fantasai : a lot of these are cases where the author knows the minimum and maybe the maximum but doesn't know the number of columns because that depends on how wide the screen is<br> <castastrophe> iank_ : I'm a little suspicious of the "knows how many items". For that use-case where you want to skip grid areas<br> <castastrophe> iank_ : It seems like it's actually easier to inject DOM<br> <castastrophe> iank_ : Or a grid property that says, skip this grid area<br> <castastrophe> iank_ : dynamic size of content didn't mesh in my mind<br> <castastrophe> fantasai : I agree in that use-case it would be better to inject DOM<br> <fantasai> s/inject DOM/specify skipped cells in a property/<br> <fantasai> s/inject DOM/specify skipped cells in a property/<br> <castastrophe> astearns : Next steps to draw out use-cases and corner-cases so we can talk through code examples<br> <castastrophe> astearns : it doesn't sound like we're ready to say yes let's put this in a working draft<br> <florian> q+<br> <castastrophe> iank_ : I don't think we need an editor's draft, just writing down the examples in the issue<br> <castastrophe> astearns : I think this is getting too complicated for an issue<br> <castastrophe> astearns : spec text would be helpful; we wouldn't have to adopt the draft if we weren't happy with it<br> <castastrophe> jensimmons : if folks are willing to explore this area, this seems like something we want to solve<br> <castastrophe> jensimmons : yes, an editor's draft with real-world use-cases<br> <castastrophe> jensimmons : then we can point at items and identify what n eeds to be better<br> <astearns> ack florian<br> <castastrophe> florian : I support this for those who feel this is a bit early<br> <castastrophe> florian : I came in really liking it and wondering if it's an uncanny valley of too much and not enough<br> <castastrophe> florian : Want to see more examples to see if this comes close enough<br> <castastrophe> iank_ : use-cases written down clearly would be really useful; there might be multiple avenues we can explore<br> <castastrophe> iank_ : we've talked about styling columns and gaps, that could be a different selector<br> <castastrophe> iank_ : multiple avenues we could go down<br> <florian> s/those who feel this is a bit early/those who feel this is a bit early, think of that early spec as an explainer/<br> <fantasai> s/that could/the rotated item case, that/<br> <castastrophe> astearns : makes sense<br> <castastrophe> jensimmons I will help make use-cases<br> <castastrophe> jensimmons I can't help write the spec<br> <castastrophe> rachelandrew happy to help with this<br> <fantasai> s/jensimmons/jensimmons:/<br> <fantasai> s/jensimmons/jensimmons:/<br> <fantasai> s/rachelandrew/rachelandrew:/<br> <castastrophe> astearns : task jensimmons and rachelandrew to work through examples and syntax<br> <castastrophe> astearns: Resolved<br> <fantasai> RESOLVED: jensimmons and rachelandrew to write up use cases, examples, and syntax for this proposal<br> <TabAtkins> ScribeNick: TabAtkins<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/499#issuecomment-930258511 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 September 2021 14:58:36 UTC