- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 20 Aug 2025 13:40:57 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-gaps-1] Gap decorations next to empty grid areas`. <details><summary>The full IRC log of that discussion</summary> <fantasai> scribe+<br> <fantasai> kbabbitt: #1 feedback we got from authors so far is wanting more control over where gaps appear<br> <fantasai> kbabbitt: Layouts they wanted with unwanted decorations<br> <fantasai> kbabbitt: especially around empty areas<br> <fantasai> kbabbitt: Another example, they want the separators in second two rows, but no first<br> <fantasai> kbabbitt: Discussed different approaches<br> <fantasai> kbabbitt: one was to have a property similar to empty-cells<br> <fantasai> kbabbitt: another is concept of gap-decoration-areas, which was in original explainer but pushed out of Level 1<br> <fantasai> kbabbitt: in this case, you define an area based on grid syntax<br> <fantasai> kbabbitt: and override set of decorations for that area<br> <fantasai> kbabbitt: name the ara, refer to it in the gap decoration properties<br> <fantasai> kbabbitt: could define things for everything but the top, for example<br> <astearns> q+<br> <fantasai> kbabbitt: in both of these two cases, the authors did express preference for this over empty areas, but third example<br> <fantasai> kbabbitt: here is a responsive layout, where they have an outer grid and each headline article is a subgrid<br> <fantasai> kbabbitt: auto-fill grid, so as you size the window, columns reflow<br> <fantasai> kbabbitt: and you can't really identify the area<br> <fantasai> kbabbitt: so because of that, I'd like to solve with some sort of property to control decorations in empty areas<br> <fantasai> kbabbitt: some discussions about this, and I think the shape of it is a 5-state value to control where you want it<br> <fantasai> kbabbitt: current behavior is painting all the gaps<br> <fantasai> kbabbitt: might want to only paint if one side<br> <fantasai> kbabbitt: or only in left side or only one side or only both sides<br> <fantasai> kbabbitt: a few things to consider, one is what to name is<br> <fantasai> kbabbitt: another is do we want to do this<br> <fantasai> astearns: Would like to object to 1st solution where you define areas where rules apply<br> <fantasai> astearns: My concerns were, I like the fact that the syntax looks like grid-template-areas and has similar semantics<br> <fantasai> astearns: but I think it would get easily out of sync with template definition<br> <fantasai> astearns: and out of sync with what parts of the grid the content is actually flowing<br> <fantasai> astearns: You set up your rule areas expecting your content is in one place, but then change it, and forget to fix it up<br> <fantasai> astearns: so prefer dealing with empty areas directly<br> <astearns> ack astearns<br> <astearns> ack fantasai<br> <emilio> fantasai: same concern as astearns for the areas version, seemed a bit fragile<br> <emilio> ... A property on the items themselves sounds like a good idea<br> <emilio> ... if the default is draw all the lines and you have a bunch of empty areas<br> <emilio> ... you can't turn those off easily<br> <emilio> ... I think you'd want a grid level thing<br> <emilio> ... and then a grid item thing that allows you to override it<br> <SebastianZ> +1 to fantasai<br> <emilio> ... so certain elements you want rules around<br> <emilio> ... instead of associating to a position on the grid<br> <emilio> ... you associate it on the item<br> <alisonmaher> q+<br> <emilio> ... so the item decides based on the content around it<br> <emilio> q+<br> <astearns> wondering whether someone will implement a CSS-only game of life with this new feature<br> <emilio> ... and whether you want that unilaterally or only if the other item enables it<br> <emilio> ... I think you still want a default behavior on the grid<br> <emilio> kbabbitt: for the first example, I guess you'd turn it off on the grid and then turn it on for some items<br> <emilio> fantasai: correct<br> <oriol> q+<br> <emilio> ... and sometimes you want to make it visible in all adjacent places, or only if there's an item around<br> <SebastianZ> q+<br> <emilio> ... and you want some items to be able to ignore and so on<br> <emilio> kbabbitt: so two props, one for the global state<br> <emilio> ... is that an on-off on the grid?<br> <emilio> fantasai: I think you need at most 3 states<br> <emilio> astearns: let's not worry too much about the details, let's go through the queue<br> <astearns> ack alisonmaher<br> <emilio> alisonmaher: what if there's multiple items with conflicting instructions?<br> <astearns> q+<br> <emilio> fantasai: I think we want items to turn things on and whether their presence turns things on, but not suppressing lines<br> <astearns> ack emilio<br> <fantasai> fantasai: So an item could say "I want a line" or "I want a line if someone else wants a line"<br> <fantasai> fantasai: But can't turn it off<br> <JoshT> q+ turning on decs for specific cells<br> <astearns> ack turning<br> <Zakim> turning, you wanted to comment on decs for specific cells<br> <astearns> ack on<br> <astearns> ack the<br> <astearns> ack on<br> <emilio> emilio: was going to raise the same kind of concern<br> <astearns> ack the<br> <emilio> ... would like to not allow for weird conflicts<br> <astearns> q+ JoshT<br> <emilio> kbabbitt: I think that model makes sense to me<br> <astearns> ack oriol<br> <emilio> oriol: My question was about the 'whether there's content or not'<br> <emilio> ... do we care about absposes? Those are not technically a grid item<br> <astearns> ack SebastianZ<br> <emilio> fantasai: those don't count, if you are doing that you need to turn the lines unilaterally<br> <emilio> astearns: re. fantasai suggestion, there's no way to turn on things for empty areas<br> <emilio> ... because you can't target<br> <emilio> fantasai: seems unlikely you'd want something like that where you want specific empty areas<br> <emilio> s/astearns:/SebastianZ:/<br> <fantasai> s/empty areas/empty areas to have grid lines, but the rest of the grid to not/<br> <emilio> fantasai: if you want to turn them on on a particular area you can put an empty div there or a subgrid<br> <astearns> ack JoshT<br> <emilio> JoshT: Coming back to the question around being more precise about where the decorations go<br> <emilio> ... was talking to kevin about a potential use case we might have where you might have a grid, you don't want to show the lines above a cell that doesn't have an image on it?<br> <emilio> ... I wonder if we should still consider that kind of use case<br> <emilio> fantasai: can you review that example?<br> <emilio> JoshT: let me share my screen<br> <emilio> ... [shows bbc.cok.uk]<br> <emilio> ... we use border lines for dividers for things that don't have an image<br> <emilio> fantasai: is the layout that you have there such that you only have that row or they overlap?<br> <emilio> JoshT: they overlap and in this case it might be better to use border<br> <emilio> ... but there might be similar cases<br> <emilio> kbabbitt: is that something that you could do targetting elements that don't have an image?<br> <emilio> JoshT: I think so<br> <emilio> kbabbitt: then in this case you'd target non-image cards<br> <emilio> ... and turn the decorations on there<br> <SebastianZ> q+<br> <emilio> astearns: but if you can target them why would we need this extra proposal?<br> <emilio> astearns: I think what there's in the spec now allows to do this<br> <emilio> kbabbitt: no it's not, but with fantasai's proposal we would be able to do this<br> <emilio> astearns: I wanted to ask whether we were discussing this because this needs to be part of the first version of gap-decorations<br> <emilio> ... you're pulling it back in after pushing it off<br> <emilio> kbabbitt: What I pushed off was the grid areas version<br> <emilio> ... so this is more about solving some of these cases<br> <astearns> ack astearns<br> <emilio> ... the empty areas here I'd like to explore more<br> <emilio> ... because it's part of the feedback that we're receiving<br> <fantasai> rule-visibility-items: always | adjacent | between<br> <fantasai> rule-visibility-self: auto | always | between<br> <fantasai> s/adjacent/around/<br> <emilio> q?<br> <astearns> ack SebastianZ<br> <emilio> SebastianZ: maybe JoshT could share screen again?<br> <fantasai> rule-visibility-items: all | around | between<br> <fantasai> rule-visibility-self: auto | around | between<br> <emilio> ... I think the bbc use case is not completely covered by this thing<br> <emilio> ... you have an image aligned with the top line<br> <emilio> ... I guess you'd use border line<br> <fantasai> emilio: fact that it's aligned with top of border is an artifact of using border<br> <emilio> ... with gap decorations you wouldn't be able to achieve exactly that<br> <fantasai> s/.../sebastianz/<br> <emilio> fantasai: if you didn't have that alignment it'd be weird, that's why border would be the right tool here<br> <emilio> ... my proposal is above, `rule-visibility-items`<br> <emilio> ... `all` would be all borders<br> <emilio> ... `around` is for all the cells around each items<br> <emilio> q+<br> <emilio> ... `between` would be only if there's an adjacent item<br> <emilio> ... `rule-visibility-self` `auto` does whatever the grid container says<br> <emilio> ... the other values behave as expected<br> <emilio> kbabbitt: I like that, also like how they're named around the grid alignment properties<br> <oriol> q+<br> <emilio> fantasai: yeah and if we need extra control like per side you can split `rule-visibility-self` per side<br> <oSamDavis> q+<br> <emilio> SebastianZ: So you'd have `column/row-visibility-items` and `row-*`?<br> <emilio> fantasai: first q is whether we need that control<br> <emilio> ... but it'd be an easy extension<br> <astearns> ack emilio<br> <fantasai> emilio: sounds good, but the items naming makes it sound like it will only put rules around the items, maybe use 'cells' or something<br> <fantasai> emilio: but otherwise seems like a reasonable start, and easy to extend<br> <fantasai> SebastianZ: but if you have a spanning item, you won't have it between those cells<br> <astearns> ack oriol<br> <fantasai> fantasai: I think consistency with the alignment properties is probably more important<br> <astearns> ack oSamDavis<br> <fantasai> oriol: What if there was one item and then a spanner that spanned over it, would there be a rule underneath the spanner?<br> <fantasai> fantasai: Not unless there would be one otherwise, I think.<br> <fantasai> oSamDavis: Would it affect layout?<br> <fantasai> kbabbitt: No, all it does is turn decorations on/off in certain places<br> <fantasai> astearns: Sounds like you have an outline of how to design this feature, so maybe take it and run with it and bring it back to us :)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12602#issuecomment-3206391174 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 August 2025 13:40:58 UTC