15:14:42 Why does the production include square brackets [] wrapping the ? https://drafts.csswg.org/css-grid/#typedef-line-names And is this something that will show up in other property value syntaxes in the future? 15:39:44 innovati: it's wrapping a group of (one or more) custom idents - the grouping is what is prompting the brackets 15:43:01 hmm - I suppose it's actually zero or more, but I don't know what happens when you add [] to a track list 15:43:06 Thanks! That makes sense, though it's interesting that grid-template-areas doesn't use this 15:44:18 there you just have the group by itself - you don't need the brackets to make the group fit in with other values 17:47:20 astearns: Nothing happens, it's just no names there. 17:47:36 innovati: It's not a general pattern, no. It's there to let us distinguish line names from track sizes. 17:59:51 This is what I'm thinking about, and though it's for a custom property value, I want to design it in the most CSSey way: https://gist.github.com/tomhodgins/5d731bc444696eacc53d4b39cea35bda 19:45:32 First, that production should absolutely be using commas. 19:45:47 Oh wait no I see what you're doing with that 20:34:21 astearns, there's an example of [ cutsom-ident ] just after the link innovati gave in Grid; it lets you name the lines so yu can refer to them later, e.g. in gtid-column or grid-row, using a subtly different syntax from grid areas :) 20:54:07 innovati: So there are a few ways I might approach that. 20:55:10 First, I might parametrize over the property-name space; claim `--breakpoint-*` so you can do `--breakpoint-width: ; --breakpoint-height: ;`. That way they cascade separately, which might be what you want. 20:56:28 Second would be to wrap the complex value in a function in the shorthand. `--breakpoints: named-breakpoint(width, ), named-breakpoint(height, );`. This makes the separation explicit and lets us use commas *within* the values as well as *between* the values in a non-ambiguous way. 20:56:47 Third and finally, tho I'd try to avoid this if possible, I'd use a `/` to separate the name from the breakpoint list. 20:57:20 I don't like the idea of using a `/` because I might want to express a number like 1/5 20:57:30 Actually, revisiting the second, I'd probably put the breakpoints in a function to begin with: `--width: breakpoints(small 100px large);`. it's a complex data type, give it a name for easier reference and mental parsing. 20:57:51 Then it's much easier to see it in a list: `--breakpoints: width breakpoints(...), height breakpoints(...);` 20:58:34 innovati: That's what calc() is for. / is already used in CSS syntax, you can't rely on using it for naked math operations. Sass is almost done with retiring numeric / outside of calc(), for example. 21:00:15 I think I'm already doing #1, but using the function notation might make the pieces more clear, especially in a shorthand https://codepen.io/tomhodgins/pen/agaeYr 21:01:52 It would be nice if there was some kind of a guide for designing good custom property values to avoid gotchas later on :D 21:03:32 Yeah, it's very much received wisdom from a few of us experienced editors. 21:08:49 Well I am very grateful for the suggestions today :D