W3C home > Mailing lists > Public > www-style@w3.org > May 2016

[CSSWG] Minutes San Francisco F2F 2016-05-09 Part I: Flexbox, Box Alignment, Grid [css-flexbox] [css-align] [css-grid]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 24 May 2016 19:35:05 -0400
Message-ID: <CADhPm3vB3YXJ0QoGwU1aTS=E7dTgOw+O2Q6sTapuN4hBkt673Q@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.


  - RESOLVED: Issue 1 the text for a11y is accepted.

Box Alignment

  - RESOLVED: Apply justify-content to columns in multicol elements
  - RESOLVED: Make “smart safe” alignment the default for handling
              overflow; but put at risk with a note saying to
              contact CSSWG if there is a problem regarding compat.


  - RESOLVED: Keep the spec the way it is in regards to issue #3
              (Abspos item placement in degenerate grids)
  - RESOLVED: Keep spec as is in regards to issue #24 (Drop empty
              tracks at ends or also in the middle?)
  - Rossen was tasked with reviewing issue #39, missing 'auto'
      changes for span>1
  - RESOLVED: subgrid proposal accepted in the at-risk section

===== FULL MINUTES BELOW =======

Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics

  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  L. David Baron, Mozilla
  Tantek Çelik, Mozilla
  Dave Cramer, Hachette Livre
  Elika Etemad, Invited Expert
  Daniel Glazman, Disruptive Innovations (only IRC)
  Daniel Holbert, Mozilla
  Jihye Hong, LG Electronics (only IRC)
  Koji Ishii, Google
  Brad Kemper, Invited Expert
  Ian Kilpatrick, Google
  Chris Lilley, W3C
  Peter Linss, HPI
  Myles Maxfield, Apple
  Edward O'Connor, Apple
  Simon Pieters, Opera
  Florian Rivoal, Vivliostyle Inc.
  Andrey Rybka, Bloomberg
  Hiroshi Sakakibara, Beyond Perspective Solutions
  Simon Sapin, Mozilla (only phone)
  Jen Simmons, Mozilla
  Geoffrey Sneddon, Invited Expert
  Alan Stearns, Adobe
  Shane Stephens, Google
  Lea Verou, Invited Expert (only IRC)
  Greg Whitworth, Microsoft

  Dael Jackson, Invited Expert
  Hyojin Song, LG Electronics

Scribe: gregwhitworth


  <fantasai> https://drafts.csswg.org/css-flexbox-1/issues-cr-20160301
  fantasai: As we mentioned, pretty much everything is fixed.
  fantasai: We asked for people to review issue 1 and 3.
  fantasai: We're asking for official resolution of those two, the
            rest are editorial.
  fantasai: You're happy to review them. After resolving we would
            like a CR.

  fantasai: Anyone need more time for issue 3?
  dbaron: The resolution for issue 3, is it independent of percent
          sizing with intrinsic widths?
  fantasai: Good question.
  astearns: That is one thing that does not have a time slot, that
            can be breakout session.
  dbaron: I just want to make sure that we're not tying this to
          something that isn't compatible with the web.
  fantasai: This one I believe is about the intrinsic minimum sizes.
  florian: Is it flex specific?
  dbaron: No.
  florian: If there is a side convo please try to include me.

  hober: If the dependency graph includes the percentage issue, then
         we should resolve that first.
  dbaron: I'm not saying it does, I'm just asking.
  fantasai: I'm not sure... yeah I think there is somewhat a
            dependency so we should resolve on those together.

  fantasai: So issue 1: a11y wording.
  Rossen: Do we have text for issue 1?
  fantasai: Yes.
  <fantasai> Note at the bottom of
  dauwhe: Are the a11y wg happy with it?
  fantasai: Cynthia is, she reported it.
  Rossen: I think the wording is exactly how we decided it, we
          should be fine. I'll follow up with Cynthia and close the
          loop with Richard and the rest of the WG.

  RESOLVED: Issue 1 the text for a11y is accepted.

Box Alignment

