- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Jun 2024 08:49:01 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Proposal: CSS Gap Decorations Level 1`, and agreed to the following:
* `RESOLVED: import the draft with shortname css-gaps and title CSS Gap Decorations with kbabbitt as editor.`
<details><summary>The full IRC log of that discussion</summary>
<dbaron> kbabbitt: gap decorations in layouts like grid is something authors have been asking for.<br>
<dbaron> kbabbitt: discussed in some other issues... this proposal takes some inspiration from previous discussions<br>
<dbaron> kbabbitt: this adds row-rule-* to complement column-rule-* and makes them apply to grid and masonry<br>
<dbaron> kbabbitt: this adds a new idea of varying gap decorations<br>
<TabAtkins> q+<br>
<dbaron> kbabbitt: ??<br>
<dbaron> kbabbitt: this example is a calendar grid with varying light and dark decorations.<br>
<TabAtkins> alternating light and *very light* rules<br>
<dbaron> kbabbitt: this is a calendar grid set up with alternating heavier and lighter rules for hours of the day and days of the week<br>
<dbaron> kbabbitt: this specifies area where they apply and patterns for drawing<br>
<dbaron> kbabbitt: plenty of use cases work without this, so could be pushed to a later version<br>
<una> q+<br>
<dbaron> kbabbitt: basic part here is row-rule-{width,style,color} and applying row-rule-* and column-rule-* to grid<br>
<rachelandrew> q+<br>
<dbaron> fantasai: how does it address the last part, where there's no rule where there's no cells?<br>
<dbaron> kbabbitt: the basic model that I have for where the decorations from the stem of the T to the next intersection<br>
<dbaron> rachelandrew: same as multicol, don't draw the rules where there's no content<br>
<florian> q+<br>
<dbaron> TabAtkins: strongly approve overall. Having control over rules is important for grid, useful for flexbox, useful for masonry. I agree with deferring rule images until some later time. They are mildly complicate in multicol, incredibly complicated in a 2D grid. Can't appreciate thus until you try to design it. Put that far in the future!<br>
<rachelandrew> +1 on deferring rule images<br>
<emilio> q+ to ask how does this interact with gap? Presumably the effective gap would be max(rule-width, gap)?<br>
<dbaron> TabAtkins: I like ideas here about areas. Captures functionality you can get tables, we don't have the hierarchy of elements in grid, good to be able to reproduce that.<br>
<dbaron> TabAtkins: I don't like use of slashes mixed with commas more than we usually like. We can do that later, such as with a wrapping function.<br>
<dbaron> TabAtkins: overall looks really good, don't have a strong opinion on what should be deferred versus MVP for level 1. Fine with simplest possible, but could see how much to get into a level 1.<br>
<dbaron> TabAtkins: some other things mentioned in thread was about controlling length of rules so they don't fill entire row/column.<br>
<dbaron> TabAtkins: model here does make that a little more complicated... might need some thought.<br>
<dbaron> TabAtkins: but I'm happy to deal that in the future.<br>
<dbaron> TabAtkins: maybe that means we should simplify to bare minimum in L1 to keep our options open for later.<br>
<dbaron> kbabbitt: One comment about use of slashes: in this example, using slashes in the context of a shorthand. Not opposed to functional notation.<br>
<dbaron> TabAtkins: you have to save commas for matching up with row rule areas.<br>
<dbaron> TabAtkins: we try to avoid 2 levels of demarcation because it's hard to read. We can figure that out in the issues.<br>
<iank_> q+<br>
<dbaron> una: generally think it's a good idea. Some questions:<br>
<dbaron> una: regarding which line item is on tap -- is it the horizontal or vertical? is it consistent? is there author control?<br>
<dbaron> una: you mentioned no images -- agree it adds a lot of complexity. What about gradients? Could be effective.<br>
<dbaron> una: my first thought was that given lack of intersection control, maybe want blend modes or filters to control how they intersect. Or can authors use blend modes etc. for gap decorators? Or is that a v2 thing?<br>
<dbaron> kbabbitt: re paint order, there's a property for that, just to choose row or column on top. Could explore more flexibility later.<br>
<dbaron> kbabbitt: for gradients and mix blend modes I'd think of that as something to explore later. Probably some complexity.<br>
<dbaron> kbabbitt: for blend modes in particular, re how decorations interct when they meet at an intersection.<br>
<dbaron> iank_: then also, gradients are images (at the spec level, no diference)<br>
<lea> q+<br>
<dbaron> kbabbitt: I'm also still collecting use cases, please post examples to the issue.<br>
<TabAtkins> Gradients *can* be 1-d (see border-stripe) but that still requires the rendering model to have a well-defined and understandable notion of "length"<br>
<dbaron> rachelandrew: generally a fan of this. Something we know people asking for.<br>
<lea> q+ to say I'd rather keep L1 as small as possible (possibly just `row-rule` that is identical to the existing `column-rule` and leave the bells and whistles for later, once we have experience of what authors do<br>
<dbaron> rachelandrew: I'm interested in the area syntax, i ithink it solves quite a few use cases, people asking for multicol pseudo-elements for grid. I think this would help with some of those.<br>
<dbaron> rachelandrew: you perhaps saw my comments on ?'s original proposal... were hoping to do multicol overflow in th eblock direction which gives us ? rows. (??)<br>
<dbaron> florian: I think it's a well thought out propsoal. A lot of complexity, but a lot of details. We can fiddle with the details a lot. I like it. Should turn it into a spec. Not sure if we want to spec more than the minimal set and then trip, or just spec minimal set.<br>
<dbaron> florian: you mention orthogonal direction doesn't apply to multicol around spanners and things... we might later extend multicol to multiple rows of multiple columns<br>
<dbaron> florian: But I like it.<br>
<dbaron> kbabbitt: for spanners in particular there are probably multiple solutions that work, such as putting borders on the spanning element<br>
<dbaron> kbabbitt: i want to reserve ???<br>
<emeyer> q+<br>
<florian> s/around spanners and things/around spanners and things, and I agree with that choice.<br>
<Zakim> emilio, you wanted to ask how does this interact with gap? Presumably the effective gap would be max(rule-width, gap)?<br>
<dbaron> kbabbitt: One reason I explored designing subareas was to make sure syntax could be extended, but I think I am leaning towards deferring it.<br>
<florian> s/we might later extend multicol to multiple rows of multiple columns/we might later extend multicol to multiple rows of multiple columns, and that's where they should apply<br>
<dbaron> emilio: does do the row length and the gap length interact? Like in columns?<br>
<dbaron> emilio: if you have a rule length that is bigger than the gap between the items, does that expand the gap or do something else?<br>
<rachelandrew> made the same comment re multicol, rows, and spanners in the proposal from Mats https://github.com/w3c/csswg-drafts/issues/6748#issuecomment-947375179<br>
<dbaron> kbabbitt: gap decorations do not affect layout at all -- they're a paint-only effect. They'd paint behind the items like gap decorations in multicol.<br>
<dbaron> kbabbitt: This is because for some of the subarea definitions, want to be able ot define an area to cover rows and columns generated implicitly as part of layout. So has to come after we figure out the size of the grid.<br>
<dbaron> iank_: +1 to starting small. We'd have had to integrate with the column-rule* properties anyway.<br>
<dbaron> iank_: you mentioned images explicitly left out because they're super complicated. Anything else left out initially?<br>
<dbaron> kbabbitt: The other thing was application to tables.<br>
<dbaron> kbabbitt: The underlying spec is still marked as not ready for implementation, probably still some compat differences.<br>
<TabAtkins> q+<br>
<dbaron> kbabbitt: and existing table borders solve many scenarious<br>
<dbaron> iank_: existing table model is different, and gap property doesn't apply there. So makes sense.<br>
<Zakim> lea, you wanted to say I'd rather keep L1 as small as possible (possibly just `row-rule` that is identical to the existing `column-rule` and leave the bells and whistles for later,<br>
<Zakim> ... once we have experience of what authors do<br>
<TabAtkins> q+ about avoiding painting across occupied areas<br>
<dbaron> lea: Just +1 to keeping level 1 super simpler -- get row-role-* as well and maybe a shorthand for both, and see what authors do before adding more.<br>
<florian> q?<br>
<dbaron> fantasai: I was on the queue to disagree with that -- I think the spanning and 2D nature of grid raises a lot of issues not present with multicol. If we don't know how we're going to solve those, we'll likely get ourselves into a bit of a mess as we try to expand to handle those cases properly. I think it's great that this deals with all of those scenarios. I think the first spec draft should continue to do that so we have an idea<br>
<dbaron> fantasai: ...how it all fits together. If some properties marked as at risk or not ready, that's fine.<br>
<dbaron> fantasai: I like that this is handling the gaps. I think the part about grid area stuff I'm a little less sure.<br>
<florian> +1 to fantasai on spec broadly and then trim / at-risk / defer the more advanced parts rather than spec narrowly<br>
<lea> +1 to discussing these issues, my point was about reducing initial implementation burden, the design work should definitely happen<br>
<dbaron> fantasai: your initial value says "1 1 -1 -1" to cover the whole grid -- but that only covers the explicit grid. One of the challenges with grid is that there's no way to address the last line including the implicit grid.<br>
<dbaron> fantasai: Overall looks pretty good, probably some syntax we want to tweak. Glad you through through the intersections carefully.<br>
<Zakim> fantasai, you wanted to say we need to sketch the whole thing<br>
<dbaron> emeyer: haven't read this in detail... but doesn't seem to be a way to select a specific track?<br>
<dbaron> emeyer: let's say I have a week calendar, and I want a rule next to Sunday and Saturday. From what I can see I'd have to do column-rule-color: black transparent transparent ... transparent black.<br>
<dbaron> kbabbitt: Other way to do that is this syntax with grid-row-rule-area specifying 2 areas.<br>
<dbaron> kbabbitt: works like transitions or animations where the area definitions are the controlling properties and the other properties line up.<br>
<dbaron> TabAtkins: quick question: if you want to avoid drawing underneath a large spanning item? Handled by setting up another grid rule area and saying no rules in that area?<br>
<dbaron> kbabbitt: A copule ways to do it. That's one. Also a way to stop short of intersections -- column-rule-outset. Default to running the line through, but can adjust.<br>
<dbaron> TabAtkins: That would work OK if the item was opaque, but if it wasn't you'd need to suppress painting under it.<br>
<dbaron> TabAtkins: one other question: What's the conflict resolution mechanism when 2 areas specify the same gap edge?<br>
<dbaron> kbabbitt: not written yet, but I think your comment said last wins, and I think I agree.<br>
<dbaron> fantasai: meaning in a comma separated list of areas the last one wins?<br>
<iank_> (I think in the default case you likely want to draw behind, e.g. for interactive grids, i.e. a calendar, opacity triggers upon drag, which you want to see the stuff behind for that particular interaction)<br>
<dbaron> fantasai: might want to consider first wins to match font-family and backgrounds?<br>
<dbaron> kbabbitt: I was thinking of painting order.<br>
<dbaron> TabAtkins: conflicting precedence in other properties, e.g., last animation wins.<br>
<florian> q?<br>
<dbaron> fantasai: Any objcetions to starting an editor's draft for this feature?<br>
<dbaron> fantasai: I suggest calling it grid gaps and rules level 2... pull in the gap property.<br>
<dbaron> florian: gaps don't only apply to grid<br>
<dbaron> fantasai: oops, CSS Gaps and Rules<br>
<dbaron> TabAtkins: I don't like starting modules with a new name and numbers greater than 1.<br>
<dbaron> fantasai: Want me to publish a gap level 1 that only has gap?<br>
<dbaron> TabAtkins: I won't stop you from busywork to justify incrementing a number...<br>
<dbaron> fantasai: shortname? css-gaps? ...<br>
<dbaron> kbabbitt: I called it gap-decorations<br>
<dbaron> una: calling it just gaps is about styling the size of the gaps<br>
<dbaron> fantasai: I'm proposing pulling that into the same module<br>
<TabAtkins> css-rules is no good (too many synonyms) so just css-gaps<br>
<dbaron> florian: Calling it gaps alone might make sense when we eventually put in images.<br>
<TabAtkins> css-gaps-and-the-things-that-go-in-them<br>
<dbaron> dbaron: singular or plural?<br>
<dbaron> fantasai: I think plural<br>
<dbaron> fantasai: proposed resolution: import the draft with shortname css-gaps and title CSS Gap Decorations with kbabbitt as editor.<br>
<dbaron> kbabbitt: I don't want people to misinterpret is a document with the shortcomings of CSS!<br>
<dbaron> kbabbitt: what I'm hearing in terms of content is definitely row and rule lines, but areas might get pulled into later level.<br>
<dbaron> fantasai: I think spec what you've got and then decide what to defer.<br>
<dbaron> fantasai: And it starts as an editor's draft, ask for FPWD when you think you're ready. (Doesn't have to be perfect.)<br>
<dbaron> fantasai: as long as it's mostly complete in terms of functionality<br>
<dbaron> RESOLVED: import the draft with shortname css-gaps and title CSS Gap Decorations with kbabbitt as editor.<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10393#issuecomment-2162458484 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 June 2024 08:49:02 UTC