- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 20 Jan 2016 21:07:36 -0300
- To: www-style@w3.org
Grid Layout
-----------
- RESOLVED: Gaps between grid tracks are suppressed (always) at
fragmentation breaks. Add note pointing out this is
different from margins.
- Rossen will review the discussion on missing named lines search,
but pending his review it looks good.
Snap Points
-----------
- RESOLVED: Rename scroll-snap-area to scroll-snap-margin
- RESOLVED: If previously snapped, must resnap to that same snap
position after content changes (if possible). If not
snapped previously and now in range of a snap
position, must snap.
- After the above resolution, there was concern about the second
sentence.
- RESOLVED: The second sentence of the previous resolution is not
precise enough.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Jan/0132.html
Present:
Rossen Atanassov
Tab Atkins
Bert Bos
Tantek Çelik
Greg Davis
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Thierry Michel
Simon Pieters
Anton Prowse
Matt Rakow
Florian Rivoal
Alan Stearns
Regrets:
David Baron
Dave Cramer
Dael Jackson
Brad Kemper
Peter Linss
Johannes Wilm
Scribe: fantasai
Grid Layout
===========
Suppressing grid gaps at fragmentation breaks
---------------------------------------------
<astearns> https://drafts.csswg.org/css-grid/issues-wd-20150917#issue-19
fantasai: mats filed issue on suppressing grid gaps at
fragmentation breaks.
fantasai: We added text to spec saying that gutters (grid-gap) and
gaps due to content alignment (e.g. align-content: space-
evenly) are suppressed at fragmentation breaks,
fantasai: both for forced and unforced breaks.
fantasai: We wanted to check with WG.
Rossen: Are we sure of this difference?
TabAtkins, fantasai: yes
TabAtkins: Gutters are only for separation between tracks, never
at the start of content in the box, unlike margins
which are used for both (hence heuristic).
Rossen: just want to make sure this is what we want to do
florian: I buy the rationale from TabAtkins.
stevez: Me too.
Rossen: Model makes sense from layout point of view, unsure about
design point of view. I defer to people who are
representing designers point of view.
fantasai: If you want, I can ask more people, but seems really
obvious to me.
astearns: I'm not sure I understand the problem with regard to the
background of grid being fragmented [concern from Rossen
mentioned earlier, not minuted].
Rossen: You'd have misaligned background.
fantasai: You can't be relying on pixel alignment of backgrounds
and content during fragmentation.
fantasai: Fragmentation introduces extra space,
fantasai: due to moving things so they don't get sliced in the
middle.
Rossen: I guess if group doesn't have a problem with this, then
okay.
astearns: Rossen has the one concern. Anyone else have a concern,
or just go with what we have in the draft now?
<silence>
astearns: Should we put a note about alignment with background
images?
fantasai: I don't think it's needed. We don't do that with margins
either.
Rossen: ... with margins, backgrounds are assigned to the elements
themselves. With grid I can imagine setting background on
the grid container.
Rossen: If we're ignoring this case, not a concern, want to make
sure we're considering it.
fantasai: Don't understand why this is different from block layout.
TabAtkins: More likely to want to have background on the grid
container, because stuff like sizing is set on the
container.
fremy: Why not clip out the background?
fantasai: I would rather just be consistent with the way margins
and everything else works
Rossen: Yes, let's be consistent with everything that's not a grid
fantasai: I don't think we can make a good argument that being
different is better for grid. Maybe make argument that
both options are the same. So let's be consistent.
astearns: So, proposal is fantasai's proposal, plus a note.
fantasai: If you really want space at the top after a forced
break, can always add margins.
RESOLVED: Gaps between grid tracks are suppressed (always) at
fragmentation breaks. Add note pointing out this is
different from margins.
Missing named lines search
--------------------------
<astearns> https://drafts.csswg.org/css-grid/issues-wd-20150917#issue-26
<astearns> email from Manuel:
https://lists.w3.org/Archives/Public/www-style/2016Jan/0063.html
fantasai: Issue raised by Manuel on searching for a missing named
line.
fantasai: E.g. looking for 2nd foo line, and only one foo line; or
looking for foo line and no foo line.
fantasai: We specced that all implicit lines carry all names,
fantasai: but this creates weirdness if you start in implicit
grid, and then span to a named line.
TabAtkins: Exact situation is a bit complicated, see email from
Manuel's email with good examples.
TabAtkins: If you're interested, please read into it. But we're
trying to match Firefox and proposed Chrome behavior
here.
<fantasai> (have agreement on the ML)
TabAtkins: This is an error case anyway.
astearns: Do you think this needs wide review?
fantasai: No, pretty sure this is the right answer. Just wanted to
give WG a heads-up in case someone particularly wants to
take a look.
Rossen: I'll review and provide feedback later.
fremy: Looks good to me.
astearns: Okay, will give a chance for more review, seems fine
overall.
TabAtkins: Grid's in a stage where we want to make sure the WG
gets a heads up on all changes, since it's pretty
stable (nearly CR).
Scroll Snap
===========
Rename scroll-snap-area to scroll-snap-margin
---------------------------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Jan/0095.html
fantasai: We propose to rename scroll-snap-area ->
scroll-snap-margin
TabAtkins: Originally scroll-snap-area specified both the box and
the offsets.
TabAtkins: But decided to stick with border-box always, which
makes it exactly like 'margin'.
TabAtkins: So like scroll-snap-padding is just like padding, this
is just like margin, should make it match.
Florian: What if want to add that ability later?
TabAtkins: Can put into another property if needed.
Florian: Sure, go ahead.
RESOLVED: Rename scroll-snap-area to scroll-snap-margin
Re-snapping Requirements
------------------------
fantasai: Next issue is resnapping requirements.
TabAtkins: Whenever your content changes, you're either snapped or
not.
TabAtkins: New snap positions get added, removed, stuff moves
around, what happens?
TabAtkins: Previous wording in spec wasn't great, didn't describe
cases appropriately.
TabAtkins: We settled on wording that if content changes, pretend
the user had just scrolled to the position that it's
now at, and re-snap if necessary
TabAtkins: However, if it was previously snapped to an element,
follow that element even if it's farther away now,
TabAtkins: because that keeps what's in the viewport most
consistent.
TabAtkins: Both cases are must, not should.
TabAtkins: The only difference is that if not tracking a snap
position, proximity might not snap if there's no nearby
snap position.
Florian: Yes, agree with this wording. Agree must is important,
would insist on it.
TabAtkins: Doesn't seem like there is any rationale for following
in mandatory case but not proximity.
TabAtkins: That's why must in both cases.
MaRakow: Yes, I agree...
MaRakow: Do we want musts all the way across?
Florian, TabAtkins: yes.
MaRakow: I think it's an edge case considering is if you're
snapped and that position becomes invalid.
TabAtkins: What's invalid?
MaRakow: If viewport shrinks so the snap position is out of bounds.
Florian: We wanted to deal with edge case separately (agree we
need to deal).
MaRakow: Yes, agree, if possible to snap to the previously snapped
position, must re-snap to that.
MaRakow: If not possible, then can't...
RESOLVED: If previously snapped, must resnap to that same snap
position after content changes (if possible). If not
snapped previously and now in range of a snap position,
must snap.
<MaRakow> I think we were only resolving on the first sentence --
discussing the second sentence now
Florian: If you're snapped to a no longer reachable mandatory snap
point, you should re-snap to something else.
TabAtkins: As currently written, a snap point that is outside
scrollable area, it's still a valid snap position. You
can still snap to it, just can't get all the way over
to it.
TabAtkins: I think this is sane, especially if the item is moving
around and goes only a little out of range.
TabAtkins: You just scroll over as far as possible.
Florian: I agree to proximity, not sure for mandatory...
<MaRakow> +1 Florian
<astearns> I thought this was already-snapped, now in a state
where that snap might not be possible
<MaRakow> maybe we should clarify
TabAtkins: If you have 2 snap points, 1 10px into unscrollable
area, and one 1000px away in scrollable area, you will
snap to the element that's 10px outside the scrollable
area; it is the closest snap position
Florian: From authoring pov...
fantasai: Imagine I have, e.g. CSSWG issues list.
fantasai: I have a bunch of small boxes, mandatory snapping.
fantasai: If I'm snapped to a box at the bottom of the page,
should be same behavior as if I targeted with #fragment.
tantek: I agree with fantasai.
Florian: For proximity makes sense, for mandatory doesn't make
sense.
Florian: Mandatory says it's wrong to be anywhere except where I
said.
fantasai: If your viewport is too big, then, you will *never* be
able to reach certain content because it won't fit
"perfectly"
<vollick> It sounds like this is a difference of opinion on what
it means to be "at" at snap point. If we define snapped
to be "at or as close as you can get" then this is
consistent, right?
MaRakow: 3 items to mention:
MaRakow: I agree with Florian wrt mandatory if snap position
becomes invalid.
MaRakow: We already resolved not to artificially add snap point at
start/end of scroller.
TabAtkins: Right.
MaRakow: [missed]
MaRakow: The next scrolling operation.. we hit this bug a few
times .. next scroll operation will try to hit the next
nearest snap point, which would have a disruptive action.
MaRakow: Would look like browser forgot to scroll to nearest snap
point.
MaRakow: If you touch screen and then release, it would snap
somewhere else.
MaRakow: e.g. have a snap point just out of reach, and one a page
away.
MaRakow: A user tries to scroll to see what's left,
MaRakow: you're in an error case if out of range for snapping to.
MaRakow: Not a great state to be in.
MaRakow: We wouldn't want an artificial snap point at start/end.
TabAtkins: This isn't an artificial start/end snap point.
MaRakow: You're in a limbo state, can't naturally get to.
[fantasai gives example of an item on the left edge, mandatory
snapping, other snap points far enough away that you
can't see it when snapped to any other point]
fantasai: If you don't allow the user to snap to this item by
scrolling all the way to the left, just because it won't
center like it requested, then the user can't see it ever.
[...]
Florian: I still think that when the author puts the list of
mandatory positions, means that the content match exactly
there... however if it's not possible for it to render
some unreachable content, it's an author error, should
therefore have behavior TabAtkins and fantasai are
advocating it.
Florian: Should warn authors not to do this.
<MaRakow> +1 to Florian
fantasai: I think it's an error if the item is off the screen to
where we can't scroll it into view, never mind snapping.
fantasai: However, I don't think it's an authoring error to have
an item that can be seen but can't be snapped into its
preferred alignment position.
tantek: I agree with fantasai ...
tantek: Also, if you can't get what the author asked for, getting
close as possible makes more sense than draconian giving
up... for apparently no reason, if you're just a few
pixels off.
tantek: I'm against draconian methodology.
Florian: Okay, I now agree with fantasai.
Florian: Having a warning...
fantasai: I think putting things in invisible regions is generally
bad authoring ...
hober: Webkit behavior, thinking was that when an author makes a
mistake, should still be possible for the user to get to
all the content.
<fantasai> hober++
<tantek> yes - that's kind of a11y 101
hober: So I agree with Tab and fantasai's proposal here.
hober: Especially with differences of screen sizes, quite easy for
authors to make this mistake.
hober: Want to make sure you can cause all the snap elements to be
visible on the screen at some point.
<Florian> hober+1
Florian: Do you still consider it an authoring error?
hober: I think it's possible in CSS to make content invisible to
user, not necessary to call out every case.
MaRakow: Sounds like we should allow snapping to such positions by
user action as well.
fantasai: Yes, definitely.
MaRakow: So should we reverse resolution on start/end snappoints?
fantasai: No!
fantasai: There shouldn't be a snap position at start/end always.
fantasai: It's just that if an item can't be positioned as it
wants for snapping, you pretend its snap position is as
far as is possible to scroll.
TabAtkins: If you're using snap points, assume that you've put
snap positions on anything that's worth looking at.
fantasai: E.g. consider case of photos, view on smaller screen
have center snap for each, great.
fantasai: On larger screen, can fit 1.5 photos, can't get last
photo centered. Treat scrolled-to-edge as its snap
position.
MaRakow: Seems like we need to specify conditions under which this
happens...
fantasai: Proposal has spec text already...
Florian: What happens if you have several mandatory snap positions
that are all out of reach. Do you collapse them, or
maintain each as an individual position for semantic
gestures like pgup?
TabAtkins: Not defined
TabAtkins: Wording about this is in 7.3 of the proposal
<astearns> If the most appropriate snap position is unreachable,
such that aligning to it would require scrolling the
scroll container’s viewport past the edge of its
scrollable area, the scroll container must be scrolled
as much as possible in each relevant axis toward the
desired snap position.
<TabAtkins> https://drafts.csswg.org/css-scroll-snap/#choosing
TabAtkins: Not copied over into Matt's copied yet
Florian: Okay, I agree with what Tab and fantasai are proposing. I
think we should resolve on that. Might later ask for a
note, but in any case agree with proposal.
astearns: So back to second sentence in previous resolution?
MaRakow: Disagree with it for proximity.
MaRakow: Suppose case where rapidly deleting things..
fantasai: Re-snapping is after settling... Why would mandatory /
proximity behave differently?
fantasai: Don't want to leave user in situation via JS that they
can't get to themselves, right.
MaRakow: [missed]
TabAtkins: If you don't move it, you're in an impossible scroll
position.
TabAtkins: If you have 2 things close to each other, delete one,
other one is in range, do you scroll to it.
MaRakow: There are ways to scroll to proximity snap points that
don't encourage snapping?
TabAtkins: How does that work?
MaRakow: e.g. our implementation of proximity varies the proximity
well size depending on precision of scrolling mechanism[?]
MaRakow: If you try to precisely drop the scroll, don't want to
snap.
TabAtkins: That's fine.
TabAtkins: We invoke that with "if the user did a direct scroll to
that spot", so should match that behavior.
<fantasai> "The UA must resnap as if the user scrolled to this
snap position"
TabAtkins: Do whatever if the user would do if the user scrolled
to that spot.
TabAtkins: If you have better wording, great.
Rossen: Maybe hack this out offline?
MaRakow: I think the 2nd resolution should be modified based on
what you said.
TabAtkins: Resolution is usually a bit rough wording in the minutes.
TabAtkins: I'm fine with more precision whatever.
RESOLVED: The second sentence of the previous resolution is not
precise enough.
Received on Thursday, 21 January 2016 00:08:34 UTC