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

[CSSWG] Minutes New York F2F 2015-05-18 Part II: Grid Issues

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 26 May 2015 19:18:09 -0400
Message-ID: <CADhPm3traMyzYZdxgiAb1-pbF4ueMFLaBCviwsY0sk_ZmbOAng@mail.gmail.com>
To: www-style@w3.org
Grid Issues
-----------

  - RESOLVED: Boxes whose parent and containing block is the grid
              container, e.g.
                <grid-container position: relative>
                  <abspos/>
                </grid>
              For these boxes, the grid container determines both
              their size and their static position.
  - RESOLVED: Auto line in grid-positioned abspos counts as the 0th
              line (for start lines) or -0th line (for end lines)
              for span calculation purposes.
  - RESOLVED: Proposal E wins for issue 17: Treat all out-of-range
              indices and missing named lines as 'auto'. This means
              missing start lines will be assigned to the start
              padding edge, and missing end lines will be assigned
              to the end padding edge.
  - RESOLVED: The auto line is always at the padding edge.
  - RESOLVED: We will error-correct mis-ordered lines (in all cases).

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

Agenda: https://wiki.csswg.org/planning/new-york-2015#agenda
Scribe: Bert

Grid Layout Abspos Issues
=========================

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015May/0148.html

Inconsistent use of grid-positioning btw static pos and abspos sizing
---------------------------------------------------------------------

  TabAtkins: 2 basic cases:
  TabAtkins: A and B
  TabAtkins: Case A grid container determines static position
  TabAtkins: Case B grid container determines size
  TabAtkins: Case C grid container determines both
  fantasai: [Draws on whiteboard]
  fantasai: [3x3 grid, cell 8 is container, elt has an offset
            relative to top left of cell 1]
  fantasai: This is in the case 'grid-row: 3; grid-column: 2'  .

  fantasai: The grid container forms the containing block (CB) for
            the abspos element.
  fantasai: If you don't specify grid position properties, then
            the grid container padding edges forms the containing
            block.
  fantasai: Therefore, by default (when grid-positioning properties
            are auto), abspos in grid behaves identical to a block.
  fantasai: Abspos in grid *with* grid positioning property uses the
            grid *cell* as the CB, rather than the grid padding box.
  TabAtkins: This was done to address use case of content responding
             to grid but not vice versa.
  [Allows positioning to the grid without affecting the grid or its
   contents.]

  TabAtkins: 1st issue is:
  TabAtkins: We treat the two cases separately (determining static
             pos, determining CB), so in the case where the abspos
             is both, the abspos's static position can be outside
             its CB.
  TabAtkins: We called this case out specially in the draft,
             specified that static position respects the grid cell
             bounds.
  fantasai: There are 3 possibilities:
  fantasai: C) We don't care that the static position is outside.
  fantasai: A) In cases where grid container is both parent and CB
               of abspos elt, then static pos uses grid positioning
               props.
  fantasai: B) In all cases, if parent is grid container, then use
               grid positioning properties to determine static pos.
  TabAtkins: Editor's draft currently has #2; used to be #1.

  dbaron: If grid positioning properties are used, in 3rd case, is
          the static pos (0,0)?
  dbaron: I'd like not to add more complications to static position.
          It was a hack in the first place...
  dbaron: Don't complicate it unless there is a use case.
  dbaron: So you propose B?
  TabAtkins: No, A
  dbaron: The ordering of proposals is weird...

  TabAtkins: I find B incoherent.
  TabAtkins: Grid container parent and CB are using same grid
             positioning properties, even if they may be different
             grids.
  TabAtkins: So I'm for A or C.
  TabAtkins: Spec says A currently.
  fantasai: Previous draft said C, we changed it.

  Rossen: Flex spec is closer to C.
  Rossen: If you have props that target grids, and your parent is a
          grid,
  Rossen: your static pos may be affected.
  Rossen: In Flex we said, your static pos is not affected.
  Rossen: So I'm with dbaron.
  Rossen: More or less static pos tracks inline position.
  TabAtkins: OK
  fantasai: OK
  dbaron: Or we can says in some cases static pos is (0,0), more
          like A.
  fantasai: You can set offsets to 0, if you want it in that box.
  Rossen: fantasai said static pos possibly outside grid, that is
          not a pb. You can either use 0,0, or use grid-row/columns.

  fantasai: Another option is define 'auto' offsets to mean use the
            grid cell lines.
  TabAtkins: That is option A
  fantasai: No, say you have an arbitrary descendant of the grid,
  fantasai: and it is absolutely positioned,
  fantasai: I want it to be positioned per grid-positioning
            properties.
  fantasai: You'd have to set all offsets to 0:
  fantasai: left: 0; right:0; top: 0; bottom: 0;
  Florian: Is that same as A?
  TabAtkins: There is a difference in case [...]
  [The difference is that we're ignoring the static position
      altogether.]

  Rossen: Why do we mix static pos and grid pos?
  Rossen: If I have an inline absolutely positioned elt,
  Rossen: And I have a static pos based on its text wrapping,
  Rossen: Why then do I need to ignore the static pos when an
          ancestor is a grid?
  Rossen: If it is a first-level child of the grid,
  Rossen: then static pos is determined by the grid parent.
  TabAtkins: In both A and C, the static pos computation must be the
             same.
  [Confusion over which is A which is C]
  dbaron: Tab said grid positioning properties should not apply to
          two different grids.
  dbaron: That implies grid positioning properties need to *never*
          apply for determining static pos.
  TabAtkins: OK, so static pos is always (0,0).

  Rossen: [Draws trees]
  Rossen: When computing the static position in either of these
          trees,
  Rossen: the grid element may or may not be positioned itself.
  Rossen: The static position should always be computed relative
          to CB.
  Rossen: If abspos element is direct child of grid,
  Rossen: then the question is if row/col should be taken into
          account.
  Rossen: That is the only issue we have to decide on.
  dbaron: Inside there may be another grid.
  Rossen: We are talking about static position.
  dbaron: There may be nested grids. Then grid-row/column property
          may be applied twice.
  Rossen: That is exactly what I don't want.
  Rossen: If we all agree that we want the simple case, static pos
          is (0,0), i.e, not based on grid-row/column properties,
          then life becomes simple.

  SteveZ: If an element is inside a container, and I want it in a
          cell...
  Rossen: Compare the case of absolutely positioned element between
          two table rows, what is its static position? That's the
          same case.
  SteveZ: It seems the default doesn't do the right thing. It should
          have all four offsets 0.
  Florian: So Rossen's objection is that static pos should not
           depend on whether parent is a grid?
  Rossen: Yes, because then an unrelated property may require
          re-validating.

  RESOLVED: Proposal c: Boxes whose parent and containing block is
            the grid container:
            <grid-container position: relative>
              <abspos/>
            </grid>
            For these boxes, the grid container determines both
            their size and their static position.

  ??: Do I have to find the margins and paddings if I want an elt to
      span?
  fantasai: No, span from 1 to -1. That is different from static pos.

