- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 26 May 2015 19:18:09 -0400
- 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