W3C home > Mailing lists > Public > www-style@w3.org > April 2018

[CSSWG] Minutes Berlin F2F Tue 2018-04-10 Part IV: CSS Grid and Box Alignment [css-grid-1][css-grid-2][css-align][css-sizing]

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 26 Apr 2018 23:21:46 -0700
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <3f8b2b80-bbba-7ec7-96a4-b5381e711c97@inkedblade.net>

   These are the official CSSWG minutes.

   Unless you're correcting the minutes,

  Please respond by starting a new thread

    with an appropriate subject line.


Grid L2


   - Author expectations and use cases were toward having the per-axis subgrid

     (Issue #2280) however several people needed more time to review the spec

     text so the group will revisit this issue later in the F2F.

   - RESOLVED: Add an ar unit to the grid 2 spec for align-content and

               justify-content. (Issue #1116)

Grid L1


   - The group believed that the Grid algorithm could still be adjusted to

       accomplish the use case in issue #2356; however the correct adjustments

       weren't immediately clear. TabAtkins and fantasai will look into a

       post-processing step that was suggested and Florian will reach out to

       Bert to see if he has any insights.


   - RESOLVED: Edit in Rossen proposal in issue #2177 "Spanners that cross tracks

               that have content-based mins AND flexible maxes only contribute

               content sizes to those tracks; otherwise they participate normally."


   - RESOLVED: Alignment and gaps in multicol behave exactly like grid and we

               will add a note explaining the concerns in the issue and how to

               solve them. (Issue #1420)

   - RESOLVED: Remove these terms (row-axis and column-axis) from the grid spec

               (Issue #1299)



   - RESOLVED: Zero out percentages on non-sizing use of calc. (Issue #2297)

   - RESOLVED: Fallback alignment for last-baseline is 'safe end' (Issue #1611)

   - RESOLVED: Publish a new WD of Alignment with the one edit from the baseline



Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule

Scribe: dael

Grid Layout Level 2


   Spec: https://www.w3.org/TR/css-grid-2/

Dual-axis vs. Per-axis Subgrids


   github: https://github.com/w3c/csswg-drafts/issues/2280

   fantasai: Issue with grid L2: it has some proposals and no feedback.

             I can't do anything to go forward.

   fantasai: Open issue says, here's 2 proposals for subgrid, which do we want?

   fantasai: I wanted to bring this up because there's strong requests from the

             community to do this, but the spec for subgrid is, well, there's

             2 specs for subgrid. I don't know what to do next.

   florian: Is there author feedback?

   rachelandrew: I have feedback. Authors really want subgrid. The use cases

                 I've seen are tied to single-dimension subgrid...

                 the proposal that was pulled from L1 wouldn't solve them.

   rachelandrew: People want the columns to be subgridded. They don't want to

                 define the rows. Having it locked to both dimensions would be

                 more frustrating then useful. Things I've seen assumed one


   fantasai: Proposal is then to resolve on per axis subgrids.

   Rossen: Didn't we decide in Tokyo?

   tantek: We added it as a possibility in Tokyo.

   Rossen: Sounds good to me. I thought we did that.

   Rossen: This is the 1.5 dimension model?

   fantasai: No, the way we set things up there's not many changes from one

             version to the other. Differences are in green.


   fantasai: Main change is for per axis you need to ensure that if you're

             interweaving the algorithm of the parent and child grids.

   fantasai: Algorithm is all defined. That's where spec is at. I think

             it's complete, mostly.

   astearns: Do we have impl?

   fantasai: I don't think anyone is working on subgrids.

   TabAtkins: Mats was interested and opposed the non-per axis. That's what

              Igalia partly implemented.

   rego: We didn't impl anything yet.

   <tantek> Mats is working on it, see the Firefox subgrid meta bug

            (with dependent implementation bugs)


   fantasai: Syntactic difference is the per-axis version has a subgrid keyword

             on grid-template-rows and grid-template-columns.

             Dual-axis was a keyword on display.

   astearns: Would anyone object to single axis subgrid?

   TabAtkins: No one has described how to do it yet.

   fantasai: It's in the spec. Here's the algorithm (section 2.4:

             https://www.w3.org/TR/2018/WD-css-grid-2-20180206/#subgrid-sizing )

   astearns: It's specified as a diff to a doc with both.

   fantasai: It inlines everything in. It just has two colors of ink.

   astearns: Anyone besides TabAtkins have concerns on single axis subgrid?

   rego: Seems more complex to impl but it would be good to know use cases.

         If there are clear use cases where we need this it's fine.

   rachelandrew: I brought use cases to the last F2F but I rarely see something

                 from an author that works for double axis. An e-commerce site

                 that has a template where they want it to work no matter if

                 there's 2 rows or 6 rows of stuff.

   rachelandrew: Let me see if I can find the examples.

   <rachelandrew> https://codepen.io/rachelandrew/project/editor/68cc7a5da9cfbb56c6e8366d7d92e6ba

   <rachelandrew> this is a better view, some examples


   astearns: Would people object to dual-axis subgrid?

   florian: I think rachelandrew would.

   astearns: I'm hearing some people for and against single axis subgrid but

             I haven't heard opinions on per-axis besides everyone thought

             it was too hard to get to for the first level of grid.

   <tantek> IIRC, all variants of subgrid were too much for grid level 1

   Rossen: I still agree it was a good move to hold it back. To your second

           point as to if dual- or per-axis is what we want, now that we can

           reason about it and think holistically the dual-axis is an easy

           shortcut to cover some use cases but during Tokyo I heard enough

           compelling reasons to have the per-axis variant. I will admit I

           haven't reviewed the spec. But I prefer the per-axis one. I don't

           think there will be all that much work per-axis, at least in our impl.

   astearns: Perhaps we could leave it at people should review the spec and

             look at the use cases and then come back soon?

   rachelandrew: I could probably get more use cases now that people are

                 using grid.

   astearns: Is there an issue for choose which approach?

   fantasai: Yep. https://github.com/w3c/csswg-drafts/issues/2280

   astearns: I suggest we continue discussing in that issue.

   astearns: Anything else?

   fantasai: When do we want to return?

   Rossen: End of F2F.

   astearns: We can try and bring this up end of Thursday. Then perhaps we

             can make a decision then.

   astearns: Please take breaks or lunch time if as you read you have questions.

   dbaron: Would it help to get Mats on a call?

   fantasai: It would be good to have Mats look and reply on github.

   fantasai: I haven't heard from him.

   dbaron: If you want me to poke him can you send me what you want me to do?

   fantasai: Review the spec and comment.

   fantasai: And if there's nothing wrong with it say it's good.

   florian: Also express a preference? Or he always has.

"equal gutters" with justify-content on grid items


   github: https://github.com/w3c/csswg-drafts/issues/1116

   astearns: Other part of grid L2 as aspect ratio controls.

   fantasai: We resolved to add this to the first level of the WD.

             Just a request for people to let me know what they think.

   TabAtkins: Other than that I want a unit on these I think it looks great.

   fantasai: Unit proposed is ar unit for aspect ratio.

   astearns: Two options are a bare number or an ar unit.

   fantasai: I'm open to name suggestions.

   TabAtkins: I regret not putting a unit on flex.

   astearns: Could ar be used in other places?

   TabAtkins: A generic aspect ratio.

   florian: It's mathematically unitless.

   fantasai: It's a multiplier.

   TabAtkins: Whatever the other thing results in, multiply it.

   florian: Does the unit thing play into if we want to ever use calc on it.

   TabAtkins: Numbers tend to cause parsing issues. It causes issues on the

              flex things. I'd prefer not to continue that pattern. This

              has a specific meaning so it should be tagged in a specific way.

              Angles are just numbers.

   fantasai: They're not.

   TabAtkins: They're radians which are just an ID.

   <ChrisL> how are radians an ID?

   <TabAtkins> ChrisL, Radian is (length of arc) / (length of radius),

               which is unitless

   <ChrisL> an aspect ratio is (by definition) a ratio. It is a length

            divided by a length, and thus also unitless.

   <TabAtkins> Yes, that's my point. We already associate units with "unitless"

               things, to give it an easily-interpreted meaning and help with

               parsing. This is the same deal.

   <ChrisL> remember though that whenever we add units, it stops those things

            being used in custom properties, because we can't divide by unit-ed


   fantasai: Somewhat related issue has been aspect ratio units for grid, #1173

   fantasai: There was a request for having an aspect ratio in the grid spec.

             A lot of the cases we want to have are covered by an aspect-ratio

             property that can apply to grid items (driving auto-sizing in the

             other dimension).

   fantasai: Question was if there isn't an element can you assign the aspect

             ratio property; then we need another approach.

   fantasai: You might decide you have a bunch of fr columns and you want the

             rows to be 1:1. Once we add aspect-ratio, if there's at least one

             element you can key off of you can auto-size the rest. If you

             don't put anything the auto row collapses to 0.

   astearns: The only things in having that row were spanning it would be weird.

   fantasai: One proposal was to have an ar unit in grid template columns that

             would represent the aspect ratio multiplied by track size in the

             opposite axis. Problem was, what if there are multiple tracks of

             different sizes?

   fantasai: Proposal I had is 1ar is always resolved value of 1fr in the

             opposite axis.

   florian: You can't map to a column 'cause you don't know which to match.

   fantasai: It's not clear what we need to do for this issue.

   astearns: And a side discussion.

   fantasai: A unit may be useful in this case.

   astearns: So do you want to resolve to add a ar unit?

   TabAtkins: If we accept the proposed syntax I feel we should have a unit.

   ChrisL: Remember when we add units you can't use them in custom properties.

           You can't divide by an ar.

   TabAtkins: You can, it works now.

   <TabAtkins> (I've been slow to add the functionality to calc(), but we

               resolved to do so a while back, and Typed OM allows it.)

   <ChrisL> fair enough; would be good to see that agreement in the spec,

            and implemented

   astearns: Objections to adding an ar unit to the grid 2 spec for align content

             and justify content?

   RESOLVED: Add an ar unit to the grid 2 spec for align-content and justify-content.

   astearns: Anything else on grid 2?

   fantasai: It's just those 2 things. Once we have agreement on subgrid and

             someone has read it [and there's no issues] I'd be happy to request


   astearns: I'd like to get an impl started.

   astearns: I'd also like to see progress on grid area styling proposal.

   fantasai: That's grid 3. Grid 2 is just subgrid and this one other small

             thing. Styling of grid areas is more complex spec-wise for sure

             (uncertain about impl-wise). In terms of figuring out the spec

             that'll be harder.

Grid Layout Level 1


Can the sizing algo be made to deal with this


   github: https://github.com/w3c/csswg-drafts/issues/2356

   <florian> https://florian.rivoal.net/csswg/grid/grid-span-auto-001-ref.html

   florian: I was laying out a page of manga using grid so each cell is a grid.

            It should layout like ^

   florian: Defining a bunch of columns and rows and everything can fit,

            but it's manual.

   <florian> https://florian.rivoal.net/csswg/grid/grid-span-auto-001.html

   florian: Here's what you get ^

   florian: It has unneeded empty spaces.

   florian: I think this boils down to current sizing algorithm not considering

            enough things. It's described as a possibly improvable heuristic.

            If we agree this is a good thing to solve... it sounds desirable...

   florian: I think this is linear programming solvable by constraints. I'm not

            good enough at math to put the steps but I think this is solvable.

   <TabAtkins> Very simple example:


   TabAtkins: Simple example ^

   TabAtkins: [explains example]

   TabAtkins: We take the largest of the planned increases so we're not loosely

              wrapping each item. Ideal would be the latter image. It's one

              possible version.

   florian: I believe an algorithm exists that could solve it... or are we too

            locked into compat?

   fantasai: I think we should be able to make the adjustments here. I don't

             think anyone depends on this slight amount of slack. As time goes

             on we might get more constrained but I think we're not at that

             state. If we could solve it it would be great, but I don't know

             how to do it.

   florian: I might be able to research the theoretical algorithm but I'm not

            right person to say if it's implementable.

   fremy: I've been working on some layouts and you can do a post-process to

          reduce the sizing.

   TabAtkins: This example (bottom of link) it shows one possible switch.

              But there's several ways to solve it like making the columns

              50,250,0, which is a big change from the current way they lay out.

   florian: Some examples have a range of solutions, mine has one solution.

   florian: I think it's worth looking into if there's a general option that

            we're not blocked in. I'd appreciate a mathematically-inclined

            person to help. Maybe do the current algorithm and squish would work.

   fremy: Browsers have already implemented grid and we don't want to change

          the whole algorithm, so a post-processing step is easier.

   TabAtkins: And your site may be doing it for you. In the manga example your

              images have known widths, it's just easier if CSS does it for you.

   fantasai: TabAtkins and I can take an action to look at adding a

             post-processing step to see if that works.

   fantasai: Maybe send a email to bert with a link to this issue to see if

             he has some insight?

   ChrisL: We were talking to people from Monash University with expertise.

   fantasai: We also had C├ęsar who was working on an impl of Bert's grid spec.

   florian: I think the trickier part is that this is more complicated.

           If we have auto sizing it's simpler. If you have one min and one

           max you span. It's much harder to explain to people that don't

           know CSS but I'll try.

   astearns: Anything more?

   florian: Nope.

Grid track sizing items spanning a flexible track


   github: https://github.com/w3c/csswg-drafts/issues/2177

   rego: Quite related, you have an item that spans 2 columns.

         One of them is outside its flexible track, and we weren't sure

         what would be the best result. We're not sure what's the core

         approach. Rossen was trying to clarify in the last comment.

   astearns: There's a specific tweak to the algorithm you propose?

   rego: Original algorithm was aligned that you don't expand a track

         with a flexible track sizing. Maybe we can open the use cases.

   fantasai: We should try Rossen suggestion in the issue and see if it

             works. I haven't fully thought it through but that's what

             I'd want to try.

   Rossen: When we looked we played with magazine layouts. One recurring

           thing was when you have a splash page when an item that spans

           N columns and want to influence rest of layout. Those columns

           need to be flexible when you're on a browser. That was the

           original motivation.

   Rossen: Since then in the issue... we can go either way. I don't think

           there's enough concept to support one or the other. What I

           proposed should work.

   fantasai: Makes sense to me.

   astearns: Do we need a resolution to edit in Rossen proposal?

   fantasai: Resolution to add Rossen proposal and we'll revisit if

             there's a problem.

   RESOLVED: Edit in Rossen proposal in https://github.com/w3c/csswg-drafts/issues/2177

'justify-content' on multicol


   github: https://github.com/w3c/csswg-drafts/issues/1420

   astearns: We've discussed in the past.

   TabAtkins: As florian says from third to last comment, right place to start

              reading is the one above.

   <fantasai> https://github.com/w3c/csswg-drafts/issues/1420#issuecomment-303958104

   TabAtkins: florian objections to current spec are 3.

   TabAtkins: 1) in current spec you can't robustly fix the ratio of the

                 default column gaps.

   florian: Fixed that.

   TabAtkins: 2) default behavior of space between ends up with not the correct

                 ratio because space-between space is added. Trivial fix, if

                 you set column-gap to 0 it works. Solving it precisely would

                 involve special cases multicol if the column gap and so we'd

                 be against that.

   florian: You should not set the column gap to 0, though, because depending

            on the space you end up with it might be 0 and it's unreadable.

   TabAtkins: Then you set padding.

   florian: I'm not completely opposed to your proposal. Setting gap to 0 it

            can be mushed so you get padding on the edges. Typically multicol

            has text, though, and if you don't have room you fallback to block

            which is good. But if you're forcing padding for space you keep the

            padding when you collapse.

   TabAtkins: I disagree. So you want space around. You leave column gap at

              1em and padding to 1/2em on either side. I don't see why when

              you go to 1 column that you don't want the 1/2em padding.

              You put it there for a reason and I don't see why it goes away.

              It goes away in multicol because it has no gaps, but you're

              explicitly putting the gaps.

   TabAtkins: If a single column you want the text flush you'd want that in

             many columns.

   fantasai: Like if you have 1 column and you split to 2 you don't want

             padding on common container but you want a gap between the 2.

   fantasai: Regardless, I'm opposed to different behavior between multicol

            and grid.

   rachelandrew: Authors wouldn't use space-around if they're not okay with

                 gaps on the outside. If you didn't want that you'd use


   rachelandrew: I agree we want to be able to maintain the 1em so people

                 don't set column-gap to 0.

   florian: This issue traces back to before we merged the models. Now we have.

            I'm okay with what you proposed, we just never discussed it. It was

            just added to the spec. If everyone agrees.

   fantasai: Proposed that alignment & gaps in multicol behave exactly like grid.

   astearns: Close no remaining changes.

   TabAtkins: I could go with a note for how it works.

   fantasai: I think people know how to do padding. They figured it would for

             grid so you'd have to have a note in both.

   florian: There's many ways to space in grid that don't require figuring

            this out. I think a note wouldn't hurt. Doesn't have to be multicol

            specific, but I think it would help more there.

   astearns: I'd prefer the note because it shows we considered this, discussed,

             and have a solution. As people read they can agree or disagree.

             Without a note it's fairly opaque.

   astearns: Proposal: alignment and gaps in multi col behave exactly like grid

             and we will add a not explaining the issues in the issue and how

             to solve them

   astearns: Obj?

   RESOLVED: Alignment and gaps in multicol behave exactly like grid and we will

             add a note explaining the issues in the issue and how to solve them.

Axis Names


   github: https://github.com/w3c/csswg-drafts/issues/1299

   fantasai: SelenIT commented that rachelandrew's articles had the opposite

             meaning of row-axis and column-axis as what's in the grid spec.

             We only use them in a handful of places, and since most people

             learn grid from rachelandrew it's probably better to match her


   rachelandrew: I've commented before that people struggle to learn this.

                 People are used to a main and a cross which you don't have

                 in grid. People are explaining it all sorts of ways. It's

                 gone around and around.

   fantasai: 3 options:

                1 is don't change the spec.

                2 flip to match rachelandrew.

                3 remove terminology.

   <fantasai> Reasoning for the spec's usage is in


   <fantasai> terminology is in https://drafts.csswg.org/css-grid-1/#grid-concepts

   TabAtkins: I'm in favor or removing the terminology. Both schemes make sense.

              Flipping to the other doesn't have a compelling reason because

              other people will not understand. We should use block and inline.

   rachelandrew: I prefer block and inline.

   Rossen: rachelandrew can you fix and teach people the way we have intended

           this to be spec?

   rachelandrew: I'd prefer us to use block and inline.

   Rossen: I think it's fine but also spec what the row and columns are correctly.

   fantasai: Note that the axis names appear 3-5 times total.

   Rossen: I'm slightly opposed because the column-axis and row-axis are

           something which applies to internal layout of grid. Easy to

           rationalize which is which. Even thought inline and block axis

           apply externally the two aren't necessarily the same.

   fantasai: Actually they are exactly the same.

   fantasai: Question for you--don't look at the spec

   fantasai: Which is the row axis? Horizontal or vertical?

   Rossen: Vertical.

   fantasai: It's horizontal in the spec.

   fantasai: If we want to match your head we need to flip.

   Rossen: Row is if you add more rows so it's how it advance.

   plinss: Thing you put in a row progress horizontally.

   astearns: I hear these terms aren't used much in the spec. What damage does

             removal cause?

   TabAtkins: Every time we use the terms we also call it block or inline

              in parentheses.

   fantasai: There's no occurrence of these terms where both aren't used.

   astearns: Useless terms. Causes confusion. We should remove.

   RESOLVED: Remove these terms from the grid spec.

   <rego> the last comment in previous issue:


   <rego> was suggesting about if it'd make sense to change the properties

         "grid-column-start" to "grid-inline-start" and "grid-row-start" to

         "grid-block-start" and so on

   <fantasai> rego: no

   <rego> fantasai: :)

Alignment: Closing out last few open issues and republishing


   Issues list: https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-align-3

calc() with percentages in margins/padding


   github: https://github.com/w3c/csswg-drafts/issues/2297#issuecomment-376263348

   <fantasai> Comment summarizing issue:


   fantasai: It was to discuss zeroing out a percentage vs the entire expression.

             Example calc (10% + 10px).

   fantasai: Zeroing the entire expression is what's impl. Zeroing the percent

             is more meaningful. This is for purpose of calculating the intrinsic

             size of the element.

   dbaron: It's also continuous in terms of what happens when you have a calc

           that approaches 0 and you remove the calc.

   TabAtkins: Are we okay with some properties having a different indefinite

              percent with calcs?

   fantasai: I prefer 0 out the percent.

   florian: Justification to zero everything is just that it's what we have impl.

   fantasai: I didn't hear anything.

   Rossen: I agree with fantasai. Zeroing the percent makes more sense.

           Having a box model with some percent and non-percent values results

           in the same logic, where we would zero out the % values and add the

           rest of the defined sizes

   fantasai: For sizes like width/height, we ignore entire calc. We closed that

             in #1132. Sorry, we throw out the calc and treat as auto.

             Fallback to initial value.

   fantasai: That makes sense for sizing in a way it doesn't here is if you

             fallback to the original that has some kind of meaning. In this

             ase there's no meaningful value for margins and padding.

   astearns: In only zeroing out percents when not sizing is a discrepency.

   fantasai: Correct.

   asteanrs: Why do we throw out the expression for sizing properties?

   florian: We can do calc of 10%+10px is the same as 10px but we can't do

           auto+10px because that's not defined.

   astearns: Arguments against only zeroing out percent on non-sizing props?

   astearns: Objections?

   RESOLVED: Zero out percentages on non-sizing use of calc.

Should last-baseline's fallback alignment be safe or unsafe?


   github: https://github.com/w3c/csswg-drafts/issues/1611

   fantasai: Say you have a row flexbox and inside you have items with

             last-baseline alignment, but the flexbox is larger than the items

             we have to decide how to align them. Just like for first-baseline

             you align and then start align the set at the top, we align the

             last-baseline set at the bottom.

   fantasai: But what if it's too small to contain all the items? In that case,

             what happens? Do we continue to align at the bottom and the large

             items overflow the top or do we take the things that are too big

             and start-align them so they no longer participate in baseline


   astearns: From I can access and read safe is better, but from design unsafe

             is better.

   myles: Implementation difference.

   fantasai: We were generally unsure before.

   myles: Have we asked authors?

   florian: Can we default to safe? Defaulting to safe sounds...safer? And let

            authors opt-in if needed.

   TabAtkins: We don't let you set it. It seemed like more switches then you

              needed access to.

   fantasai: We could make it possible to combine the keywords.

   florian: I'd prefer default safe and have the keyword.

   astearns: We last left this that someone would write a blog post.

   fantasai: That was not done.

   astearns: I don't think we should assume we will add a switch. We should

             decide based on probability that this is a weird edge case so

             it's not worth our time to have a switch.

   TabAtkins: That's why we haven't done it.

   Rossen: Can we resolve on choosing safe? If someone squeaks really hard

           we'll solve it.

   astearns: Objections to using the safe behavior in this case of last-baseline


   fantasai: All using the alignment properties.

   astearns: In this case with content that will not fit in it's container and

             we fail to be able to last-baseline align things, things will

             overflow in a safe direction.

   RESOLVED: In this case with content that will not fit in its container and

             we fail to be able to last-baseline align things things will

             overflow in a safe direction.



   fantasai: New WD once dbaron says they're okay?

   astearns: Objections to new WD once we get through some of the remaining

             open issues?

   ChrisL: I'd rather be told when it's approved, not we approve some time

           in the future.

   Rossen: Let's publish now and again later.

   astearns: We just resolved 2 things.

   fantasai: One was no changes.

   Rossen: The one for calc was in sizing?

   astearns: Objections to publishing a new WD of Alignment with the one edit

             from the baseline-alignment resolution.

   RESOLVED: Publish a new WD of Alignment with the one edit from the

             baseline-alignment resolution.

   <br type="short">
Received on Friday, 27 April 2018 06:22:19 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 April 2018 06:22:20 UTC