Relationship of automatic padding-edge lines to regular grid lines
------------------------------------------------------------------

  TabAtkins: 2nd issue:
  fantasai: Initial value of grid positioning properties is 'auto'
  fantasai: That puts an element into the next empty slot.
  fantasai: [ But for abspos, we don't have this concept so instead ]
            There is an implied special line at the padding edge,
            the 'auto' line.
  fantasai: But then we we need to define these lines relative to
            rest of grid.
  fantasai: What does span 2 mean?
  fantasai: Is it the "negative 0" line?

  SteveZ: So you're giving a label to the line?
  fantasai: We're not actually allowing to refer to the line directly.
  Rossen: Authors would expect in a 2x2 grid with span 2, you would
          span the slots.
  TabAtkins: You'd have to say span: 1/2
  SteveZ: These cases will be explicitly warned about in the spec?
  Rossen: Seems OK, if you want to snap to a grid line, then say so
          explicitly.

  RESOLVED: Auto line counts as the 0 or -0 line for span purposes.

Handling of nonexistent lines
-----------------------------

  [ Issue is about abspos items whose grid positioning properties
    refer to lines that don't exist. ]
  TabAtkins: Next issue. Any lines beyond implicit grid are clamped.
             Position at line 100, will be at actual last line.
  fantasai: But that doesn't work for spans,
  fantasai: So option A is not an option.
  fantasai: Valid options are B, C, D, E.
  Rossen: I like E
  TabAtkins: E is terrible.
  Rossen: Yes, it is invalid, so you fall back to static position.
          It is an error condition.

  SteveZ: So I have a 2x2 grid and position to start on 2 and 4,
          what happens?
  TabAtkins: [Draws case with 2x2 grid and position assigned to 3/5]
  SteveZ: So I will see something in the padding area?
  TabAtkins: Not in option C. In D and E yes.
  TabAtkins: In that case 3 is valid line, 5 is not. Take case 4/5,
             both lines invalid.
  SteveZ: So the case with one valid line and one invalid?
  fantasai: In a lot of error cases you'll end up in the padding
            area [either because you spanned across it or because
            you're entirely outside the grid and got pushed back in].
  SteveZ: As long as I at least see something, so I can see I did
          something stupid.
  TabAtkins: In normal grid 3/5 and 4/5 look very similar. Would be
             strange if abspos suddenly changes that.
  SteveZ: So if I understand: You want to snap to last valid line
          and snap to auto line if [...]
  SteveZ: In 4/5 case, nothing displays, it's zero-width.
  dbaron: In fantasai's case it sounds like people are more likely
          to use it as a feature.
  <dbaron> (which I think is probably a bad thing)

  ??: Changing the grid may make it impossible to see why things go
      wrong.
  fantasai: Could say invalid start edge means first padding edge,
            invalid end edge means last padding edge.
  TabAtkins: [Draws]
  TabAtkins: 3/100 shows on the right, 4/100, because 4 is invalid,
             spans whole elt.
  TabAtkins: Under proposal D, 4/100 would also be on the right.
  TabAtkins: So choices are D and E.
  strawpoll: 7 for E, 2 for D = E wins
  <dbaron> (Tab and I were for D)

  RESOLVED: Proposal E wins for issue 17: Treat all out-of-range
            indices and missing named lines as 'auto'. This means
            missing start lines will be assigned to the start
            padding edge, and missing end lines will be assigned to
            the end padding edge.

If the 'auto' line is positioned inside the geometric space of the grid
-----------------------------------------------------------------------

  TabAtkins: Final issue:
  TabAtkins: We said final line is the padding edge.
  TabAtkins: That is fine if the grid container is bigger than the
             grid.
  TabAtkins: Now imagine the grid container is smaller.
  TabAtkins: And assume overflow is visible.
  [ In overflow cases, we use the inner padding edge, i.e. the one
      that belongs to the scrollable area, not the scrollbox
      itself. ]
  <dbaron> Does CSS actually define that "inner padding edge"?
  dbaron: Is that the correct padding edge as defined by CSS? Is
          that term defined at all?

  TabAtkins: [Draws on whiteboard]
  TabAtkins: There are four options.
  TabAtkins: A, B, C, D
  TabAtkins: A is last grid or padding, whichever is further out.
  TabAtkins: B is to flip start/end to match spatial relationship of
             the lines
  TabAtkins: C is to ignore auto line, make effective CB zero-sized
  TabAtkins: D is anything else.

  Rossen: We don't ignore static pos in normal case, so we shouldn't
          ignore it here.
  Rossen: I believe that means option B.
  fantasai: We already decided we use the auto line, we now have to
            decide where the auto line is.

  Florian: So in case B, do we make position '5/3' be the same as
           '5/3'?

  plinss: Why do we have an auto line that is not grid line?
  fantasai: Because position is normally defined by a box, not a
            grid line.
  TabAtkins: We want to be able to position against the edge.
  fantasai: Grid doesn't always fill the container.
  fantasai: E.g., a centered grid in an element, or with a large
            padding.

  TabAtkins: So Rossen likes B, Florian suggested changing the error
             correction by swapping 5/3 to 3/5.
  TabAtkins: Should we always treat 5/3 as 5/3?
  TabAtkins: Or 5/3 becomes 5/auto, as currently?
  plinss: Also swap named lines?
  TabAtkins: Yes, same way.
  Rossen: Makes sense. Imagine you snap to lines and later reposition
          the lines.
  TabAtkins: It may not be intentional, it may be just a mistake,
             but I'm fine with it.

  SteveZ: I'd need more time, but...
  SteveZ: but I'm bothered that turning off scrolling makes things
          behave differently.
  TabAtkins: Overflow does that.
  SteveZ: It seems a simple change, but with unexpected results.
  SteveZ: Not sure what option B means.
  TabAtkins: It means auto line can be always the padding edge, even
             with overflow.

  TabAtkins: A and B each make two different cases out of four
             consistent.
  TabAtkins: A makes overflowing grids inconsistent with overflowing
             blocks
  TabAtkins: B makes error-handling inconsistent between abspos and
             not.
  ...
  TabAtkins: So seems we lean to consensus on B.
  TabAtkins: Proposal: Padding edge is always the auto line, and we
             will error-correct mis-ordered lines.

  RESOLVED: Padding edge is always the auto line, and we will
            error-correct mis-ordered lines.

<br type=lunch>
Received on Tuesday, 26 May 2015 23:18:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:31 UTC