Application of justify-content to multicol columns

  fantasai: Tab and I went through the spec and updated the baseline
            alignment stuff to the best of our ability.
  fantasai: Anyone that's interested please take a look at it.
  fantasai: One open issue is whether the justify-content property
            applies to column boxes.
  fantasai: The other is the default value of overflow.

  fantasai: The justify-content property: in grid it justifies the
            tracks and in flex it justifies the flex lines.
  fantasai: [gives example of how justify-content works]
  fantasai: The goal of this spec is to allow alignment to work for
            all layout models.
  fantasai: Should justify-content apply to the columns or not?
  TabAtkins: No - justify-content can't because it applies to one
             line of things.
  florian: It sounds interesting, but do we have any wiggle room?
  fantasai: We can say that the normal value is doing what multicol
            already does,
  fantasai: for blocks it does nothing for them.
  <fantasai> https://drafts.csswg.org/css-align-3/#distribution-block
  florian: It sounds interesting to me.

  dbaron: It still doesn't make sense to me why it doesn't apply to
  TabAtkins: There is only one flow of stuff, so you can't justify
             its items - you can justify self.
  fantasai: If you think in terms of flex, block is like having one
            flex line.
  fantasai: There is no line in a block.
  dbaron: I was confusing justify-content and justify-items.

  jensimmons: If you specify the width of the col at 200, if we
              change this would you be able to do this and add the
              power to keep it at 200 and distribute from that fixed
  fantasai: Yes, this adds power to multi-col.
  florian: We cover step sizing a little bit later.
  dauwhe: This makes sense.
  TabAtkins: The mechanics are all there, this just allows you to
             control those gaps.

  RESOLVED: Add justify-content to multicol

  florian: Now we have column rules in the middle of column gaps
  TabAtkins: just like grid the things on the side are not gaps

