Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[css-grid-1] gCS() of grid-row-start/etc properties should return used values? #2681
In #1465, an author requested a way to find out what grid area a grid item ends up occupying, after placement. This seems like a reasonable request! There also seems to be a straightforward way to achieve it - specify that the used values of the grid-row-start/etc properties are the line numbers the item actually lands on, and then specify that gCS() returns the used value of those properties.
(We already have a precedent of several grid-related properties returned used valued for gCS().)
Browser compat on what's returned for those properties today seems to be relatively consistent on returning the specified values, so this would be breaking compat. Whether that's important or not is unclear.
The rest of the requests in #1465 (finding out how many rows/columns are in the implicit grid, and finding out what items overlap a given area) can both be determined from this one change, as you can just iterate over the grid items and build up a map of where they live yourself. We shouldn't need to add any API surface for those.
referenced this issue
May 17, 2018
The Working Group just discussed
The full IRC log of that discussion<dael> Topic: gCS() of grid-row-start/etc properties should return used values?
<dael> github: https://github.com//issues/2681
<dael> TabAtkins: Someone brought up q of, it would b e useful to knowwhat row and column a grid element ended u p in for scripting.
<dael> TabAtkins: The requests are all solvable if we solve this. In particular if you do auto placement. Clearest way to do this is make sure used values are actual lines the properties end up with. Changing gCS to return used value
<dael> TabAtkins: This is a change for all impl, they all return computed. It is more consistant with all other grid properties. Solves a useful use case without us having to add an API. With luck compat is low and huge benefit, but I want to get WG opinion
<dael> astearns: Use value i s a line number index?
<dael> TabAtkins: Yes
<fantasai> +1 to the change, per TabAtkins’ rationale
<dael> emilio: Do impl preserve that info after layout? not sure they do
<dael> TabAtkins: Don't know, but they have it at some point.
<dael> dbaron: Not a fan of interesting things in gCS. I see used value as legacy not to repeat. Slight pref for sep API but not strong
<gsnedders> I am +1 of dbaron's point here
<dael> TabAtkins: Sep API one thing is a bit awk to compute. He wanted to know how large implicit grid is. I'm okay with either way. Thought pile into gCS is easier, but okay with both
<dael> astearns: There are other things in grid returning used?
<dael> TabAtkins: grid-template properties give used values
<dael> TabAtkins: That's b/c it's how MS and Chrome did it initially
<dael> fantasai: MS asked to keep b/c it was compat for them. We put in spec so Chrome & FF did it.
<dael> fantasai: I think a special API for grid to get interesting things is good. It will take a while to figure out what it should looklike and where it goes and do we want layout mode APIs for other modes. It's a big project. Modifying gCS gets us most of what we want. Information you're otherwise loosing doesn't seem like it's that valuable. You can'tget used values at all.
<dael> fantasai: Since we're already returning used for other things if we switch we let people build the APIs they need to explore the grid.
<dael> fantasai: In general I prefer less exceptions but in this case I think the usefulness and the time it would take to go the other route I think it points that we should change gCS
<dael> astearns: Summary b/c it would take too long to do it right we should do it wrong
<dael> TabAtkins: Not exactly wrong.
<dael> fantasai: If gCS wasn't already a mix of used and computed I would say don't do that. It is a mix and it's largely legacy driven by may was well go with utility
<dael> frremy: I think I agree with proposal. It's useful a nd not complex to do. Makes sense
<dael> astearns: Houdini APIs when you ask computed you'llg et computed?
<dael> TabAtkins: Yes
<dael> fantasai: And that's true in all cases where we return
<dael> dbaron: If you're making a change incompat with all impl you need to have someone commit to try it soon rather then sticking it in and hoping someone will impl in a few years. We don't want dependencies on that decisionn.
<dael> TabAtkins: Valid, yes.
<tantek> right, who is will to provide an intent to implement this?
<dael> frremy: I'm not technically worried. Right now you get auto. If you're trying to do something with that you'll get a right value. I don't htink it's a compat problem. I agree we should impl sooner rather then later.
<dael> astearns: Are you volunteering?
<dael> frremy: Don't know about that. But don't think it's complex. We should do it.
<dael> astears: Any volunteers?
<dael> TabAtkins: I'll ask Igalia folks and bring it back
<dael> astearns: dbaron has a point that longer it sits in spec moldering the worse it'll be.
<dael> astearns: We can wait on resolving until a commitment. We can resolve and revisit in a month and if not move to impl revert?
<dael> TabAtkins: Resolve to do the change, not change spec until commits, and add edits in a month if someone adds
<AmeliaBR> There probably needs to be at least a resolution that implementers can point to in their bug trackers.
<dael> astearns: prop: Accept this change but keep the issue open and don't do edits until there's an impl commitment
<dael> astearns: Obj?
<dael> RESOLVED: Accept this change but keep the issue open and don't do edits until there's an implementation commitment
<dael> astearns: AmeliaBR has a point it would be great if people could put an issue in your own bug tracker
<dael> emilio: I looked at other grid properties. it's kind of slow but it works. I'll file and CC him. If no strong opinion I can impl.
<dael> TabAtkins: Since gCS requires compute up front that is an argument for sep API. Then we can lazy compute
<dael> dbaron: [missed] because it's a live object
<dael> emilio: Right. You only compute when do correct call
<dael> TabAtkins: Right, nevermind.
<dbaron> s/[missed]/it doesn't require computing everything up front/
<dael> astearns: Should we reverse resolution?
<dael> TabAtkins: No
Gecko: no we don't, fwiw.
What value should be returned for
Note: returning used values means we have to flush any pending style / layout changes to get the correct value. This can lead to performance issues.
I think the only sensible thing to do would be to return
This is true if the author pulls gCS on e.g.