Repository navigation
[css-grid-1] gCS() of grid-row-start/etc properties should return used values? #2681
Description
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.
Activity
emilio commentedon May 30, 2018
cc @MatsPalmgren
css-meeting-bot commentedon May 30, 2018
The Working Group just discussed
gCS() of grid-row-start/etc properties should return used values?, and agreed to the following:RESOLVED: Accept this change but keep the issue open and don't do edits until there's an implementation commitmentThe 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?
<tantek> s/will/willing
<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/
<emilio> s/correct/getPropertyValue
<dael> astearns: Should we reverse resolution?
<dael> TabAtkins: No
fantasai commentedon May 30, 2018
We should put an issue note in the draft though.
MatsPalmgren commentedon May 30, 2018
Gecko: no we don't, fwiw.
What value should be returned for
autoon a grid-aligned abs.pos. child?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.
fantasai commentedon Jun 12, 2018
I think the only sensible thing to do would be to return
auto, since nothing else would make sense.This is true if the author pulls gCS on e.g.
grid-template-columnsas well, though, right? We're already returning used styles for that.[css-grid] Add note about potentially returning used values for gCS()…
fantasai commentedon Dec 11, 2018
Agenda+ to check in with implementers on this issue, since it's been ~6 months.
css-meeting-bot commentedon Dec 12, 2018
The CSS Working Group just discussed
gCS() of grid-row-start/etc properties should return used values?, and agreed to the following:RESOLVED: Return computed value for gCS() for these propertiesThe 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#issuecomment-396441751
<dael> fantasai: We discussed and resolved to accept the change, keep issue open, and don't do edis until impl commitment
<dael> fantasai: Currently these properties return computed, but authors pointed out that there is no way to get used. Straightforward way as gCS() to return that value.
<dael> fantasai: We decided it's a good idea, but no one agreed to impl. So WG said we agree but won't put edits in. That's end of May. I wanted to check where we're at now. Is that something anyone is interested in impl?
<dael> astearns: Mats said there could be perf issue in returning used when call is made
<dael> fantasai: The answer is deafening silence so I'll take that as a no
<dael> florian: How do we make sure we don't forget?
<dael> fantasai: There's a note in the spec
<dael> astearns: Saying we could make change if there's impl interest?
<dael> fantasai: Something to that effect, yeah
<fantasai> note https://github.com/w3c/csswg-drafts/commit/77b8f93eb5b30c408bdd8ca91e4d4d61b3605570
<dael> astearns: Alternative is not to use used and close off this. Find some other way to solve this problem.
<dael> fantasai: Right, we'd need a new API
<dael> astearns: Not hearing impl interest.
<dael> astearns: Objections to not returning the used value in gCS for these properties?
<dael> Rossen: Returning computed values always?
<dael> astearns: Yes
<dael> astearns: New resolution that we return computed value for these properties in gCS
<dael> astearns: Obj?
<dael> RESOLVED: Return computed value for gCS() for these properties
fantasai commentedon Dec 12, 2018
Note this means that if authors want this information exposed, now that we're not reporting it through gCS() we'll need to come up with a specialized API just for Grid. Personally I think that's worse...
Peppertop commentedon Dec 16, 2018
Thanks for discussing this. It seems odd to me that there's a part of the layout engine that can automatically place items, but then no practical way to find out about those placement choices. gCS() would seem to have been a fairly lightweight way to expose that information (compared with a dedicated API), so it's a shame there's no traction there.