- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Feb 2024 21:57:50 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid] Resolved values of grid-template-rows/columns don't round-trip`.
<details><summary>The full IRC log of that discussion</summary>
<fantasai> oriol: Problem is that in grid-template properties, the sizes you assign are assigned only to explicit grid tracks<br>
<florian> s/.../Especially if you have the ability to define variables that are local to the mixing, we run into the kind of problems you have with hygienic macros vs non hygienic macros in lisp<br>
<fantasai> ... but the value you get back includes implicit tracks<br>
<fantasai> oriol: if you try to round-trip, then these implicit track sizes increase the size of the explicit grid<br>
<fantasai> oriol: and change the beahvior<br>
<fantasai> oriol: we considered not including the sizes of the implicit tracks<br>
<fantasai> oriol: but this broke some sites<br>
<fantasai> oriol: Then we thought about offering an alternative API for such websites, but this was along time ago, and probably we have too much dependency<br>
<fantasai> oriol: So we might have to keep the broken behavior<br>
<fantasai> oriol: one idea was to define which line is line #1 in the syntax<br>
<fantasai> oriol: so that you could distinguish the implicit vs explicit tracks<br>
<fantasai> oriol: by marking line 1 or line -1<br>
<fantasai> oriol: it might be more compatible<br>
<fantasai> oriol: but if a website doesn't use line names at all, they might not be expecting line name definitions<br>
<fantasai> oriol: so... possible to be Web-compatible and better than current broken thing?<br>
<fantasai> oriol: so maybe browsers could investigate whether compatible?<br>
<fantasai> oriol: that's the idea.<br>
<fantasai> oriol: The specific syntax would be to use brackets, instead of idents just use '1' or '-1', and could only do this once in the track listing<br>
<fantasai> astearns: I'm not sure I entirely understand the proposal, but sounds like it would be a new syntax that opt into that could round-trip<br>
<fantasai> astearns: but we would still have round-trip problem otherwise?<br>
<fantasai> oriol: we would try to use this syntax when serializing, as a way to distinguish implicit vs explicit tracks<br>
<fantasai> oriol: this way if you assign back the value, you wouldn't be growing the grid, because items would still be placed according to existing line<br>
<fantasai> astearns: would that be true with content changes?<br>
<fantasai> astearns: would there be a scenario where initial content A had a particular layout, and roundtripped value matched, but that if you went and serialized with content A and did roundtrip, would content B give a different result?<br>
<fantasai> TabAtkins: if we end up generating different numbers of implicit tracks because different number of children<br>
<fantasai> TabAtkins: then ... but that wouldn't be different from today<br>
<fantasai> astearns: but the new declared value gives you one result, but don't content A, and then applying round-trip to content B gives you a third layout<br>
<fantasai> TabAtkins: Today if any implicit rows or tracks, you will gradually mutate your grid<br>
<fantasai> TabAtkins: this will prevent you from accidentally mutating your grid<br>
<fantasai> TabAtkins: right now you will add explicit tracks that weren't there originally<br>
<astearns> ack fantasai<br>
<emilio> fantasai: If you're changing the content after you shove the computed value back you're gonna run into two problems<br>
<emilio> ... you're going to have explicit tracks which were explicit<br>
<dholbert> s/were explicit/were implicit/<br>
<emilio> ... but then the non-fixed sizes will not fit their contents<br>
<emilio> ... so either way if you change the content you're going to run into problems<br>
<dholbert> q+<br>
<emilio> ... you run into more problems if we don't fix this<br>
<dholbert> q-<br>
<emilio> ... so that is not super new, the issue is the current behavior will change the number of columns without content changes<br>
<fantasai> iank_: would this break people who are naively parsing?<br>
<emilio> iank_: Is it true that this might break people that are naively parsing the output<br>
<fantasai> oriol: Yeah, if they're not using line-names, they might not be parsing the bracketed line name sets correctly<br>
<fantasai> TabAtkins: We do show line-names in the output if we're using e.g. grid-template-areas<br>
<fantasai> TabAtkins: but it might be in a place you're not expecting line names<br>
<fantasai> TabAtkins: but less likely that it will be completely bad<br>
<fantasai> iank_: Given breakage last time, I think it's still pretty high risk<br>
<fantasai> astearns: are you willing to try it?<br>
<fantasai> iank_: we tried going first last time and broke the world, someone else can try this time :)<br>
<fantasai> astearns: do we have a volunteer?<br>
<fantasai> emilio: I could patch Gecko<br>
<astearns> ack fantasai<br>
<emilio> fantasai: question would be whether we parse these numbers we actually respect the implicit lengths<br>
<emilio> ... or keep our current behavior<br>
<emilio> oriol: haven't thought about that<br>
<fantasai> fantasai: two ways to ignore: one keep in the computed value (acutal computed value, not gCS) but ignore during layout<br>
<fantasai> fantasai: or throw it out during style computation<br>
<emilio> fantasai: third option is not ignoring, would override grid-auto-{rows,columns}<br>
<emilio> ... for the columns for which you have a matching value<br>
<emilio> astearns: we don't know the ramifications of that but don't love to ignore it<br>
<emilio> fantasai: we could ignore it just in gCS<br>
<emilio> ... first question is whether this is compatible at all<br>
<fantasai> s/ignore it/allow it/<br>
<emilio> ... so maybe emilio implements whatever's easier and see that first before figuring this out<br>
<emilio> astearns: iank_, do you know off-hand which sites were broken?<br>
<emilio> oriol: some of them commented in the issue<br>
<emilio> astearns: so leave as is with an experiment to see if this round-tripping idea can work at all<br>
<emilio> ... would that be ok?<br>
<fantasai> emilio: seems fine<br>
<fantasai> emilio: I'll check with oriol about the specifics, but I can do it<br>
<fantasai> iank_: I think webflow was the primary site that broke<br>
<fantasai> astearns: so we leave this issue again, and try out this experiment see whether web-compatible at all, and if it is, work out further details<br>
<dholbert> (other sites that maybe-broke: wix sites, grid critters)<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4475#issuecomment-1939659664 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 12 February 2024 21:57:57 UTC