New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-grid-1] gCS() of grid-row-start/etc properties should return used values? #2681

Open
tabatkins opened this Issue May 17, 2018 · 5 comments

Comments

Projects
None yet
5 participants
@tabatkins
Member

tabatkins commented May 17, 2018

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.

@emilio

This comment has been minimized.

Collaborator

emilio commented May 30, 2018

@css-meeting-bot

This comment has been minimized.

Member

css-meeting-bot commented 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 commitment
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?
<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

This comment has been minimized.

Contributor

fantasai commented May 30, 2018

We should put an issue note in the draft though.

@MatsPalmgren

This comment has been minimized.

MatsPalmgren commented May 30, 2018

Do impl preserve that info after layout? not sure they do

Gecko: no we don't, fwiw.

What value should be returned for auto on 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

This comment has been minimized.

Contributor

fantasai commented Jun 12, 2018

What value should be returned for auto on a grid-aligned abs.pos. child?

I think the only sensible thing to do would be to return auto, since nothing else would make sense.

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.

This is true if the author pulls gCS on e.g. grid-template-columns as well, though, right? We're already returning used styles for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment