Re: [csswg-drafts] [css-gaps-1] Grammar for expanded column-rule shorthand (#11496)

The CSS Working Group just discussed `[css-gaps-1] Grammar for expanded column-rule shorthand`, and agreed to the following:

* `RESOLVED: accept the PR to solve this issue`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> kbabbitt: First issue is about gap rule shorthand<br>
&lt;fantasai> kbabbitt: In the future, I wanted to allow different parts of container ot have different gap decorations<br>
&lt;fantasai> kbabbitt: In the current version of the spec, we allow for varying gap decorations within a given region o the container<br>
&lt;fantasai> kbabbitt: For the purposes of the shorthand, specify widths styles colors ...<br>
&lt;fantasai> kbabbitt: For longhand properties to do varying decorations, can specify them all: columnrule-color: red blue ; alternate red/blue<br>
&lt;fantasai> kbabbitt: For shorthand it's more complicated because of additional values<br>
&lt;fantasai> kbabbitt: I previously used slashes to separate width/style/color groups<br>
&lt;fantasai> kbabbitt: wanted to reserve commas for future feature for regions<br>
&lt;fantasai> kbabbitt: Got feedback that slashes were not great for this particular separation<br>
&lt;fantasai> kbabbitt: subsequent discussion, several pointed out that when that feature comes along, we'll need to specify which region each set applies to<br>
&lt;fantasai> kbabbitt: identify the region of the container<br>
&lt;fantasai> kbabbitt: so we could use those indicators as the separators for this set of decorators applies to this region of the grid etc.<br>
&lt;fantasai> kbabbitt: that seems reasonable to me<br>
&lt;fantasai> kbabbitt: indicates that it's safe to use comma for separators for varying decorators within a section<br>
&lt;fantasai> kbabbitt: so that's what I would like to do<br>
&lt;emeyer> scribe+<br>
&lt;astearns> ack fantasai<br>
&lt;emeyer> fantasai: border-radius has a similar problem trying to assign things to different positions<br>
&lt;emeyer> …It also wanted to make sure it had the ability to use repitition<br>
&lt;emeyer> …This seems like a similar problem to what you have here<br>
&lt;emeyer> …You want to be able to specify all the gaps individually, or be able to repeat them<br>
&lt;emeyer> kbabbitt: We do have a repeat pattern defined in the syntax<br>
&lt;emeyer> fantasai: I think I need to read the proposed syntax a little more closely<br>
&lt;astearns> `gap-rule: 1px solid red, 2px solid red [2/2/4/4] 2px dashed silver, 2px dashed gray`<br>
&lt;fantasai> fantasai: Maybe we can have an example?<br>
&lt;emeyer> astearns: Is this representative?<br>
&lt;emeyer> kbabbitt: Yes<br>
&lt;fantasai> kbabbitt: in that example you'd have 1px / 2px alternating across the grid, and then alternating silver and gray in the other section<br>
&lt;emeyer> …In that example, you’d alternate 1px/2px for most of a grid, but within that potrtion of the grid you’d alternate silver and gray<br>
&lt;emeyer> …That would be in a future version; the question here is whether we can use commans to separate portions of the grid<br>
&lt;emeyer> astearns: If I understand, I think in order to more closely follow border-radius, we should use commas to separate values within…<br>
&lt;emeyer> fantasai: border-radius doesn’t use commas, so may not be a good analogy<br>
&lt;fantasai> border-radius:  &lt;length-percentage [0,∞]>{1,4} [ / &lt;length-percentage [0,∞]>{1,4} ]?<br>
&lt;kbabbitt> border-radius: 2em 1em 4em / 0.5em 3em;<br>
&lt;emeyer> fantasai: The slash in border-radius separates the X side and Y side<br>
&lt;emeyer> …I don’t know how applicable this is to gaps<br>
&lt;emeyer> …You usually want to set border and color as a set<br>
&lt;emeyer> …Useage patterns may not be the same<br>
&lt;emeyer> kbabbitt: I got feedback that caused me to raise the issue<br>
&lt;emeyer> fantasai: We could separate regions with commas, but I think it might be confusing<br>
&lt;astearns> q?<br>
&lt;emeyer> …Then again we do use commas to separate lists of things, so following that pattern is a good thing<br>
&lt;emeyer> astearns: I think I’m good with the current proposed PR, not as sure about the extension<br>
&lt;emeyer> kbabbitt: The PR was written assuming extensions will be needed<br>
&lt;emeyer> …Another thing I raised was that we don’t need a separator within a given region<br>
&lt;emeyer> fantasai: But then you have to fix the order of them, and everywhere else we do line styling you can mix the order of width, style, color<br>
&lt;emeyer> …I don’t think we can just use spaces<br>
&lt;emeyer> …Commas is probably the best we can do here and we’ll have to get creative with region styling<br>
&lt;emeyer> astearns: Even if we use something other than commas, commas might still not be right for the extension<br>
&lt;emeyer> …I’µ good with commas and not concerned about being backed into a corner<br>
&lt;emeyer> astearns: Proposed resolution is to accept PR<br>
&lt;emeyer> TabAtkins: I have a tiny technical nit about the grammar but not germane to this issue<br>
&lt;astearns> RESOLVED: accept the PR to solve this issue<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11496#issuecomment-2775767880 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 3 April 2025 13:20:06 UTC