W3C home > Mailing lists > Public > www-style@w3.org > June 2014

[CSSWG] Minutes Seoul F2F 2014-05-21 Part V: Grid/Subgrid, position: sticky, Acknowledgements

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 13 Jun 2014 10:22:55 -0400
Message-ID: <CADhPm3urchhRFMuRCH2ma0RECj0qS4XMd-tESyDyJpNyFTQUUQ@mail.gmail.com>
To: www-style@w3.org

  - RESOLVED: Move subgrid to at risk for level 1 and add a
      requirement for display-box: contents to be used with
      grid and include examples.

position: sticky

  - dbaron brought to the group some behavior inconsistencies
      between implementations when using position: sticky and the
      margin box and padding box are the same size.
  - The group looked through dbaron's examples (available here:
      and agreed it was broken.
  - Rossen will address the inconsistency in his continuing work on
      the spec.


  - Everyone thanks the TTA for being wonderful hosts!


  Full Agenda: http://wiki.csswg.org/planning/seoul-2014#agenda
  ScribeNick: dael


  Rossen: A quick review
  Rossen: Grid is awesome.
  <astearns> [whiteboard drawing]

  <fantasai> http://fantasai.inkedblade.net/style/discuss/subgrid-markup/
  <fantasai> My position: If you can convince me that 80% of Web use
             cases for grid layout can be handled without
             compromising accessibility, I will retract my objection
             to removing subgrid. Otherwise not.

  Rossen: The thing we can do with grid is you have a division of
          space and you have lines where you can size and have
          adaptive layout.
  Rossen: The one thing it doesn't give you is grouping.
  Rossen: If you have items on the grid you want to group and
          attach behavior, you can't.
  Rossen: For example, a simple form with a button and an input
          field for text. If you want to treat it as a group where
          text spans two cells and the button is one, but I want
          hover where the whole group is hovered, in order to deal
           with that we go into subgrid territory.
  Rossen: It behaves like a semi-transparent item in the level of
          grid and the purpose is grouping.
  Rossen: All the items in a subgrid are in the top-level grid,
          but have this invisible element that lets us attach

  Rossen: For the past 1 or 2 years, one exercise we went though
          was to take the initial grid spec with-in an app based
          grid with cells and try and merge that with typography
          based grid
  Rossen: We did that. Everyone in the grid task force contributed
          a lot.

  Rossen: The spec is in fairly good shape to get to LC.
  fantasai: I think it needs another round or two for the algorithm.
  fantasai: But design-wise, it's good.
  Rossen: As concepts, it's good.
  Rossen: The one wrinkle is that implementing subgrid will be
          fairly complex.
  Rossen: The reason why is (and subgrids nest) so the entire
          layout of subgrids boils down to the dependency of
          subgrids, which can bring any element anywhere in a
          subtree with a different amount of spanning on some
          level as well as overflow.
  Rossen: The current sampling makes me think Blink and Firefox
          are close to implementing grid.
  fantasai: Mozilla is nowhere near.
  jet: It's been going around for a bit. Mats is working on it.

  Rossen: But we want to push grid out as soon as we can. We want
          to revise our un-prefixed version of grid for everything
          except subgrid.
  Rossen: I think subgrid as a functionality is needed. I propose
          we move subgirid to level 2, allow level 1 to ship so
          all implementors that are close to done can roll out at
          the same time.
  Rossen: And then work on subgrid as soon as we can.
  Rossen: In the meantime, if we find out implementation of
          subgrid is quicker, we might pull it back into level 1
          before REC, but my initial prototyping suggests it will
          have a significant implementation delay.

  fantasai: My position is if we can cover 80% of common use cases
            with existing spec without using subgrid or compromising
            accessibility, I'm okay with this. But I'm not convinced.
            I think we can cover 30%. There's common cases that will
            be worse with using just grid.
  fantasai: Those are cases for which grid is designed and I haven't
            heard markup for an example that uses grid and isn't bad

  Rossen: I can tell you almost, nearly all, HTML based windows
          store apps use grid.
  Rossen: They're accessible and are requesting subgrid as a
          future, but almost all that content that will be on the
            web will be fine without subgrid.
  fantasai: App layouts seem to be simpler.
  Rossen: I don't agree.

  fantasai: I want a concrete example of something common with
            proper markup and I haven't seen that.
  dbaron: fantasai's concern is about people having to remove things
          from markup.
  TabAtkins: So anything doing a vaguely grid layout,
             accessibility-wise it's fine. Right now they're deeply
             nested, but for accessibility they're fine. There's a
             decent number of use cases for in-page components that
             are better solved by subgrid, but I want to solve page
             layout right now.
  * liam wants to see page layout solved too :-)
  fantasai: So write an example an post to the mailing list.
  TabAtkins: Look at any website.
  fantasai: I did and said you'd have to remove these things
            (section markup and ids) and add empty elements.

  fantasai: I went to a grid layout framework's homepage and analyzed
            their examples. I posted the link about that.
  fantasai: I took that, figured out how to do the markup with grid
            and subgrid and figured out that it's very different.
  TabAtkins: This first example is fine if you don't remove sections.
  fantasai: If you want the pictures to line up, you need to remove
            the markup that collects around "here" [pointing] unless
            you guarantee that the headers are the same number of
  fantasai: So something where you have something that looks like a
            grid, but doesn't rely on things being the same size. If
            it's same size, why not use flex?
  TabAtkins: You don't need subgrid until you're trying to style
             with padding and border. You're taking each top level
             piece and display-box works.
  fantasai: Then we can put display-box: contents in the grid spec.
  TabAtkins: That's silly.
  fantasai: I agree.

  fantasai: But I don't want to give a feature that authors
            will be excited to use, but to use it they have to strip
            out markup to use it. They'll continue to do that years
            after we ship subgrid, because of habit and because of
            backwards-compat with old versions of IE.
  fantasai: Even if subgrid ships in 2 years, it'll suck for 10 years
            because people will keep stripping it out.
  TabAtkins: Given the pattern, worst case you need a div around
             the pattern so that you can say auto-flow.
  hober: I think the point stands is you have to take out the markup
         for a complicated model.
  fantasai: auto-flow only works in one direction.
  fantasai: I'm not convinced this isn't harmful. I'm pretty sure
            it's harmful. Unless you have examples that show me I'm
            wrong, but you have not done that.

  * dauwhe see footer at http://alistapart.com

  TabAtkins: Most sites have a simple grid that's hard to do now and
             can be addressed just fine with grid.
  fantasai: And how many of the use cases is that?
  TabAtkins: The plan is people will use grid forever.
  fantasai: I don't want them in the habit to do harmful things to
            use grid and keep using those habits.
  TabAtkins: This is a short period of time.
  fantasai: So we wait until subgrid is implemented, if it's only a
            short period of time.
  fantasai: It's not just about old tutorials sticking around, it's
            about habits and compat. If you do it the old way it'll
            work in old versions of IE.

  hober: Probably you shouldn't add very attractive, desirable
         features to use practically in the real world but that
         require reduced markup quality.
  TabAtkins: I say not in many or most cases and the markup quality
             today is so terrible we're improving it anyway.
  TabAtkins: We'd rather a flatter structure.

  plinss: Does display-box: content solve most of the problems?
  TabAtkins: Some.
  plinss: Enough to alleviate your concerns?
  fantasai: Yes, my concerns are about markup being actively ruined.
  plinss: So is display-box being ready before subgrid a way to make
          this work?
  TabAtkins: So I can't promise, but it's likely going to be ready
             before subgrid.
  TabAtkins: We have something else calling for this feature.

  plinss: Does this handle your concerns?
  TabAtkins: I'm otherwise going to object to objections here.
  fantasai: If that's implemented and shipped before or with grid
            and we update the spec to have a nice tutorial to use
            these together, than I think that will be acceptable.
  plinss: Okay.
  TabAtkins: Sounds fine to me.
  Rossen: Jet, you're okay with that?

  fantasai: I'm waiting for display-box: content; before I remove my
  TabAtkins: The agreement was it shipping.
  fantasai: Until that's happening, I'm not removing my objection.
  dbaron: Would you be okay with something in the spec that says
          implementors implementing grid are also expected to
          implement display-box?
  hober: That's a message to say that things should be in the order.
         All the examples should have to use it in order to have the
         affect you want.
  TabAtkins: The examples today don't need it.
  plinss: So phrase it in a way to say display-box: content is an
          implementation requirement of grid.
  dbaron: They're correct that the examples should have it as well.

  clilley: Rossen does the app store has an accessibility review?
           Any problems with grid?
  rossen: Grid is a default that's used for authoring apps. In
          order to submit it has to meet accessibility. I'm not
          sure how it's assessed.
  rossen: With the current grid, which we have without subgrid,
          all these applications exist just fine.
  clilley: Some data would be useful.
  rossen: They're all new content. None are using the same
          pattern as a website, though I wouldn't expect much
  fantasai: If you're using it for labels and forms elements,
            the markup required by grid is a jumble.
  dbaron: The other point is that on the web we want the platform
          made so people write accessible content as the default.
          If you have a review state that means you have a different

  dbaron: I think we almost had a compromise.
  plinss: Proposed resolution is to move subgrid to level two and
          add a requirement for display-box to be used with grid.
  fantasai: I'd prefer a label for at risk.
  astearns: How far along is the display-box implementation?
  plinss: People said it's easier.
  astearns: Is it implemented yet?
  jet: I think it's almost landed.
  plinss: So it's coming real soon.
  fantasai: We should finish the Display draft, then. :)

  RESOLVED: Move subgrid to at risk for level 1 and add a
            requirement for display-box to be used with grid and
            include examples.

  fantasai: I'll make the edits
  Rossen: I'll review them.
  TabAtkins: And I'll go over them.

