- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 May 2018 16:30:23 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: gCS() of grid-row-start/etc properties should return used values?<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/2681<br> <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.<br> <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<br> <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<br> <dael> astearns: Use value i s a line number index?<br> <dael> TabAtkins: Yes<br> <fantasai> +1 to the change, per TabAtkins’ rationale<br> <dael> emilio: Do impl preserve that info after layout? not sure they do<br> <dael> TabAtkins: Don't know, but they have it at some point.<br> <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<br> <gsnedders> I am +1 of dbaron's point here<br> <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<br> <dael> astearns: There are other things in grid returning used?<br> <dael> TabAtkins: grid-template properties give used values<br> <dael> TabAtkins: That's b/c it's how MS and Chrome did it initially<br> <dael> fantasai: MS asked to keep b/c it was compat for them. We put in spec so Chrome & FF did it.<br> <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.<br> <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.<br> <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<br> <dael> astearns: Summary b/c it would take too long to do it right we should do it wrong<br> <dael> TabAtkins: Not exactly wrong.<br> <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<br> <dael> frremy: I think I agree with proposal. It's useful a nd not complex to do. Makes sense<br> <dael> astearns: Houdini APIs when you ask computed you'llg et computed?<br> <dael> TabAtkins: Yes<br> <dael> fantasai: And that's true in all cases where we return<br> <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.<br> <dael> TabAtkins: Valid, yes.<br> <tantek> right, who is will to provide an intent to implement this?<br> <tantek> s/will/willing<br> <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.<br> <dael> astearns: Are you volunteering?<br> <dael> frremy: Don't know about that. But don't think it's complex. We should do it.<br> <dael> astears: Any volunteers?<br> <dael> TabAtkins: I'll ask Igalia folks and bring it back<br> <dael> astearns: dbaron has a point that longer it sits in spec moldering the worse it'll be.<br> <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?<br> <dael> TabAtkins: Resolve to do the change, not change spec until commits, and add edits in a month if someone adds<br> <AmeliaBR> There probably needs to be at least a resolution that implementers can point to in their bug trackers.<br> <dael> astearns: prop: Accept this change but keep the issue open and don't do edits until there's an impl commitment<br> <dael> astearns: Obj?<br> <dael> RESOLVED: Accept this change but keep the issue open and don't do edits until there's an implementation commitment<br> <dael> astearns: AmeliaBR has a point it would be great if people could put an issue in your own bug tracker<br> <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.<br> <dael> TabAtkins: Since gCS requires compute up front that is an argument for sep API. Then we can lazy compute<br> <dael> dbaron: [missed] because it's a live object<br> <dael> emilio: Right. You only compute when do correct call<br> <dael> TabAtkins: Right, nevermind.<br> <dbaron> s/[missed]/it doesn't require computing everything up front/<br> <emilio> s/correct/getPropertyValue<br> <dael> astearns: Should we reverse resolution?<br> <dael> TabAtkins: No<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2681#issuecomment-393227464 using your GitHub account
Received on Wednesday, 30 May 2018 16:30:27 UTC