Skip to content
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][css-align] How items with synthesized baseline affect the size of intrinsic tracks #1365

Closed
mrego opened this Issue May 12, 2017 · 12 comments

Comments

@mrego
Copy link
Member

mrego commented May 12, 2017

Let's try to explain an issue we're hitting while trying to implement baseline alignment on CSS Grid Layout.

The example is a bit complex, so let's go step by step:

<div style="display: grid; width: 200px; height: 200px;
            grid: auto 50px / 100px 100px; border: solid thick;
            align-items: baseline;">
  <div style="font: 25px/1 Monospace; background: magenta;">
    First<br>item
  </div>
  <div style="writing-mode: vertical-lr;
              font: 25px/1 Ahem; background: cyan;">
    XX X X X X X
  </div>
  <div style="grid-column: span 2; align-self: stretch;
              background: rgba(255, 255, 0, 0.5);">
  </div>
</div>

Columns have a fixed size, so we don't need to care about them.

Regarding rows, on the first run of the grid track sizing algorithm, to calculate the size of the first row it checks the heights of the items inside:

  • 1st item (magenta) has a 50px height.
  • 2nd item (cyan) is vertical, so its height has a range between 50px (the min-content size) and 300px (the max-content size).

As the 2nd row has 50px and the grid container has a fixed height of 200px, the 1st row ends up being 150px tall.

Status of the grid after the first pass

Until here everything seems pretty clear. Let's move to the funny part.

Now we calculate the baselines to apply the alignment to the items in the first row.

  • 1st item (magenta) baseline is 25px (height of the first line).
  • 2nd item (cyan) as is vertical we use the synthesized baseline, so the bottom of the element 150px.

We take the biggest one 150px baseline and calculate the baseline offsets:

  • 1st item (magenta) 150px - 25px = 125px. We add a kind of 125px margin to the item.
  • 2nd item (cyan) 150px - 150px = 0px. No changes here.

Status of the grid when we apply baseline alignment

Here the min-content contribution of the first item has changed, before it was 50px, and now it's 175px = 125px (the baseline offset) + 50px (its height). So we've to do a new run of the algorithm.

In this second run to compute the size of the first row we do:

  • 1st item (magenta) has a 175px "height" now (it's not really its height but its min-content contribution due to the baseline alignment).
  • 2nd item (cyan) has a range between 50px and 300px.

The first row has to be now 175px height, the 2nd row is fixed so it has 50px height and it overflows the container (not a big deal as that's what happens in similar cases without baseline alignment).

Problem comes now, what should we do at this point?

Option 1)

Following the approach above, we'd recompute the baselines offests:

  • 1st item (magenta) the baseline is 150px = 125px (from the previous run) + 25x (height of the first line).
  • 2nd item (cyan) this item has now a height of 175px, so 175px.

The biggest baseline is 175px so we calculate the offsets again:

  • 1st item (magenta) 175px - 150px = 25px. We move the item down 25px more.
  • 2nd item (cyan) 175px - 175px = 0px. We don't do any change.

Then we'd stop, as the algorithm just ask to repeat it only once.
The result would be:

  • 1st row: 175px.
  • 2nd row: 50px, overflowing the grid container.
  • 1st item (magenta): 50px height (with a 150px baseline offset), overflowing the 2nd row.
  • 2nd item (cyan): 175px height, no oveflow.

Status of the grid following option 1

Option 2)

We avoid to recompute the baselines and reuse the biggest one from the previous run, which was 150px.

Then we calculate the new offsets:

  • 1st item (magenta) 150px - 150px (current "height") = 0px. We don't move it further.
  • 2nd item (cyan) 150px - 175px (current height) = -25px. We move it up 25px.

Again, this is the 2nd run so we stop at this point.
The result would be:

  • 1st row: 175px.
  • 2nd row: 50px (overflowing the grid container).
  • 1st item (magenta): 50px height (with a 125px baseline offset), not overflowing the 2nd row.
  • 2nd item (cyan): 175px height (with a -25px baseline offset), overflowing the 1st row on the top and not reaching the bottom of the row.