default overflow-alignment value

  <fantasai> https://drafts.csswg.org/css-align-3/#overflow-values
  fantasai: The next issue is the initial handling of
  fantasai: We have safe and unsafe keywords, e.g. with 'unsafe'
            if you say center it will absolutely center it even
            if that causes it to overflow both sides, so the 'safe'
            keyword restricts overflow to the end side.
  fantasai: But a lot of times what you really want is true
            centering, except you want to keep it inside of the
            scrollable region.
  fantasai: The user wants to be able to see the content and they
            should be able to get to the content.
  fantasai: The initial behavior we're proposing is to do the unsafe
            behavior up until you would overflow the unscrollable
            container and then switch to the safe behavior.

  dbaron: That is very expensive on the layout engine.
  dbaron: I would prefer for people to have to ask for the slow path.
  fantasai: The people that need this won't know they'll need to
            change this. So it won't be useful as a default.
  fantasai: Only if you have overflow do you need to re-layout this.
  dbaron: I don't buy that there isn't overflow the majority of cases.
  dbaron: We can't change the default for block.
  fantasai: Block already does safe alignment.
  fantasai: This is all new stuff.
  fantasai: The only legacy is flex box.
  fantasai: Once this spec is implemented it will apply to
            everything and will only work if you set the alignment

  esprehn: I want to talk about the feature.
  esprehn: Someone showed a layout where the content is
           inaccessible, we need to solve it.
  dbaron: I prefer safe rather than true for that reason.
  esprehn: The example we had was a video in an iframe and the top
           was cut off and you could only scroll down.

  dbaron: A lot of layout issues deal with how a parent deals with
          its children.
  Rossen: Once you start nesting you're going to have very bad
  Rossen: This sounds like a weird position: sticky-ish.
  TabAtkins: This is still scrollable and only goes back if you
             overflow out of your scrollable bounds.
  dbaron: I agree with Rossen.
  Rossen: The benefit of sticky, you can keep it on the compositor
          and not re-layout.
  shans: This is about the negative bounds, not the scrollable region.
  Rossen: This is how I understood it, if you begin layout and you
          center align some items you start overflowing you have to
          redo layout to fix it.
  shans: On resize you re-layout anyways.

  fantasai: [draws a diagram]
  fantasai: [explains drawing]
  fantasai: This is all about the scrollable region, when the
            shifting occurs and it's outside the scrollable bounds
            this will change the box's alignment position to allow the
            content to be visible.
  fantasai: If you have a box that is a flexbox and it has a flex
            item that will have an item that goes into the
            unscrollable area then you flag it.
  fantasai: This only triggers when you have overflow in the
            scrollable direction.
  florian: Is this a third value?
  florian: Yes it's a third value.
  TabAtkins: It's kinda safe.

  zcorpan: You want this to happen in any direction right?
  fantasai: Yes.
  dholbert: This will affect any container with any alignment props
  fantasai: I think you could probably optimize this mostly away.

  dbaron: I think in theory that's fine, but it will take 10 years
          to find all the bugs.
  fantasai: We would like to put it in the spec and put it at risk,
            we don't expect it to be implemented soon.
  fantasai: Our content dependency is with flexbox.
  fantasai: The change in behavior may look a little bit worse on
            some pages, but for pages (like esprehn's example)
            where users can't scroll to see the content, this will
            fix those pages.

  bradk: Why not just make it so that you can scroll to the content?
  TabAtkins: That's the idea.
  hober: I don't want an infinite scrollbar because someone
         positioned something way out on the left for cargo cult
         a11y reasons.
  dbaron: What UI do you do when the scrollbar position is somewhere
          random in the middle?
  bradk: In a non-perfect world it seems like a good solution.
  dbaron: I looked into implementing it about 10 years ago and
          realized that it was too much of a compat risk.
  zcorpan: It would need to be opt in.
  TabAtkins: People use negative margins to hide stuff off the start
             edge of the document.

  fantasai: Any other comments?
  dholbert: Maybe an idea to work out later, but relpos/abspos would
            need to be taken into account.
  Rossen: The point is you should not start in a positive, safe will
          take you to the origin of that box, we don't want to move
  fantasai: We'll make you less unsafe until you're safe.
  florian: If you make this the default and at risk, please be clear
           in the spec what to do if you're not willing to implement

  TabAtkins: We still need a name.
  Rossen: un-safe-ish
  Rossen: scrollport

  fantasai: Does that sound like a reasonable plan?
  TabAtkins: Default to unsafe and put it at risk.

  dbaron: What happens to flex?
  fantasai: It will cause a behavior change where items are aligned
            such that they are not fully within the scrollable area.
  fantasai: This will probably fix more pages than it breaks.
  dbaron: I'm not sure I buy that.
  fantasai: But it only affects things that are aligning items into
            unscrollable regions.
  esprehn: Every time we change flex, we get yelled at - let's
           change and see how loud the yell is.
  hober: Also put a note that if you change and get yelled at let us

  RESOLVED: Put it into the spec, put at risk with a note saying to
            contact specs if you hear from authors regarding compat.

  <dholbert> fantasai/tab: we'd need to also be sure this
             "scrollsafe" alignment thing would interact nicely with
             layout containment
  <dholbert> In particular, layout containment probably needs to
             block aligned things from finding their nearest
             scrollable ancestor
  <dholbert> (for the purposes of this keyword)
  * fantasai likes the name scrollsafe :)

  fantasai: We'll publish next week.
  fantasai: Probably.

  dbaron: How much do we need to add to custom layout to make that
          work in Houdini?
  Rossen: Not much I think, you would need to add the origin and
          it's nearest ancestor.
  Rossen: You're always avoiding the origin for scrolling purposes.
  iank: I'm trying to catch up
  dbaron: I think if the nearest scroller is in another writing mode.
  Rossen: It still has an origin.
  dbaron: OK, you're right.
  Rossen: It's implementable.
  Rossen: Now that I understand it, it's not that scary.

  <iank> This seems fine for Houdini at a first glance, in your
         constraintspace at the moment you know at which point
         you'll trigger a scroll, and can adjust off that; but I'd
         have to have a little more of a think.


  <fantasai> https://drafts.csswg.org/css-grid-1/issues-wd-20150917

abspos items in degenerative grids (Issue 3)

  TabAtkins: We have a couple things that we need approval first.
  TabAtkins: Abspos items in degenerative grids.
  TabAtkins: The question here was what to do when you have a grid
             with no tracks whatsoever and how to place abspos items
             as a result; they care where the grid is.
  TabAtkins: There is no grid items, just some abspos and the grid
             has one grid line but no tracks, where should this line
  TabAtkins: The spec says it's against the start edge in both axis.
  astearns: Does anyone have any issues?
  astearns: Any objections?
  hober: What do the implementations do?
  TabAtkins: Don't know.

  RESOLVED: Keep the spec the way it is in regards to issue #3

