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-2] support automatic grid span for subgrids? #2565

Closed
MatsPalmgren opened this Issue Apr 13, 2018 · 6 comments

Comments

Projects
None yet
5 participants
@MatsPalmgren
Copy link

MatsPalmgren commented Apr 13, 2018

IIRC, the early subgrid specs had a concept of an automatic grid span. I think it might be worth adding that back in some simplified form. If we impose the restriction that the outer grid needs to know the subgrid's extent upfront for placing purposes I think we could at least support making the automatic grid span be the maximum of the extent of the subgrid's grid-template-columns/rows and grid-template-areas properties (the same way those properties provides the size for the explicit grid in non-subgrids).

@tabatkins tabatkins added the css-grid-2 label May 9, 2018

@fantasai

This comment has been minimized.

Copy link
Contributor

fantasai commented Jun 11, 2018

Tagging @rachelandrew and @jensimmons for comment here. It's certainly possible, but I don't know how useful this would be or if there are nearby use cases we should be sure to address when resolving this.

Note that if the subgrid doesn't receive line names from its parent grid, we could even resolve the entire implicit grid first (as I think the original feature did), so there's also the option of either also including the implicit grid when some line-name-scoping keyword is assigned to the subgrid or disabling line name inheritance when the subgrid has an automatic span in order to include the implicit grid.

@rachelandrew

This comment has been minimized.

Copy link
Contributor

rachelandrew commented Jun 12, 2018

I'm not sure I understand what this is for, and don't remember the earlier spec which included this, do you have an example @fantasai?

@fantasai

This comment has been minimized.

Copy link
Contributor

fantasai commented Jun 12, 2018

An example would be, say I place the subgrid in its parent grid using grid-row: 3. This expands to grid-row-start: 3; grid-row-end: auto. Currently auto resolves to span 1, so the subgrid spans lines 3-4 in the parent grid and has only one row regardless of its grid-template-* properties.

We could alternately make it calculate auto from the contents of the subgrid, e.g. if the subgrid declared grid-template-rows: subgrid; grid-template-areas: "a" "b" "c" "d", we would resolve the subgrid’s grid-row-end as span 4. It would then span lines 3-7 in the parent grid and have four rows.

@rachelandrew

This comment has been minimized.

Copy link
Contributor

rachelandrew commented Jun 13, 2018

That does sound useful, in terms of component based design. Being able to infer numbers of tracks from the subgridded component would make the outer one more easily reusable, rather than having to specifiy in both places (the outer and the component) the number of tracks.

@fantasai

This comment has been minimized.

Copy link
Contributor

fantasai commented Jul 26, 2018

Proposed diff

diff --git a/css-grid-2/Overview.bs b/css-grid-2/Overview.bs
index 7a68df1..1a218cc 100644
--- a/css-grid-2/Overview.bs
+++ b/css-grid-2/Overview.bs
@@ -147,13 +147,36 @@ Characteristics of a Subgrid Item</h3>
 
   <ul style="list-style-type: lower-alpha">
     <li id="subgrid-tracks">
-      The number of explicit tracks in each subgridded dimension
-      is given by its <a>grid span</a> in that dimension,
-      rather than by 'grid-template-rows'/'grid-template-columns'.
-      The track sizes are governed by the parent grid.
-
+      Placing the <a>subgrid</a>
+      creates a correspondence between its subgridded tracks
+      and those that it spans in its parent grid.
       The grid lines thus shared between the subgrid and its parent
-      form the subgrid’s <a>explicit grid</a>.
+      form the subgrid’s <a>explicit grid</a>,
+      and its track sizes are governed by the parent grid.
+
+    <li id="subgrid-span">
+      The number of explicit tracks in the <a>subgrid</a>
+      in a subgridded dimension
+      always corresponds to the number of <a>grid tracks</a>
+      that it spans in its parent <a>grid</a>:
+
+      <ul>
+        <li>
+          If the <a>subgrid</a>’s <a>grid span</a> in the subgridded dimension is definite,
+          then the number of explicit tracks in each subgridded dimension
+          is taken from its used <a>grid span</a> in that dimension
+          (regardless of its 'grid-template-*' properties).
+
+        <li>
+          If it has an <a>indefinite grid span</a>
+          (i.e. either the '-start' or '-end' value
+          of its <a>grid-placement properties</a> in the subgridded axis
+          is ''grid-row-start/auto'')
+          then its used <a>grid span</a> is taken
+          from the number of explicit tracks specified for that axis
+          by its 'grid-template-*' properties,
+          floored at one.
+      </ul>
 
     <li id="subgrid-indexing">
       The <a>grid-placement properties</a> of the <a>subgrid</a>’s <a>grid items</a>
@css-meeting-bot

This comment has been minimized.

Copy link
Member

css-meeting-bot commented Aug 1, 2018

The Working Group just discussed support automatic grid span for subgrids?, and agreed to the following:

  • RESOLVED: Accept the diff in the issue
The full IRC log of that discussion <dael> Topic: support automatic grid span for subgrids?
<dael> github: https://github.com//issues/2565
<dael> fantasai: Suggestion was we used to have ability to have automatic grid span. In grid L1 that resolves to span is 1. When you have subgrid you can say it should resolve to number of tracks in subgrid. Mats suggested we do that. Do we want to?
<dael> TabAtkins: I think it's a nice feature. You expressed span in subgrid so seems reasonable
<florian> seems pretty reasonable. And there isn't really any other useful thing we should do. So yes
<dael> astearns: Seems okay to me
<dael> astearns: Anyone against?
<dael> astearns: Prop: Accept the diff in the issue
<dael> astearns: objections?
<dael> RESOLVED: Accept the diff in the issue
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.