Status of the grid following option 2

Option 3)

As a last resort we could think on a different approach that would be to ignore the items with synthesized baseline. So in this case both items will be on the top of the first row and have a height of 50px and 150px (so the row would be 150px). But probably we don't want this.

What do you think?

@tabatkins

This comment has been minimized.

Copy link
Member

tabatkins commented Jun 21, 2017

I'm thinking that, since this is a bad situation in any case (trying to baseline-align orthogonal flows), I'm okay with the result that we currently get from the spec (option 1). Option 2 looks at least as bad, and would involve some changes I'm not confident about, and option 3 goes against the entire reasoning for having synthesized baselines.

The result isn't pretty, but it's both (a) rare, and (b) well-defined already, so I'm okay with it as it is.

@javifernandez

This comment has been minimized.

Copy link
Contributor

javifernandez commented Jun 27, 2017

I'm thinking that, since this is a bad situation in any case (trying to baseline-align orthogonal flows), I'm okay with the result that we currently get from the spec (option 1).

I'm ok with this decision. I didn't have any preference and current behavior is as good as any other option. The only issue worth discussing would be the fact that Baseline Alignment alters box's intrinsic size. If we end up removing that behavior, implementation would be considerably simpler.

@tabatkins

This comment has been minimized.

Copy link
Member

tabatkins commented Jul 20, 2017

The problem is that the cyan box is allowed to grow into the new space cleared out below it by aligning to the baseline of the pink box. If we can prevent that growth from happening, then the cyan's baseline will stay the same in both rounds, and the layout stabilizes in the second round.

Suggestion, then: when we do self-baseline-alignment, we add pretend-margin to both sides of the boxes, so that all the aligned boxes have identical margin-box sizes.

In this example, then, the first round would give the pink box 125px of top margin, and the cyan box 25px of bottom margin (so both have a margin-box height of 175px). Then, when we go into the second round, both boxes already exactly fit into the new 175px row height. The cyan box's synthesized baseline is still at 150px, so the pink box is already aligned with it, and layout is finished. The yellow box still overflows the grid container by 25px, but otherwise things fit together nicely.

What this means is that, if there are larger items in the row, the cyan item will not resize to fit the row. And we haven't solved that there will be some overflow in this case even though it's theoretically not necessary. But at least its size should be stabilized across cycles.

Thoughts? We're not sure at the moment whether this is only needed for self-alignment, or whether it would apply to the pretend-padding of content alignment too.

~TJ and fantasai

@astearns astearns removed the Agenda+ F2F label Aug 1, 2017

tabatkins added a commit that referenced this issue Oct 13, 2017

[css-grid] Try to handle baseline-aligned items whose height depends …
…on the size of the track, by ignoring them. Related to #1365.

tabatkins added a commit that referenced this issue Oct 17, 2017

[css-grid] Revert early attempt at fixing baseline-alignment for item…
…s with circular sizing dependencies. Related to #1365.
@tabatkins

This comment has been minimized.

Copy link
Member

tabatkins commented Oct 17, 2017

Our current proposal is to simply detect when there's a circularity in sizing for baseline-aligned things (that is, when an item depends on the size of the track), and disable their baseline alignment so that they fall back to start/end alignment. In the first example in this thread, then, the first image is also the final one, because the teal item is no longer baseline-aligning (and becomes start-aligned instead) and the magenta item now has nothing else to baseline-align to (and so start-aligns as much as possible).