Repeat function with auto-fit and auto-fill keywords (Issue 24)

  <fantasai> https://drafts.csswg.org/css-grid-1/issues-wd-20150917#issue-24
  TabAtkins: The repeat function with auto-fit and auto-fill keywords.
  TabAtkins: If you have 1000px to work with and auto-fit with 10
             tracks it will adjust accordingly, with auto-fill and
             you don't have enough columns it will drop them.
  TabAtkins: Which columns should you drop?
  TabAtkins: These columns in the middle are not being used, do you
             drop them?
  TabAtkins: We don't have a strong opinion on this, currently it's
             defined at the end.
  fantasai: We spec it currently based on what's implemented.

  jensimmons: Correct me if I'm wrong, I want empty columns in the
              middle and they don't want them to go away.
  fantasai: No this is for the auto-fill not auto-fit within the
            repeat() syntax.
  jensimmons: I just want to get what I've defined.
  fantasai: We'll do that,
  fantasai: But sometimes when you want to center columns and that
            contradicts with the amount of columns available, do you
            drop the tracks at the end and middle, or just the end.
            So we have an 'auto-fit' keyword to allow for that option.

  fantasai: Can anyone come up with a use case and behavior that
            people prefer?
  TabAtkins: Unless anyone has any strong opinion, we'll keep it the
             way the spec is.
  TabAtkins: Which is to drop all empty tracks.
  dholbert: The counterintuitive part is you can have something in
            col1 and col10 and then remove all the empty ones when
            you wanted them apart.

  RESOLVED: Keep spec as is in regards to issue #24

