W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2017

Re: [csswg-drafts] [css-grid][css-align] How items with synthesized baseline affect the size of intrinsic tracks

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 22 Nov 2017 17:35:55 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-346422610-1511372154-sysbot+gh@w3.org>
The Working Group just discussed `How items with synthesized baseline affect the size of intrinsic tracks`, and agreed to the following resolutions:

* `RESOLVED: When the track depends on the size of its contents and the item depends on the size of the track it cannot be baseline aligned.`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: How items with synthesized baseline affect the size of intrinsic tracks<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/1365<br>
&lt;TabAtkins> Sorry, was finishing up cleaning the house. Logged in now<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/1365<br>
&lt;dael> fantasai: We looked through this issue which is a problem with the way baseline sizing has a loop with things that depend on size of row. You can see in example we size all the items and you can see we have a circle for analysis.<br>
&lt;dael> fantasai: Our current proposal is to detect when we're in this case and say you don't get baseline-alignment.<br>
&lt;dael> TabAtkins: This case being anything that depends on size of track cannot be baseline aligned.<br>
&lt;dael> TabAtkins: Image with height 100% or ortogonal flow.<br>
&lt;dael> fantasai: Anything that depends on size of the track when track is sized based on its contents.<br>
&lt;dael> fantasai: We're happy to consider other solutions, but we can't figure out a reason why you'd do this.<br>
&lt;dael> TabAtkins: Igalia folk are happy with this resolution.<br>
&lt;dael> Rossen_: Have you looked at what current impl do?<br>
&lt;dael> Rossen_: I just ran the code sample in the issue and there seems to be mild interop.<br>
&lt;dael> Rossen_: This would prob. mean a change for FF and Edge.<br>
&lt;dael> fantasai: FF looks like it wouldn't change.<br>
&lt;dael> fantasai: FF isn't baseline-aligning which would mean no change in this case.<br>
&lt;dael> Rossen_: Maybe I got your point backwards.<br>
&lt;dael> Rossen_: This would be change for Chrome, not FF or Edge<br>
&lt;dael> TabAtkins: In so far that you don't baseline align at all yet, yeah it's no change.<br>
&lt;dael> TabAtkins: Chrome does require change, but igalia folk are happy so we're fine to change.<br>
&lt;dael> rego: We were looking. We wanted to investigate in the next weeks, but we think we're fine. FF doesn't baseline align orthgolnal so it's not change.<br>
&lt;dael> Rossen_: We do currently do that.<br>
&lt;dael> Rossen_: Looking at the 3 impl side by side, I see what you mean. FF basically doesn't do it.  We do an okay job in the test case from the issue.<br>
&lt;gsnedders> dbaron, fantasai, xidorn: wrt counter-styles tests, there's a PR containing all the tests from mozilla-central that I posted while at TPAC<br>
&lt;dael> TabAtkins: If you're doing an okay job, you're not following spec.<br>
&lt;dael> Rossen_: Yeah. By okay job I mean slightly better then Chrome, we fit all the items in the blue section, but alignment and track sizes are pretty much the same.<br>
&lt;dael> Rossen_: Yeah, FF doesn't do it.<br>
&lt;dael> Rossen_: You're saying you guys are willing to change?<br>
&lt;dael> TabAtkins: Yeah. Manuel brought up the issue.<br>
&lt;dael> astearns: So we could resolve on this and as Edge continues to impl if you have something better propose it?<br>
&lt;dbaron> gsnedders, ah, https://github.com/w3c/web-platform-tests/pull/8150<br>
&lt;xidorn> gsnedders: that's all? I... thought we have more...<br>
&lt;dael> Rossen_: Our impl is shipping. We're not changing anything. but it's rolling out with that behavior. Which means you'll have two impl matching in this case, regardless of following spec.<br>
&lt;dbaron> gsnedders, no, I was thinking of a different set of tests<br>
&lt;dael> TabAtkins: Okay. We're willing to change because the behavior is objectively bad. No one would want the behavior currently desc in the spec.<br>
&lt;dael> Rossen_: Okay. I'm okay with the issue.<br>
&lt;gsnedders> xidorn: all from that directory, excluding a couple of files that are unspec'd behaviour IIRC<br>
&lt;dbaron> gsnedders: there's a different directory, layout/reftests/counter-style/<br>
&lt;dael> TabAtkins: When the track depends on the size of its contents and the item depends on the size of the track it cannot be baseline aligned.<br>
&lt;dael> Rossen_: I think I spent two hours chatting with fantasai on this at the F2F in Paris and, at the time, we went back and forth and I think we were on the same page.<br>
&lt;dael> fantasai: I think taht was the general case. THis is a particular case with a cyclic dependency.<br>
&lt;dael> Rossen_: I'm not gonna object, but I'm pretty sure this won't be the last time we discuss.<br>
&lt;dael> fantasai: I hope someone has a solution that gets is better results if we discuss again<br>
&lt;dael> astearns: Proposed is: When the track depends on the size of its contents and the item depends on the size of the track it cannot be baseline aligned.<br>
&lt;dael> astearns: Obj?<br>
&lt;dael> RESOLVED: When the track depends on the size of its contents and the item depends on the size of the track it cannot be baseline aligned.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1365#issuecomment-346422610 using your GitHub account
Received on Wednesday, 22 November 2017 17:35:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 22 November 2017 17:36:03 UTC