[css-grid] grammar of grid-row-start and friends is ugly and harms value space for line names

[therealglazou]

Ref: https://drafts.csswg.org/css-grid/#line-placement

I am currently implementing editing support for CSS grids in BlueGriffon and I must say the "span" keyword that can appear in the values of grid-row-start, grid-column-start, grid-row-end and grid-column-end is very ugly, and painful in terms of UX in a content editor. It also requires the following provision in the prose:

In all the above productions, the custom-ident additionally excludes the keyword span.

and given the richness of the CSS grammar, I am surprised we ended up with such a restriction of the value space of line names.
Can't we do better that, and instead of

grid-row-start: span 3 myline

have (that's only an example, many other options are possible)

grid-row-start: (3 myline)

I think it's not only cosmetic. The parser for these properties' values will be a bit simpler, line names will suffer no restriction, and my content editor will not have to exclude one single word without explanation. Even with an explanation, the exclusion of "span" just for the grammar of these properties seems a failure, IMHO.

[fantasai]

@therealglazou 3 and span 3 mean two different things, so I don't understand what you're proposing at all.

(Also, I think it's too late to change the syntax. We did ask multiple times for people to comment and suggest improvements, but nobody did so. :( )

[jensimmons]

You asked me to chime in. I'm not sure what you are proposing here. Could you list examples of the current syntax (for context), and samples of a proposed different way the exact same lines of code would work?

[jensimmons]

And yes, it's awfully late to want to change it. Since it just shipped.

[rachelandrew]

The syntax makes a lot of sense to authors as well, and for future readability of code. People get the idea of span 3 - it's human readable rather than a syntax that means span 3 but doesn't say that.

[tabatkins]

Grid is definitely far into the "only bugfixes" stage of its lifetime, and will very quickly be in the "even then, be careful about webcompat" stage. That means syntax changes that aren't fixing a serious error are basically auto-rejected at this point.

But also, like fantasai, I'm not sure what you're actually proposing.

[frivoal]

@therealglazou, is what you have in mind something like this:

<grid-line> =
  auto |
  <custom-ident> |
  [ <integer> && <custom-ident>? ] |
  span( <integer> || <custom-ident> )

[therealglazou]

Please all note I will live with a no-change decision but what @frivoal wrote above seems to me a MUCH better syntax than the one that is currently in the spec.

For the record : we introduce a special keyword ("span") used as a discriminator between two different value syntaxes, and a side effect of it is an impact on the value space of line names. I understand it is very late to highlight it but I understood its bad design (because it's really bad design, we should never have done that and we should never do it again) only when I started implementing it. Editors will have to specifically reject the line name "span" in all UI, and there is honestly no good reason beyond a "yeah, well, we used that name as a special keyword somewhere so you can't use it yourself".

About "shipped", "not changeable", "awafully late", we're still in CR and the feature should still be considered as experimental, right? And CR is meant to be the last step to detect such important design or technical errors, right? If not, I suggest AC-Reps reach out to W3M to let them know PR and REC have no meaning any more.

[fantasai]

It's no longer considered experimental. CR is changeable, but focus isn't on experiment but deployment. See https://www.w3.org/TR/CSS/#future-proofing -- CR is when we consider something “ready to implement and ship”. We spent years working out details and asking for feedback on anything and everything; at some point we think we're done, and we ask the WG if it's sure, and then we move to CR. That was six months ago. At this point, the syntax of Grid has been implemented, shipped in 5 browsers, and, more significantly, taught in courses across the world. We have the ability to modify behavior somewhat, but syntax I think it's too late...

[frivoal]

Grid is unusual for having matured slowly in private for a long time and then shipped in a coordinated fashion by most UAs. This means that market adoption is very rapid, and that the post-CR-but-can-still-change-things-without-breaking-the-web window is unusually short.

I do think it is valid for Daniel to raise this at this stage: while anybody could have complained about this being a not-so-great syntax in theory at any point in time, the fact that it is particularly bad in editors due to how they need to interactively validate the syntax is indeed something that came out of implementing it and trying it out.

With that said, I think this is likely to be an unfortunate mistake we will have to live with, as syntax changes are particularly prone to causing breakage, and this is not an obscure and unused corner of the spec.

This is not a good situation, but I don't really see what we can do in practice: editors are special type of UAs with special needs, getting feedback about that early in the design cycle would let us make better decisions. But editors also have (much) more limited financial means that browsers, and cannot be expected to be constantly ahead of the curve on every topic, and feedback will therefore come in late on average. We seem to be structurally doomed to make sub-optimal decisions for editors.

[tabatkins]

Grid is unusual for having matured slowly in private for a long time and then shipped in a coordinated fashion by most UAs. This means that market adoption is very rapid, and that the post-CR-but-can-still-change-things-without-breaking-the-web window is unusually short.

That's not very accurate. It had some nice private (within MS) maturation for a while, but it's then spent 5 years out in public, with fantasai and I driving its evolution, and only just now finally got shipped. This isn't a very unusual evolution, and the "window" was several years wide.

---

Anyway, telcon today resolved to close the issue as no change, since this change would cause a large amount of breakage, which isn't tolerable at this maturity stage for the relatively small benefit that the change would bring.

[fantasai]

Filed into http://wiki.csswg.org/ideas/mistakes in case anyone invents a time machine. :)