Missing 'auto' changes for span>1 (Issue 39)

  <fantasai> https://drafts.csswg.org/css-grid-1/issues-wd-20150917#issue-39
  TabAtkins: The counterintuitive part is why you would ask for auto
             generated rows and then explicitly set them into cols.
  fantasai: We need very competent people to take a look at this one.
  astearns: Anyone?
  TabAtkins: We think the spec is correct, but we would like for
             someone to take a look.
  Rossen was voluntold.

  ACTION Rossen to review issue 39 of the grid spec
  <trackbot> Created ACTION-768


  TabAtkins: The previous position on subgrid was complex so we
             removed it. That said, there are use cases that can't
             be done in current grid.
  TabAtkins: So we've put together a much simpler proposal that
             covers the majority of use cases.
  <fantasai> http://meyerweb.com/eric/thoughts/2016/01/15/subgrids-considered-essential/
  fantasai: Here's the feedback we got on subgrid:
  <fantasai> http://blogs.igalia.com/mrego/2016/02/12/subgrids-thinking-out-loud/
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2016Jan/0141.html
  <jensimmons> Rachel Andrew on subgrid, her response:
  fantasai: What are the things we need to address and how simple
            can we get it?
  fantasai: There were things we could get rid of, e.g. the subgrid
            auto sizing itself based on its contents.
  fantasai: So now you can't have any overflow tracks in the subgrid.
  fantasai: You can have overflowing content however (due to sizing),
            so they are still scrollable.
  fantasai: It won't affect the sizing of the parent grid however.

  <fantasai> Current proposal -
  TabAtkins: [shows example of the subgrid]
  TabAtkins: You declare an item to be a subgrid by giving it
             display: subgrid
  TabAtkins: This makes it a grid container but grid-template-
             columns/rows do nothing on it.
  TabAtkins: The children on the subgrid position themselves on the
             parent's grid.
  TabAtkins: The subgrid still lays out.
  TabAtkins: The margin/padding/border they get applied accordingly
             magically to apply the declared amount.

  florian: I assume this does the right thing no matter the writing
  TabAtkins: Yes.
  TabAtkins: It works the same way in nested subgrids.
  TabAtkins: You cannot get implicit tracks from the subgrid.
  florian: Can you use display: contents?
  TabAtkins: Sure, if you don't need a wrapper at all, then use
             display: contents.
  TabAtkins: You can't set grid gaps on a subgrid.
  florian: Anyone implementing grid not implementing
           display: contents?
  TabAtkins: We plan to, but will take awhile because we need to
             refactor a lot of code. FF has an implementation of it,
             webkit has  a prototype I think.
  florian: I'll write a blog post,
  florian: to convince everyone to implement display: contents.

  TabAtkins: That's the proposal.
  TabAtkins: Does the WG feel this is a good direction to with?
  TabAtkins: Overflow still applies.

  astearns: You were going to go over the single dimension case that
            this doesn't support.
  TabAtkins: Right.
  TabAtkins: Let's say you have a subgrid and your parent is 2x2
             square but you don't care about the rows of the
             parent's grid,
  TabAtkins: and you don't know how many rows itself will have.
  TabAtkins: This particular case is easy to hit with HEADER,
             CONTENT, FOOTER and then you want to fill in the
             content with your catalog items.
  TabAtkins: However, this makes it very complicated to handle.
  TabAtkins: The case is relatively small, and you can use a nested
             grid to allow for this so long as track sizes are not
  TabAtkins: If people demand a lot of this we may try to address it
             in the future.

  Rossen: By current subgrid proposal, this is not possible?
  TabAtkins: Yes, it can't work.
  Rossen: Good, I think this keeps it quite simple and keeps the
          mental model of the grid intact and symmetric.

  florian: Have you heard from the authors?
  fantasai: Yeah, I think this addresses the majority of the issues.
            Wanting to interweave the subgrid lines with the
            parents lines is very hard, and is not covered here.

  fantasai: There is an issue we marked, subgrid only takes affect
            if it is a grid item and the grid-template properties
            are set.
  fantasai: This gives us an extension point that allows us to use
            subgrid to ensure that the grid properties are set to
            none which they don't affect and later may affect it in
            the future it could break it.
  fantasai: The goal of adding the condition is so that the grid
            WILL break so that we can improve subgrid later.
  astearns: What do you do in this case then?
  fantasai: Maybe just treat it as block.
  dbaron: You're intentionally making it not work unless things are
          set for extension later then you should say so it in the
          spec and then also suggest implementations give console
  dholbert: We risk authors being ok with the "broken" behavior.
  florian: There's always a risk of that, but grid is so central to
           your layout that I think if it breaks then we won't have
           as much compat risk.
  astearns: If people do depend on it, we would need to come up with
            another way to solve it.

  astearns: We basically heard from all implementors saying 'subgrid.
            This is crazy.', have thoughts changed?
  TabAtkins: Igalia said their opinion on the list,
  dholbert: I spoke to Mats, and he feels this is still complex as
            you need to keep track of overflow for the items.
  fantasai: We would be ok with computing overflow to visible always
            if that is a concern.

  TabAtkins: Another issue is paint order.
  fantasai: I expect authors to be able to control z-index from
  dholbert: With that change, it may make it simpler.
  fantasai: You won't have to keep track of scrollers, etc
  dbaron: z-index also applies to all graphical stuff as well,
          masks, transforms, etc.
  fantasai: I think everything should just work as normal unless
            stated otherwise.
  dbaron: This is odd that it's basically an element that doesn't
          have a box.
  dbaron: This is similar to an element that doesn't have a box.
  TabAtkins: We're getting more explicit about the box.
  dbaron: But does the spec on filters or mask define whether this
          applies to elements or boxes, thus would impact a subgrid.
  esprehn: I don't think we should have another table row problem
  fantasai: I agree, it should get a box and we will on purpose
            exclude stuff from it to ease implementer complexity.
  dbaron: So it gets a box?
  fantasai: Yes.
  dbaron: This is well defined how the positioning/margin/border/
  TabAtkins: Yes.

  <Rossen> plinss, so you're saying that for layout purposes the
           subgrid is considered empty but has a size independent of
           its children sizes?

  jensimmons: I am an author and feel very strongly that subgrid
              should be included with grid, and I'm hoping that this
              is simple enough to ship it.
  jensimmons: From my experience they're going to be very confused
              that they can't align everything to the parent grid.
  jensimmons: I'm not sure this will cover all use cases, mainly
              because haven't had the time to play with it.
  jensimmons: In most cases they're going to be thinking about the
              explicit grid, not the implicit grid and I hope that
              this is simple enough that vendors will implement this.

  fantasai: I think we can resolve that overflow is at risk and say
            it computes to visible.
  astearns: So an at-risk within the at-risk section.
  astearns: Is there anything more people want to add?

  RESOLVED: subgrid proposal accepted in the at-risk section

[break=15 minutes]
Received on Tuesday, 24 May 2016 23:36:05 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:59 UTC