position: sticky

  dbaron: This is a follow-up to an issue that hasn't been edited
          into spec.
  fantasai: (Can we turn the spec into a list of links into the
            www-style archives?)

  dbaron: There was a thread started that says it doesn't explain
          the two boxes you need to use sticky
  dbaron: My understanding of sticky is that you have something like
          a header and you want to to scroll up with the content and
          then stop for a period of time with the content where it's
          the header and then scroll off when it's done being used.
  dbaron: So it's fundamentally like position: relative except the
          offset is changing dynamically.
  dbaron: You can use any of the top/right/bottom/left properties.
  dbaron: You have the boxes you care about. The scrollable box, the
          element's containing block, and than you have the sticky
          element itself.
  * liam wonders if this is e.g. for a table header that remains
         visible when you scroll a long table
  <fantasai> yes

  dbaron: For the sticky element we only care about the margin box
          and for the scrollable area we care about the padding box.
  dbaron: What happens if you set none of the offsets, nothing
          interesting happens.
  dbaron: If you set the offset to top: 20px, it's relative to the
          outside box so it means you care about the edge that's
          20px from the top of the scrollable area. So you prevent
          this margin box from going above...
  dbaron: So top: 20px says the top px of the sticky box won't go
          above the container as long as the scrolling box doesn't
          go above.

  hober: So it implicitly controls two edges?
  dbaron: It's two constraints. And the 2nd overrides the first.
  dbaron: The point of the second is to have it scroll off. Even
          though this isn't in the spec, we agree that this is how
          it works.

  dbaron: Where implementations don't agree is if the boxes are the
          same size.
  Rossen: Or some of the internal boxes are bigger.
  dbaron: I want to discuss what if they're the same. The issue is
          that the second constraint constrains relative to
          something that's scrolling within the scrollable area.
  hober: If they're the same you never hit the bottom.
  dbaron: The problem is the scrollable box is sorta like two boxes:
          The actual box and the scrollable area.
  dbaron: There are three options for the second constraint where
          the sticky element's containing block is its scrollable
  dbaron: I prefer 1) Throw out the second constraint.
  dbaron: 2) make the scrollable constraint the area inside the
            scrollable container.
  dbaron: And that means most of the time the second constraint
          doesn't happen either unless you're in an overflow case.
  dbaron: Gecko does #1
  dbaron: 3rd is Webkit's approach which is use the box that isn't
          being scrolled. You have to write weird test cases to
          trigger this.
  dbaron: Webkit will force the sticky element into the box, even if
          it's below it.
  dbaron: If the sticky element is scrolled up above, it'll force it
          down into the box. Which seems crazy.
  dbaron: I think in this case where the two boxes are the same, the
          purpose of the containing block constraint has disappeared.
  dbaron: I've got a testcase link in which Gecko and Webkit disagree
  <dbaron> https://bug915302.bugzilla.mozilla.org/attachment.cgi?id=8386943
  dbaron: So the case...
  dbaron: In Webkit, I was right the first time. If the box is way
          below, Webkit will constrain it to the bottom and than
          will scroll it up to the 20px margins until, I'm not
          sure when.

  Rossen: Can I add one more view?
  Rossen: This is what I was going to add into the spec and it's
          almost ready.
  Rossen: Last I talked about this with Cory is the following:
  Rossen: We have an element to which you'll be using position: sticky.
  Rossen: You default to 0px, no matter what.
  dbaron: They default to auto, not 0.

  hober: For what it's worth, the Webkit test case is paying
         attention to how I thought.
  dbaron: [corrects hober's use of the example]
  hober: Oh. That's evil.
  dbaron: The other thing to notice is they have a bottom of 180px
          that pushes them outside the containing block.

  Rossen: So the terminology we used is the sticky position, which
          is the position at which the box will get stuck. Also the
          release position, which is the condition at which the box
          gets put away.
  hober: That you're using enormous values is what makes it apparent.
  Rossen: So sticky position is by the scroller, release position
          is triggered by containing block and an open question is
          if the containing block is the same as the scroller, in
          which case we need to define reasonable behavior.
  dbaron: I was suggesting if they're the same, you throw away
          and release.
  Rossen: So it's stuck forever. That could be reasonable. If you
          have a bunch of these they'd stick on each other. It
          would be sucky if they're the same size, but a reasonable
  Rossen: The other problem is when sticky is above the trigger so
          we have to either define so it's brought back or it
          doesn't trigger.

  dbaron: The other fun case is if you have both top and bottom or
          left and right and figuring out who wins
  Rossen: We can use the scroll direction as a preference so if
          you're scrolling down we take preference of the top.
  hober: Having the behavior depend on initial scroll direction is
         weird. As an author trying to debug, not realizing it's
         that you originally scrolled in a certain direction...
  dbaron: I think he meant by which way you can scroll to overflow.
  hober: I'm presuming you've scrolled a bit.
  Rossen: Initially. When the scroller is at origin than you have a
  hober: That does seem reasonable.

  adenilson: I have all three browsers open and they're all doing
             something weird.
  dbaron: It's a weird testcase.
  dbaron: We should try and fix this.

  TabAtkins: We're no longer shipping sticky.
  TabAtkins: It's in stable, but not in less stable versions.
  dbaron: I think Chrome has sticky in its experimental web
          platform, but Apple is shipping and we are.

  TabAtkins: The more I think about it Webkit's behavior makes sense.
  dbaron: It makes sense to pull to the opposite edge.
  TabAtkins: It doesn't want to exit it's containing block.
  hober: Which is undesirable in the weird case where they're
         the same.
  Rossen: Having section don't necessary mean...they can be
           separated by headers.
  hober: But they do stack.
  TabAtkins: This is how I'd expect if the containing block is
             the viewport.
  Rossen: Or if the release is defined by interacting with another
          sticky item.
  hober: No, no.

  dbaron: You can compute this locally and this is all data you want
          to send to your compositor. What I don't like about
          Webkit's approach is it's totally different information in
          that one case.
  dbaron: In every other case it's in the scrolling except in that
          case where the release is a scrolling position.

  fantasai: Sticky is relative to the nearest ancestor.
  fantasai: It's sticky in both dimensions?
  hober: Yes. In the axis you set and offset.
  dbaron: top/bottom/left/right auto means not sticky.
  hober: It's relatively positioned, but you haven't offset it from
         it's original static position.
  fantasai: Okay.

  dbaron: In Firefox the green one is honoring the bottom 180 and
          the orange one is honoring the top 180
  dbaron: Green starts like that because that's bottom 180.
  dbaron: There's no release constraint, just sticky.
  TabAtkins: Whereas in ours this means sticky so it stays.
  hober: So there's a release side where you're willing to release
         but if you haven't hit that you should stick.
  TabAtkins: Now that I can see it live, I can see it's a bug,
  TabAtkins: I'm not sure...
  TabAtkins: If I like it or not.
  TabAtkins: If you say the green is bottom 180, top 0 it wouldn't
             ever fall off.
  dbaron: It's kinda an edge case and I just want the make the
          implementation simpler and don't have to worry about a
          release that's outside the box.
  TabAtkins: I'm assuming this is because it's easier, but I'm
             not sure.
  hober: I think Simon thought through a lot of edge cases.
  TabAtkins: I'm not opposed to changing.

  dbaron: I think we're done this topic.
  TabAtkins: How is editing position?
  Rossen: It's going.
  TabAtkins: You have a plan?
  Rossen: Yeah.
  Rossen: I have most of this edits done, I have to clean it up.
  TabAtkins: Can we define static position in your draft?
  Rossen: Fine with me. We need it for flex and grid.
  plinss: We haven't published a WD in 2 years.
  Rossen: As soon as I have the edit I'll ask for a new WD.


  glazou: A few minutes ago I e-mailed TTA to thank them for hosting.
          I think the walking distance hotel was very convenient and
          they were incredibly helpful.
  <liam> [I would like to thank Daniel for the audio webinar
  glazou: I'd also like to thank dwim for all the help he gave us
  <glazou> Thanks dael!

  [Meeting adjourned]
Received on Friday, 13 June 2014 14:23:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:30 UTC