We considered just ignoring the circular items for sizing purposes (the step added in #1039) but still allowing it to baseline-align at the end of layout like normal, but in the common case this will cause the item to overflow upwards, and we can't come up with a single use-case where this seems desired in the first place. (Hence the changes added/reverted above.)

Thoughts?

@javifernandez

This comment has been minimized.

Copy link
Contributor

javifernandez commented Oct 30, 2017

I think this simplification makes sense. I agree it will solve these and many other cases, related to baseline regular and orthogonal items.

Shouldn't we add something regarding ignoring the circular items for baseline-alignment purposes ? Perhaps we can add something here:

https://drafts.csswg.org/css-align-3/#baseline-values

We could state there that items with a size dependent on its content area (in the appropriated axis) don't share the baseline alignment context.

@tabatkins tabatkins added the Agenda+ label Nov 14, 2017

@css-meeting-bot

This comment has been minimized.

Copy link
Member

css-meeting-bot commented Nov 22, 2017

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.
The full IRC log of that discussion <dael> Topic: How items with synthesized baseline affect the size of intrinsic tracks
<astearns> github: https://github.com//issues/1365
<TabAtkins> Sorry, was finishing up cleaning the house. Logged in now
<dael> github: https://github.com//issues/1365
<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.
<dael> fantasai: Our current proposal is to detect when we're in this case and say you don't get baseline-alignment.
<dael> TabAtkins: This case being anything that depends on size of track cannot be baseline aligned.
<dael> TabAtkins: Image with height 100% or ortogonal flow.
<dael> fantasai: Anything that depends on size of the track when track is sized based on its contents.
<dael> fantasai: We're happy to consider other solutions, but we can't figure out a reason why you'd do this.
<dael> TabAtkins: Igalia folk are happy with this resolution.
<dael> Rossen_: Have you looked at what current impl do?
<dael> Rossen_: I just ran the code sample in the issue and there seems to be mild interop.
<dael> Rossen_: This would prob. mean a change for FF and Edge.
<dael> fantasai: FF looks like it wouldn't change.
<dael> fantasai: FF isn't baseline-aligning which would mean no change in this case.
<dael> Rossen_: Maybe I got your point backwards.
<dael> Rossen_: This would be change for Chrome, not FF or Edge
<dael> TabAtkins: In so far that you don't baseline align at all yet, yeah it's no change.
<dael> TabAtkins: Chrome does require change, but igalia folk are happy so we're fine to change.
<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.
<dael> Rossen_: We do currently do that.
<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.
<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
<dael> TabAtkins: If you're doing an okay job, you're not following spec.
<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.
<dael> Rossen_: Yeah, FF doesn't do it.
<dael> Rossen_: You're saying you guys are willing to change?
<dael> TabAtkins: Yeah. Manuel brought up the issue.
<dael> astearns: So we could resolve on this and as Edge continues to impl if you have something better propose it?
<dbaron> gsnedders, ah, https://github.com/web-platform-tests/wpt/pull/8150
<xidorn> gsnedders: that's all? I... thought we have more...
<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.
<dbaron> gsnedders, no, I was thinking of a different set of tests
<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.
<dael> Rossen_: Okay. I'm okay with the issue.
<gsnedders> xidorn: all from that directory, excluding a couple of files that are unspec'd behaviour IIRC
<dbaron> gsnedders: there's a different directory, layout/reftests/counter-style/
<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.
<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.
<dael> fantasai: I think taht was the general case. THis is a particular case with a cyclic dependency.
<dael> Rossen_: I'm not gonna object, but I'm pretty sure this won't be the last time we discuss.
<dael> fantasai: I hope someone has a solution that gets is better results if we discuss again
<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.
<dael> astearns: Obj?
<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.
@fantasai

This comment has been minimized.

Copy link
Contributor

fantasai commented Nov 27, 2017

Edits checked in! Please let us know if it needs further clarification.

@javifernandez

This comment has been minimized.

Copy link
Contributor

javifernandez commented Nov 30, 2017

Sorry for the delay, I'm still implementing a prototype of the new algorithm to play with some orthogonal cases. As I said before, I think the new text addresses the problems identified in this issue, but I think we may have to add some minor changes to the current text to deal properly with some orthogonal cases.

I'll provide the required examples soon and will define the WPT when I started the actual implementation.

@mrego

This comment has been minimized.

Copy link
Member Author

mrego commented Nov 30, 2017

Just as a summary I'm attaching an image showing the behavior of the example from the first comment on the different browsers and how it'd work with the new proposal.

Status of this issue on the different browsers

The situation is:

  • Chromium: Needs changes.
  • Firefox: It's fine because it doesn't apply baseline to orthogonal flows.
  • Edge: Needs changes.
  • Safari: It's not implementing baseline yet, so I'm not even adding a screenshot for it.
@javifernandez

This comment has been minimized.

Copy link
Contributor

javifernandez commented Nov 30, 2017

The new text added states the following:

https://drafts.csswg.org/css-grid/#algo-baseline-shims

Since grid items whose own size depends on the size of an intrinsically-sized track do not participate in baseline alignment, they are not shimmed.

Perhaps I'm understanding it wrong, but I've got the impression that it implies that such items are excluded of participating on baseline alignment on any axis I don't think that's necessary, nor desirable, since the only way of defining baseline alignment along the column axis is using orthogonal items.

I'd like the new text to allow baseline in both dimensions, like this:

2-dimension-baseline

What do you think about being more specific about which baseline axis the item doesn't participate on ?

@tabatkins

This comment has been minimized.

Copy link
Member

tabatkins commented Dec 1, 2017

@mrego Correct.

@javifernandez

Perhaps I'm understanding it wrong, but I've got the impression that it implies that such items are excluded of participating on baseline alignment on any axis I don't think that's necessary, nor desirable, since the only way of defining baseline alignment along the column axis is using orthogonal items.

Notes are not normative, they're just reminders! If you follow the link to the actual normative text in chapters 10.3 and 10.4, it's clear that the "doesn't baseline-align" is per-axis.

@javifernandez

This comment has been minimized.

Copy link
Contributor

javifernandez commented Dec 1, 2017

Yes, it's indeed clear, thanks.

chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue Feb 16, 2018

[css-grid] Baseline alignment inside the tracks sizing algorithm
We have identified several cases where the Baseline Alignment accounts
for the grid's intrinsic size. Since we depend on the track sizing
algorithm to compute the grid's intrinsic size, the only way to handle
all these cases is to integrate the baseline alignment logic in the
algorithm.

Additionally, the CSSWG has identified several cases that can't be
solved properly; such cases have in common that they imply cyclic
dependencies between the item's and grid area's size. The CSSWG has
resolved that these items don't participate in baseline alignment:

w3c/csswg-drafts#1365

There are also other related issues with some examples and relevant
discussions about this topic:

w3c/csswg-drafts#1039
w3c/csswg-drafts#1409

Bug: 704713
Change-Id: I817b16eb43aa76f4827deb8f1f20efb7fde3dc22

chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue Mar 7, 2018

[css-grid] Baseline alignment inside the tracks sizing algorithm
We have identified several cases where the Baseline Alignment accounts
for the grid's intrinsic size. Since we depend on the track sizing
algorithm to compute the grid's intrinsic size, the only way to handle
all these cases is to integrate the baseline alignment logic in the
algorithm.

Additionally, the CSSWG has identified several cases that can't be
solved properly; such cases have in common that they imply cyclic
dependencies between the item's and grid area's size. The CSSWG has
resolved that these items don't participate in baseline alignment:

w3c/csswg-drafts#1365

There are also other related issues with some examples and relevant
discussions about this topic:

w3c/csswg-drafts#1039
w3c/csswg-drafts#1409

Bug: 704713
Change-Id: I817b16eb43aa76f4827deb8f1f20efb7fde3dc22

chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue Mar 19, 2018

[css-grid] Baseline alignment inside the tracks sizing algorithm
We have identified several cases where the Baseline Alignment accounts
for the grid's intrinsic size. Since we depend on the track sizing
algorithm to compute the grid's intrinsic size, the only way to handle
all these cases is to integrate the baseline alignment logic in the
algorithm.

Additionally, the CSSWG has identified several cases that can't be
solved properly; such cases have in common that they imply cyclic
dependencies between the item's and grid area's size. The CSSWG has
resolved that these items don't participate in baseline alignment:

w3c/csswg-drafts#1365

There are also other related issues with some examples and relevant
discussions about this topic:

w3c/csswg-drafts#1039
w3c/csswg-drafts#1409

Bug: 704713
Change-Id: I817b16eb43aa76f4827deb8f1f20efb7fde3dc22

chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue May 21, 2018

[css-grid] Baseline alignment inside the tracks sizing algorithm
We have identified several cases where the Baseline Alignment accounts
for the grid's intrinsic size. Since we depend on the track sizing
algorithm to compute the grid's intrinsic size, the only way to handle
all these cases is to integrate the baseline alignment logic in the
algorithm.

Additionally, the CSSWG has identified several cases that can't be
solved properly; such cases have in common that they imply cyclic
dependencies between the item's and grid area's size. The CSSWG has
resolved that these items don't participate in baseline alignment:

w3c/csswg-drafts#1365

There are also other related issues with some examples and relevant
discussions about this topic:

w3c/csswg-drafts#1039
w3c/csswg-drafts#1409

Bug: 704713
Change-Id: I817b16eb43aa76f4827deb8f1f20efb7fde3dc22

chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue May 22, 2018

[css-grid] Baseline alignment inside the tracks sizing algorithm
We have identified several cases where the Baseline Alignment accounts
for the grid's intrinsic size. Since we depend on the track sizing
algorithm to compute the grid's intrinsic size, the only way to handle
all these cases is to integrate the baseline alignment logic in the
algorithm.

Additionally, the CSSWG has identified several cases that can't be
solved properly; such cases have in common that they imply cyclic
dependencies between the item's and grid area's size. The CSSWG has
resolved that these items don't participate in baseline alignment:

w3c/csswg-drafts#1365

There are also other related issues with some examples and relevant
discussions about this topic:

w3c/csswg-drafts#1039
w3c/csswg-drafts#1409

Bug: 704713
Change-Id: I817b16eb43aa76f4827deb8f1f20efb7fde3dc22

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 28, 2018

[css-grid] Baseline alignment inside the tracks sizing algorithm
We have identified several cases where the Baseline Alignment accounts
for the grid's intrinsic size. Since we depend on the track sizing
algorithm to compute the grid's intrinsic size, the only way to handle
all these cases is to integrate the baseline alignment logic in the
algorithm.

Additionally, the CSSWG has identified several cases that can't be
solved properly; such cases have in common that they imply cyclic
dependencies between the item's and grid area's size. The CSSWG has
resolved that these items don't participate in baseline alignment:

w3c/csswg-drafts#1365

There are also other related issues with some examples and relevant
discussions about this topic:

w3c/csswg-drafts#1039
w3c/csswg-drafts#1409

Bug: 704713
Change-Id: I817b16eb43aa76f4827deb8f1f20efb7fde3dc22

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 29, 2018

[css-grid] Baseline alignment inside the tracks sizing algorithm
We have identified several cases where the Baseline Alignment accounts
for the grid's intrinsic size. Since we depend on the track sizing
algorithm to compute the grid's intrinsic size, the only way to handle
all these cases is to integrate the baseline alignment logic in the
algorithm.

Additionally, the CSSWG has identified several cases that can't be
solved properly; such cases have in common that they imply cyclic
dependencies between the item's and grid area's size. The CSSWG has
resolved that these items don't participate in baseline alignment:

w3c/csswg-drafts#1365

There are also other related issues with some examples and relevant
discussions about this topic:

w3c/csswg-drafts#1039
w3c/csswg-drafts#1409

Bug: 704713
Change-Id: I817b16eb43aa76f4827deb8f1f20efb7fde3dc22

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 29, 2018

[css-grid] Baseline alignment inside the tracks sizing algorithm
We have identified several cases where the Baseline Alignment accounts
for the grid's intrinsic size. Since we depend on the track sizing
algorithm to compute the grid's intrinsic size, the only way to handle
all these cases is to integrate the baseline alignment logic in the
algorithm.

Additionally, the CSSWG has identified several cases that can't be
solved properly; such cases have in common that they imply cyclic
dependencies between the item's and grid area's size. The CSSWG has
resolved that these items don't participate in baseline alignment:

w3c/csswg-drafts#1365

There are also other related issues with some examples and relevant
discussions about this topic:

w3c/csswg-drafts#1039
w3c/csswg-drafts#1409

Bug: 704713
Change-Id: I817b16eb43aa76f4827deb8f1f20efb7fde3dc22

aarongable pushed a commit to chromium/chromium that referenced this issue May 29, 2018

[css-grid] Baseline alignment inside the tracks sizing algorithm
We have identified several cases where the Baseline Alignment accounts
for the grid's intrinsic size. Since we depend on the track sizing
algorithm to compute the grid's intrinsic size, the only way to handle
all these cases is to integrate the baseline alignment logic in the
algorithm.

Additionally, the CSSWG has identified several cases that can't be
solved properly; such cases have in common that they imply cyclic
dependencies between the item's and grid area's size. The CSSWG has
resolved that these items don't participate in baseline alignment:

w3c/csswg-drafts#1365

There are also other related issues with some examples and relevant
discussions about this topic:

w3c/csswg-drafts#1039
w3c/csswg-drafts#1409

Bug: 704713
Change-Id: I817b16eb43aa76f4827deb8f1f20efb7fde3dc22
Reviewed-on: https://chromium-review.googlesource.com/923261
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Reviewed-by: Sergio Villar <svillar@igalia.com>
Cr-Commit-Position: refs/heads/master@{#562406}

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 29, 2018

[css-grid] Baseline alignment inside the tracks sizing algorithm
We have identified several cases where the Baseline Alignment accounts
for the grid's intrinsic size. Since we depend on the track sizing
algorithm to compute the grid's intrinsic size, the only way to handle
all these cases is to integrate the baseline alignment logic in the
algorithm.

Additionally, the CSSWG has identified several cases that can't be
solved properly; such cases have in common that they imply cyclic
dependencies between the item's and grid area's size. The CSSWG has
resolved that these items don't participate in baseline alignment:

w3c/csswg-drafts#1365

There are also other related issues with some examples and relevant
discussions about this topic:

w3c/csswg-drafts#1039
w3c/csswg-drafts#1409

Bug: 704713
Change-Id: I817b16eb43aa76f4827deb8f1f20efb7fde3dc22
Reviewed-on: https://chromium-review.googlesource.com/923261
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Reviewed-by: Sergio Villar <svillar@igalia.com>
Cr-Commit-Position: refs/heads/master@{#562406}

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 31, 2018

[css-grid] Baseline alignment inside the tracks sizing algorithm
We have identified several cases where the Baseline Alignment accounts
for the grid's intrinsic size. Since we depend on the track sizing
algorithm to compute the grid's intrinsic size, the only way to handle
all these cases is to integrate the baseline alignment logic in the
algorithm.

Additionally, the CSSWG has identified several cases that can't be
solved properly; such cases have in common that they imply cyclic
dependencies between the item's and grid area's size. The CSSWG has
resolved that these items don't participate in baseline alignment:

w3c/csswg-drafts#1365

There are also other related issues with some examples and relevant
discussions about this topic:

w3c/csswg-drafts#1039
w3c/csswg-drafts#1409

Bug: 704713
Change-Id: I817b16eb43aa76f4827deb8f1f20efb7fde3dc22
Reviewed-on: https://chromium-review.googlesource.com/923261
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Reviewed-by: Sergio Villar <svillar@igalia.com>
Cr-Commit-Position: refs/heads/master@{#562406}

Hexcles added a commit to web-platform-tests/wpt that referenced this issue May 31, 2018

[css-grid] Baseline alignment inside the tracks sizing algorithm
We have identified several cases where the Baseline Alignment accounts
for the grid's intrinsic size. Since we depend on the track sizing
algorithm to compute the grid's intrinsic size, the only way to handle
all these cases is to integrate the baseline alignment logic in the
algorithm.

Additionally, the CSSWG has identified several cases that can't be
solved properly; such cases have in common that they imply cyclic
dependencies between the item's and grid area's size. The CSSWG has
resolved that these items don't participate in baseline alignment:

w3c/csswg-drafts#1365

There are also other related issues with some examples and relevant
discussions about this topic:

w3c/csswg-drafts#1039
w3c/csswg-drafts#1409

Bug: 704713
Change-Id: I817b16eb43aa76f4827deb8f1f20efb7fde3dc22
Reviewed-on: https://chromium-review.googlesource.com/923261
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Reviewed-by: Sergio Villar <svillar@igalia.com>
Cr-Commit-Position: refs/heads/master@{#562406}

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jun 10, 2018

Bug 1438730 [wpt PR 9553] - [css-grid] Baseline alignment inside the …
…tracks sizing algorithm, a=testonly

Automatic update from web-platform-tests[css-grid] Baseline alignment inside the tracks sizing algorithm

We have identified several cases where the Baseline Alignment accounts
for the grid's intrinsic size. Since we depend on the track sizing
algorithm to compute the grid's intrinsic size, the only way to handle
all these cases is to integrate the baseline alignment logic in the
algorithm.

Additionally, the CSSWG has identified several cases that can't be
solved properly; such cases have in common that they imply cyclic
dependencies between the item's and grid area's size. The CSSWG has
resolved that these items don't participate in baseline alignment:

w3c/csswg-drafts#1365

There are also other related issues with some examples and relevant
discussions about this topic:

w3c/csswg-drafts#1039
w3c/csswg-drafts#1409

Bug: 704713
Change-Id: I817b16eb43aa76f4827deb8f1f20efb7fde3dc22
Reviewed-on: https://chromium-review.googlesource.com/923261
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Reviewed-by: Sergio Villar <svillar@igalia.com>
Cr-Commit-Position: refs/heads/master@{#562406}

--

wpt-commits: 82b278966038f26cb83ceeb67404b0ce7e13a74c
wpt-pr: 9553

xeonchen pushed a commit to xeonchen/gecko-cinnabar that referenced this issue Jun 12, 2018

Bug 1438730 [wpt PR 9553] - [css-grid] Baseline alignment inside the …
…tracks sizing algorithm, a=testonly

Automatic update from web-platform-tests[css-grid] Baseline alignment inside the tracks sizing algorithm

We have identified several cases where the Baseline Alignment accounts
for the grid's intrinsic size. Since we depend on the track sizing
algorithm to compute the grid's intrinsic size, the only way to handle
all these cases is to integrate the baseline alignment logic in the
algorithm.

Additionally, the CSSWG has identified several cases that can't be
solved properly; such cases have in common that they imply cyclic
dependencies between the item's and grid area's size. The CSSWG has
resolved that these items don't participate in baseline alignment:

w3c/csswg-drafts#1365

There are also other related issues with some examples and relevant
discussions about this topic:

w3c/csswg-drafts#1039
w3c/csswg-drafts#1409

Bug: 704713
Change-Id: I817b16eb43aa76f4827deb8f1f20efb7fde3dc22
Reviewed-on: https://chromium-review.googlesource.com/923261
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Reviewed-by: Sergio Villar <svillar@igalia.com>
Cr-Commit-Position: refs/heads/master@{#562406}

--

wpt-commits: 82b278966038f26cb83ceeb67404b0ce7e13a74c
wpt-pr: 9553

@fantasai fantasai added this to the css-grid-1 CR 2016-09-29+ milestone Jan 22, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.