- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 7 Jun 2016 21:25:23 +0300
- 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.
=========================================
Scroll Snapping
---------------
Archival Copy of the Change Proposal being discussed:
https://lists.w3.org/Archives/Public/www-archive/2016Jun/att-0002/Overview.html
- RESOLVED: No ability to specify the strictness of snapping
separately per axis.
- RESOLVED: Allow the keyword to be dropped, default to proximity.
- RESOLVED: Ordering of keywords is strict in scroll-snap-type
(to allow for extensions)
- RESOLVED: Values are x | y | block | inline | both | point ,
where point would be dropped after next publication.
- RESOLVED: Require (for now) an explicit axis and will gather
more info as we can (to decide between physical and
logical direction as the default).
- RESOLVED: make snap-align behave like a subset of background
position (from fantasai's proposal:
https://lists.w3.org/Archives/Public/www-style/2016Jan/0133.html).
- RESOLVED: Add section 6.2.2 (Snapping Boxes that Overflow the
Scrollport) and add issues.
- RESOLVED: Add section 6.2.1 (Scoping Valid Snap Positions to
Visible Boxes) as an open issue
- RESOLVED: Add section 6.2.3 (Unreachable Snap Areas)
- RESOLVED: Merge section 6.3 (scroll-snap-stop) with
* an issue about whether it applies to 2D
* an issue to bikeshed "normal"
- RESOLVED: Merge section 7.3 (Choosing Snap Positions) with
* parenthetical of "corridor" point moved to start the
paragraph
* JS element-targetting scrolls added into the :target
paragraph
- RESOLVED: Add section 7.1 after removing "explicit" "inertial"
and "directional" definitions, moving the first
sentence and adding a more precise definition of when
an active scrolling operation is done so we know when
to start snapping.
- RESOLVED: Merge 7.0 (introductory text) too
- RESOLVED: Add fantasai and TabAtkins as editors to scroll
snapping
- RESOLVED: Shortname css-snappoints -> css-scroll-snap
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics
Scribe: Florian
Scroll Snapping
===============
Change of axis
--------------
<fantasai> https://drafts.csswg.org/css-scroll-snap/diff
<fantasai> https://drafts.csswg.org/css-scroll-snap/diff-notes
<fantasai> https://drafts.csswg.org/css-scroll-snap/diff-notes#change-axes
fantasai: An outstanding difference is syntax of scroll-snap-type
fantasai: Matt is wanting to change from the proposed syntax
none | [ proximity | mandatory ] || [ x | y | block |
inline | both ]
fantasai: to a syntax where both is replaced by repeating axes
fantasai: in order to allow for different snapping strictness per
axis.
MaRakow: I previously didn't like axes being different for
mandatory vs proximity was because it didn't make sense
for point snapping
MaRakow: but it does make sense for 2 x 1D.
MaRakow: So the proposed syntax allows do different mode if you're
2 x 1D, but a single mode for point snapping.
myles: Usecases?
MaRakow: In one dimension, you have clearly defined columns, and
in the other you want sort of a paginated experience in
the other.
myles: If you have columns, you would want mandatory in 1
dimension, and no snapping in the other.
MaRakow: Are you making a case against 2 x 1D snapping?
myles: Yes.
fantasai: We could change the syntax to pair the axis and its
snapping type, and for now only allow for 1 axis, and
defer to later the possibility to have both.
MaRakow: We initially talked about separate properties for axes
and strictness, but if we're merging into a single
property ....
<MaRakow> https://lists.w3.org/Archives/Public/www-style/2016Apr/0146.html
MaRakow: A few things I was concerned. Should we allow snapping
differently between each axis, and make sure we only get
one strictness for point snapping?
MaRakow: Are people interested in having different strictness per
axis?
myles: Apple is not interested in having different strictness.
TabAtkins: Fine for now.
astearns: Objections?
RESOLVED: No ability to specify the strictness of snapping
separately per axis.
Florian: Should we also resolve on a concrete syntax?
fantasai: Yes
fantasai: The syntax in our spec allows for the keyword to be
omitted, so we need to either require it or pick a
default.
<fantasai> A) none | [ proximity | mandatory ] || [ x | y | block
| inline | both | point ]
<fantasai> B) none | [ [ mandatory | proximity ] [ x | y | block |
inline ]? ]{1,2} | [ mandatory | proximity ] point
fantasai: First: do we require the strictness keyword?
fantasai: If we don't, an axis would imply proximity.
MaRakow: Explicit is good.
fantasai: Short is good.
fantasai: That we're snapping is implied in the name.
leaverou: Conciseness is good, we should pick a default. And
proximity is a good default.
astearns: MaRakow would you object?
MaRakow: No objection.
astearns: Anyone else?
RESOLVED: Allow the keyword to be dropped, default to proximity.
fantasai: Second: do we require a particular ordering, or is "x
proximity" and "proximity x" both fine?
fantasai: In general we allow reordering
fantasai: but that gets in the way of allowing (in the future) to
add different strictness by axis.
fantasai: So I would prefer being conservative, and not allowing
reordering for now.
MaRakow: works for me
(+1 from Myles)
leaverou: Alternatively, we can allow different orders now, and in
the future we use a slash to separate.
fantasai: Or required ordering only if you have two.
astearns: I prefer being strict now.
fantasai: Sounds good.
RESOLVED: Ordering is strict.
<Rossen> https://drafts.csswg.org/css-snappoints/#valdef-scroll-snap-type-point
<Rossen> https://lists.w3.org/Archives/Public/www-style/2016Mar/0353.html
Rossen: We already have a resolution to move point snapping to
level 2.
Rossen: Resolved in Sydney.
Rossen: Why is it still in the spec?
fantasai: That prose was never on /TR, we wanted there before
pushing to next level. Just procedural.
Rossen: Ok
<astearns> x | y | block | inline | both ?
fantasai: syntax would be x | y | block | inline | both | point ,
where point would be dropped
MaRakow: plus the optional strictness?
fantasai: yes
RESOLVED: x | y | block | inline | both | point , where point
would be dropped
Difference in logical axis
--------------------------
<fantasai> https://drafts.csswg.org/css-scroll-snap/diff-notes#change-align-axes
fantasai: A difference is logical axes. We felt it was important
to have the difference between block vs inline.
fantasai: One major reason is consistency with Level 4
background-position, which was already resolved.
fantasai: Another is that, although which axis is snapped may be
physical or logical, whether you snap to the start or
end within an axis is nearly always logical.
<fantasai> (I know of no physical use case)
MaRakow: The reason I put it as x + y is to match the overflow
properties.
fantasai: The overflow props don't have a 2-value syntax.
fantasai: We have overflow-x and overflow-y, but also -block and
-inline in the logical props spec.
fantasai: You can choose which is more important to you.
fantasai: Once you have chosen, within an axis, the decision is
writing mode dependent.
fantasai: I have a hard time seeing use cases for physical.
MaRakow: For background position, if you have 2 values, the first
is horizontal and the second is vertical.
<fantasai> https://drafts.csswg.org/css-backgrounds-4/#the-background-position
MaRakow: but I am more worried about overflow:auto, not specifying
MaRakow: and then specifying snapping physical makes more sense.
fantasai: If you don't specify, it defaults to the block axis.
fantasai: If you don't specify the scroll-snap-type axis it
defaults to block axis.
fantasai: Scrolling inline is an exceptional case.
fantasai: The spec is intentionally biased to be a logical system.
MaRakow: I prefer default to physical.
fantasai: [disagrees]
MaRakow: Discussed that on the phone a couple of months ago.
MaRakow: My position is still that the main use cases are physical
<fantasai> This is my position:
https://lists.w3.org/Archives/Public/www-style/2016Jan/0133.html
Scribe: fantasai
Florian: My recollection is the conclusion was more subtle than
that
Florian: regardless of whether primary use cases are physical or
logical.
Florian: Even when physical, the coupling of scrolling axis works
better when logical, even for physical use cases.
Florian: I think back to what you were saying earlier: when you
only have one axis for scrolling, which is typical case,
you don't need to specify and it just falls out.
Florian: If you specify scrolling axis physically, it just works.
Florian: The case for having to specifically physical snapping
axes, is a bit of a red herring.
Florian: Use case might be physical, but the scrolling is physical
not just the snapping.
Florian: In Tab and fantasai's proposal, it works.
Florian: Without doing anything extra fancy, if you have physical
scrolling in the case, it just works.
Florian: For these cases it's okay either way.
Florian: For the other cases, where you care about logical
directions, its preferable with logical coordinates.
MaRakow: Reason why these are chosen physically, is based on
physiology, eg using mouse wheel,
MaRakow: or swiping on a screen.
MaRakow: Layout seems to be based on that.
Florian: Scrolling is physical, not the snapping.
fantasai: I didn't understand what you just said Florian.
Scribe: Florian
fantasai: The cases given demonstrate that often scrolling and
snapping are physical.
fantasai: That's why we have x and y.
fantasai: But once you have chosen an axis
fantasai: within that axis, whether you're going to the start or
end is a logical dimension
fantasai: so we should use logical coordinates for alignment
within one axis, once you've picked it (regardless of
physical or logical).
Florian: I understand MaRakow's preference, but not its
justification.
myles: What if the start edge of the box and the container are
different sides?
fantasai: No problem, alignment is specified on the child.
TabAtkins: You don't get the mismatch given how it is specified.
MaRakow: A relevant discrepancy is the default axis
MaRakow: of snapping.
[segmentation fault]
MaRakow: Nothing specifies the scroll wheel is in the block
direction.
fantasai: It tends to happen.
TabAtkins: I assume that when in vertical writing modes, there's
an easy way to scroll.
koji: IE does horizontal, webkit/blink do vertical. Horizontal is
better, but not always done.
Myles: WebKit is interested in matching IE.
koji: So will blink.
fantasai: I want to either resolve now, or to know how to proceed.
TabAtkins: WE MUST RESOLVE TODAY IT HAS BEEN A YEAR ARGHHHHHHH
[technical difficulties]
<smfr> vertical-rl scrolling testcase:
http://www.smfr.org/css/scrolling-vertical.html
* smfr notes that mac trackpad scrolling is physical
<MaRakow> it's really inconsistent across the board
<MaRakow> e.g. arrow keys are physical, home/end is logical in edge
* fantasai notes that trackpads are equally competent in both
axes, unlike scroll wheels
[The group split at this point and those interested in Color moved
to another room (see next set of minutes)]
*** Scroll Snap Breakout Session Minutes ***
Scribe: vollick
fanatasai: How do we make progress? We fundamentally disagree.
astearns: One way forward is for MaRakow is to give up. what do
you think, MaRakow?
MaRakow: Against my better judgment?
myles: If the snap points are physical, they don't need to be
recomputed on style change.
myles: Therefore faster.
fastasai: Unless you're changing the writing mode, doesn't really
matter. how often does that happen?
myles: I offer this comment as, hopefully, a way to move forward.
fantasai: I think one way forward is to try and be conformant with
how background-position works.
MaRakow: Would it make more sense to resolve on axis before
alignment behavior?
fantasai: The block axis is usually the one that's scrolling. if
the inline axis is scrollable, it's usually because the
screen is inconveniently small.
MaRakow: I think you're thinking of a document, rather than
something that's 2D snappy, like a tiled view.
fantasai: Stuff grows, overall, in the block axis.
tantek: Like a spreadsheet?
MaRakow: Another example, maybe you have rows of movies to watch
and no snapping preference in the x axis (or columns).
tantek: Like netflix ui.
MaRakow: My point is that those layouts probably don't change in a
writing mode locale.
tantek: Could we look at japanese netflix ui? (looking for a real
work example to guide us).
fantasai: The primary scroll axis should match how the scroll
wheel behaves.
MaRakow: If you think about UIs like a flipper view, they're
commonly horizontal even where block axis is vertical.
Flipping through content is a physical, not logical thing.
fantasai: And a flipper view would explicitly specify.
MaRakow: Yeah, it's possible, but in the majority of cases the
author isn't thinking about the logical orientation, but
the physical arrangement of the content...
MaRakow: Flipper view is something like at the top of many
websites, you can flip left-right through stories.
astearns: We _could_ take a straw pool of those remaining. Would
rather hear people express a preference one way or the
other.
shans: There's no functionality lost through choosing one vs the
other.
fantasai: No, we could specify anything explicitly.
shans: Just trying to summarize. 1) consistency with other css
props and matching text behavior
fantasai: And that scrolling is usually logically...
shans: and a counterargument (albeit obscure) is performance.
shans: And the counterargument is that snapped layouts are usually
physical.
shans: Perhaps we could do a survey of content and find out what's
truly prevalent?
gregwhitworth: Would either party change their minds based on this
study, or would we just be informing folks?
fantasai: I think that there's a combination of logical/physical,
but primarily you're scrolling in the block dimension,
because you've got too much content.
fantasai: The inline scrolling is unintentional because screen is
too small.
fantasai: The physical case, therefore, should be specified
explicitly.
gregwhitworth: I'd posit the reason scroll snap is physical is the
map scenario. The widgets you bring up (usually
completely different than typical scrolling), in
these maps scenarios, scrolling is very physical.
gregwhitworth: It boils down to: do we want consistency in syntax
or behavior?
fantasai: This is the case where you didn't specify an axis. What
will frequently happen is that the author says "I want
snapping" and if we default to 2D snapping, we get
snapping to the wrong stuff if we overflow
unintentionally in the wrong direction.
fantasai: But what tab and I know is that the author may not have
tested thoroughly and didn't anticipate the
unintentional scrolling, and we get weird behavior if we
default to 2d scrolling.
fantasai: So we need the default behavior to be scrolling in 1D
and in the primary direction, because it's most likely
what's intended.
fantasai: Most scroll ports have the primary axis be the block
axis, so we should spec for that.
MaRakow: I want to go back to what shans was saying, I think that
doing a survey of content is a great idea. Seems like
you're focusing on documents, but I don't think it's the
primary use case for this feature
<fantasai> Use cases include photo flippers, but also blog posts,
address books, train schedules, etc.
astearns: We're talking about the default behavior, correct? (yes)
It's not about all the places we use scroll snaps, it's
the cases where the author has chosen the default.
fantasai: We also key off the overflow values. If we have
overflow-x and not overflow-y, we'll do horizontal. It's
only where it's ambiguous where we default to block axis.
fantasai: Yeah, if you have an app-centric view of the world, you
may think that the dimensions are equivalent, but there
are a whole bunch of docs on the web.
MaRakow: Not just apps, but docs, too. flippers, stores often are
docs.
flackr: We're talking about a default behavior, but can we require
this to be specified until we have more data?
MaRakow: Fine by me.
astearns: What does it mean if we punting on?
fantasai: We always specify, and we don't try and guess until later.
astearns: But can we defer this? If we require this, but then
default it later...
MaRakow: I think that this will be a lot easier, because we can
measure the common case.
shans: That might actually be good, if we see people specifying
y-axis and pages break when the writing mode changes, then
that's an argument for logical..
fantasai: Changing axis is very rare.
fantasai: A novel could do this, but not a fancy-layout magazine.
fantasai: The concern I have with going physical, is that our
defaults are often logic and choosing physical here is
incongruous.
MaRakow: I think we have a way forward by avoiding ambiguity.
shans: I have a preference for fantasai's suggestion. how about a
straw poll to check for strong opinions. Failing that, we
go with explicit requirement.
astearns: I would like to use IRC and get folks to say physical or
logical.
<fantasai> 1) logical
<fantasai> 2) physical
Straw Poll:
Rossen 2
Florian 1
MaRakow 2
fantasai 1
shane 1
myles abstain
bradk 1) logical
flackr 1
jensimmons 1
astearns 1
gregwhitworth 2) physical
iank_ abstain
koji 1
vollick abstain
ojan abstain
Tabatkins 1
dauwhe 1
astearns: There's an obvious preference for logical, so we go back
to asking for objections from Microsoft.
MaRakow: I think we have an opportunity to gather more data by
doing what shans suggested, so I propose that we go with
explicit.
astearns: The people that abstained may be expressing a preference
for gathering more data. Both ian's and tantek are in
that camp.
ojan: Abstaining due to lack of informed opinion.
astearns: Alright, given this and that we're likely not going to
get further, let's go with explicit.
shans: Can we go for explicit with the understanding that without
strong data for physical, we go with logical.
fantasai: How are we going to get this data?
fantasai: The info we get from what author's type isn't
trustworthy. e.g. they might inaccurately use margin-top,
because they didn't consider other writing modes.
fantasai: The only way we can truly judge is by looking at use
cases and see what would have ideally been done.
fantasai: I'm ok with this to move forward, though. we can talk
about this later.
fantasai: I just want to point out that it's not as simple to
gather data as "turn on explicit and measure"
RESOLVED: Require (for now) an explicit axis and will gather more
info as we can (to decide between physical and logical
direction).
* fantasai would like to revisit this resolution with the rest of
the WG
astearns: I agree that parsing what people type is not reliable.
* Rossen points out that Matt's examples are from real apps that
already work with our impl
Snap-align and background position
----------------------------------
fantasai: We have the related issue of snap-align
fantasai: My opinion - unless we change background position syntax,
this should work exactly the same way.
<fantasai> https://drafts.csswg.org/css-backgrounds-4/#the-background-position
fantasai: This is the syntax we discussed at TPAC in Sapporo.
fantasai: It can express physical, logical, or combinations.
fantasai: The scroll snap align takes a subset, so should be the
same.
fantasai: If we want to have physical/logical coordinates, we
should use the same syntax.
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Jan/0133.html
fantasai: In lieu of repeating myself a lot, read this ^
fantasai: Either we add a bunch of keywords to be explicit, or we
interpret the same as background position.
MaRakow: ok.
astearns: You're ok with fantasai's proposal?
MaRakow: Yeah, seems to favor logical, but we could add words to
make physical in future. ok.
RESOLVED: Make snap-align behave like a subset of background
position (from fantasai's proposal:
https://lists.w3.org/Archives/Public/www-style/2016Jan/0133.html).
Scoping Valid Snap Positions to Visible Boxes
---------------------------------------------
<fantasai> https://drafts.csswg.org/css-scroll-snap/#snap-scope
fantasai: In the interest of time and minuting, I will paraphrase...
astearns: Alternatively, we could have matt respond and we could
see if we need to discuss.
MaRakow: I haven't looked at these as closely
MaRakow: but can go into detail on what I've read in detail. The
issue I have with visible boxes
MaRakow: could give wiggling while scrolling or snap points
outside scroller.
MaRakow: With this specification, there could be a great
candidate, that happened to be out of scroll at the
beginning, so we wouldn't consider it.
MaRakow: Problem, basically, is that you need to make a decision
where you're going to scroll.
MaRakow: During scroll is crummy, but at the beginning causes you
to ignore good candidates.
fantasai: The goal of this section is to avoid snapping to
something that is way off to the side, out side the
scroller, but not in the direction you're scrolling.
MaRakow: Yeah, I get the scenario you're considering (and agree it
needs to be addressed), but not sure what prose to suggest.
fantasai: We could replace the text of this section with an issue
that describes the problem.
MaRakow: I think that if such prose exists, would love to look at
it, but don't know if any algorithm exists that could
address the issue.
fantasai: Do you have other concerns about this section that we
should address if we were to try to come up with better
prose.
Snapping Boxes that Overflow the Scrollport
-------------------------------------------
<fantasai> https://drafts.csswg.org/css-scroll-snap/#snap-overflow
fantasai: The next section is snap points that overflow the
scrollbox.
MaRakow: Doesn't account for more than one element that overflows
the viewport...
fantasai: <quotes some of the prose>
<fantasai> “and there are no other snap areas within the snapport
that would provide a snap position aligning the
overflowing snap area within the snapport,”
<fantasai> “then any scroll position in which the snap area covers
the snapport is a valid snap position in that axis”
MaRakow: In general this has issues with multiple elements in the
viewport.
fantasai: I don't get it.
MaRakow: Say we have two huge elements, and a tiny view port. When
you scroll out of one and another huge element appears,
the only valid snap points will be the centers.
MaRakow: So, at the time that you've panned into the 2nd element,
then your 2nd condition doesn't pass anymore. You don't
necessarily snap then, but the list of snap points only
includes the centers.
astearns: So the text doesn't cover that case.
fantasai: I don't understand why, but we can talk offline. do you
have a problem with this, or just need better prose?
MaRakow: Same as before. need better prose, but not sure if such
prose exists.
astearns: fantasai and tab have reasons for adding these sections
once we have prose, and I would like the reasons stated
explicitly.
fantasai: Go back to giant photo requires center alignment
(expected bigger screen).
astearns: You want to get away from the center
fantasai: Yeah, you want to be able escape, but the author hasn't
let you.
astearns: Do you agree that we at least need a note for this?
MaRakow: Yeah, but I thought we had one. .. looks like it got
dropped. We talked about this in January.
fantasai: It's an interesting point. although the prose isn't
ideal, I think it's better to have this than not, and
just fix the section.
fantasai: Might be awkward as specified, but leaves content
inaccessible, if we don't address this.
MaRakow: Problem is that this text doesn't solve the problem in
many cases.
astearns: At least gets you to the edge.
MaRakow: Maybe if it's a single element that's really large.
<fantasai> If you remove “and there are no other snap areas within
the snapport that would provide a snap position
aligning the overflowing snap area within the
snapport”, which probably needs some tweaking,
<fantasai> Then having this section solves the accessibility
problem
<fantasai> And behavior could be improved on top of that.
astearns: So, I think I agree with fantasai that we should have
this section because it's a problem we need to solve. I
don't mind if it's just an issue describing the problem.
MaRakow: I am ok with describing the problem. I don't want
unimplementable prose.
fantasai: It at least solves 100% of the accessibility problem,
but we can refine the snapping behavior.
fantasai: It might not do enough snapping, but removes barriers
from content.
MaRakow: I'm fine with adding an issue. I don't think this text is
going in the right direction.
MaRakow: I remember you suggesting a disjointed set of points...
did that go anywhere?
fantasai: We started with that, but ended with this prose.
MaRakow: I agree this is an important problem.
fantasai: I would prefer to add prose with an issue, rather than
just issue.
MaRakow: I'm not convinced this is going in the right direction,
but am interested in the disjoint set.
shans: Having something that can be critiqued is better than
nothing. and preferable to throwing up our hands and saying
"dunno". I think we should add this and matt should add
specific issues.
MaRakow: I would like to add a note saying "don't implement this
now."
astearns: I propose we add section with issues detailing the
problem.
astearns: Objections?
RESOLVED: We add the section 6.2.2 (Snapping Boxes that Overflow
the Scrollport) and add issues.
Scoping Valid Snap Positions to Visible Boxes (revisited)
---------------------------------------------------------
fantasai: Can we do this for the previous section?
MaRakow: The other one is not just bad prose, it's not
implementable.
<fantasai draws on the whiteboard>
<It is a scroller with a snap candidate off to the side>
myles: If they intersect the viewport by 1px, still stinks to snap
to them.
fantasai: happy to make it fuzzier, but when? up to the ua?
myles: should leave it up to the ua
MaRakow: this is why we went with point based.
myles: I don't think something like a raw intersection test would
give us the best experience
MaRakow: agreed.
astearns: You agree we should have this section, but the wording
is MUCH more up in the air because we can't agree on the
criteria.
myles: different UAs could disagree with what's in and out
MaRakow: scrolling is intended to bring out of view content into
view; ignoring out-of-view content is against the spirit
of the thing.
fantasai: Want to clarify that we _can_ snap to that stuff as long
as it's actually visible when we've snapped.
astearns: Agreement that it's something we should have but don't
have the right wording. my proposal is to add a section
with just an issue.
<MaRakow> +1 astearns
astearns: objections?
fantasai: I think we should add section with issues.
astearns: I disagree. In this case I think the wording is going to
be completely different.
fantasai: can't work on diff forever
astearns: let's work on the issue.
RESOLVED: Add section with just the issue.
Unreachable Snap Areas
----------------------
<fantasai> https://drafts.csswg.org/css-scroll-snap/#unreachable
fantasai: I want to center an image in the screen.
fantasai: The image is at bottom right of scrollable area.
fantasai: Its small
fantasai: (so i can't center it).
fantasai: So, the used snap position means you should just scroll
as far as possible.
fantasai: So you still snap "there" but it's not really "there".
<MaRakow> No objection on this one.
RESOLVED: Add section 6.2.3
Scroll-snap-stop
----------------
<fantasai> https://drafts.csswg.org/css-scroll-snap/#scroll-snap-stop
fantasai: scroll-snap-stop
fantasai: We discussed the difference between when you flick, you
scroll until you run out of inertia
fantasai: then you determine where to snap.
fantasai: The other behavior is when you stop at the next snap
position, always
fantasai: "infinite sinkhole" effect.
fantasai: Microsoft's API has a matrix of proximity vs mandatory.
fantasai: Sometimes you want to only snap by one "stop" and you
might want to cross the next "stop".
fantasai: Florian's use case: you have snap positions at every
heading, but every article has a mandatory snap.
myles: Does this interact with 2d snapping?
myles: You shouldn't be able to only go one stop when 2d snapping
isn't enabled.
fantasai: You could say that you just go in one direction to choose.
gregwhitworth: (to myles): do you think that this should only work
1 dimensionally or do you think this shouldn't be
merged.
myles: A note or an issue is fine.
MaRakow: "Normal" is non-descriptive
MaRakow: Let's use "multiple" or something else.
fantasai: If we decided to make this work for mandatory, it'd be
the snap position that you'd choose if you had very slow
speed and no friction.
gregwhitworth: Is it ok to merge if we note to bikeshed the normal
keyword and define inertial scroll?
MaRakow: I think so.
MaRakow: There are issues with inertial scroll.
astearns: Objections?
RESOLVED: Merge section 6.3 with 2 issues
Choosing Snap Positions
-----------------------
<fantasai> https://drafts.csswg.org/css-scroll-snap/#choosing
fantasai: Choosing snap positions
fantasai: We have 2 concepts: we have 1) valid snap positions, and
2) the chosen position
fantasai: The UA determines #2.
fantasai: Don't lock down #2.
fantasai: Locking down #1 is good though.
fantasai: Guidance for #2 is valuable for a spec to have.
fantasai: Expository writing shows some guidelines.
fantasai: We also have bullet points.]
<fantasai> “Snap positions should be chosen to minimize the
distance between the end-point (or the natural
end-point) and the final snapped scroll position,
subject to the additional constraints listed in this
section.”
<fantasai> “Point-snapping is all-or-nothing; if the snap position
of an element is chosen to align to, the scroll
container must set its scroll position according to the
element’s snap positions in both axises; the scroll
container must not “partially align” to the element by
taking its snap position in one axis and aligning the
other axis according to something else.”
fantasai: Let's come back to this.
fantasai: Clarification of point snapping: you can't snap to the
x-axis of a point w/r/t point snapping when snapping to
the y-axis of another point.
fantasai: This is uncontroversial.
MaRakow: Normative or recommendation?
fantasai: Normative (but you have leeway)
fantasai: We have some "should"s or "may"s.
fantasai: next! "axis locking"
<fantasai> “If a scroll is axis-locked and the scroll container is
axis-snapping, any snap positions in the other axis
should be ignored during the scroll. (However, snap
positions in the other axis can still effect the final
scroll position.)
<fantasai> If a scroll is axis-locked and the scroll container is
point-snapping, snap positions should be penalized in
the selection process according to the amount of other-
axis scrolling they would cause.”
<fantasai> “Additionally, because page layouts usually align
things vertically and/or horizontally, UAs sometimes
axis-lock a scroll when its direction is sufficiently
vertical or horizontal. An axis-locked scroll is bound
to only scroll along that axis. This prevents, for
example, a nearly horizontal fling gesture from
gradually drifting up or down as well, because it is
very difficult to fling in a precisely horizontal line.”
fantasai: ^^^^ this is how axis-locking is defined
fantasai: It means "if we are scrolling close to vertical, we may
disregard horizontal scrolling" this rule means that if
you're doing this locking, you don't snap in the
opposite direction.
fantasai: If you have two snap positions you're choosing, and they
are otherwise equivalent, it's not specified how you
choose a point, but you should penalize the point in the
orthogonal direction to the axis locking
<MaRakow> points aligned with the axis of scrolling should be
preferred over points off-axis
astearns: It is ambiguous. we don't know if you should penalize
depending on how far we are trying to scroll.
gregwhitworth: We don't need to define everything now, we need to
determine what needs to be addressed to get the
specs merged in, not define right now. let's get
through this stuff!!
astearns: We need to determine what needs to be an issue.
gregwhitworth: Let's not define ambiguity.
gregwhitworth: myles summarizes a lot
MaRakow: "axis locking" the reader needs to know what this is.
It's not well defined.
fantasai: It was defined earlier.
MaRakow: It depends on the reader to already know what is up.
MaRakow: Maybe this needs to be defined better.
fantasai: No. It means "here's a thing that UAs do, and we are
assigning it a name so we can refer to it"
fantasai: We aren't defining exactly what it does.
fantasai: It is normative, but it's not a directive.
MaRakow: Everything here says "should" right
fantasai: Correct. Next!
<fantasai> “ Snap positions should be ignored if their elements
are far outside of the “corridor” that the snapport
defines as it moves through the scrollable area during
an inertial scroll, or a hypothetical “corridor” in the
direction of a directional scroll, or the snapport
after an explicit scroll. (This is to prevent a far-
offscreen element from having difficult-to-understand
effects on the scroll position.)”
fantasai: If you're scrolling in a direction, you probably want to
ignore things that are in another direction.
fantasai: You should ignore elements that are far away in an
orthogonal direction.
fantasai: This is so the user doesn't scroll way off in the weeds.
fantasai: This is about choosing snap positions, not about what is
a valid snap position.
fantasai: The other section is about valid snap positions.
myles: One is a filter, the other is scoring.
fantasai: It's not a filter.
fantasai: You can't snap to an element which is super far away.
fantasai: The other one is saying that, among the valid snap
points, you should prefer ones which are in the
direction of scrolling.
fantasai: The user intent is to go in one direction, try not to
pull the user in an orthogonal direction.
MaRakow: Can we focus on the parenthetical "UAs should avoid
difficult-to-understand scrolling behaviors"?
astearns: Let's talk about "scroll vectors"
astearns: How about "don't change the 'scroll vector' by a large
amount"'
MaRakow: Scroll vector & corridor are bad, because you may scroll
in multiple directions (when you hit the edge of a page).
MaRakow: Let's say "don't let far away elements affect snap points".
MaRakow: This is easy to interpret.
MaRakow: It doesn't have to delve into crazy edge cases.
fantasai: It helps to clarify the specific cases
fantasai: Obviously we don't want bad user experiences
MaRakow: Let's just lead with the parenthetical.
astearns: Let's do it.
RESOLVED: Merge it with the parenthetical first.
<fantasai> “User agents must ensure that a user can “escape” a
snap position, regardless of the scroll method. For
example, ...”
fantasai: if the next mandatory snap position is super far away,
normal flings won't take you that far ordinarily
fantasai: but the UA should not trap you
astearns: Maybe it's a use case to let strong people win prizes
for hard flinging.
MaRakow: I'm imagining a use case and it is like a carnival game
MaRakow: Sounds good to me.
RESOLVED: merge that puppy
<fantasai> “If a page is navigated to a fragment that defines a
target element (one that would be matched by :target),
and that element defines some snap positions, the user
agent should snap to one of that element’s snap
positions. The user agent may do this even when the
scroll container has scroll-snap-type: none.”
fantasai: If you are navigating to an element which has been
targeted, don't put the element to the top of the
viewport. Instead, you should snap to that element if it
has a snap position. Even if an element has a snap
position, you may want to use the snap area as a
guideline for how to move it into view.
MaRakow: How does this work when you have scroll-snap-type: none
MaRakow: This allows you to have scroll snap points but they are
disabled.
fantasai: This doesn't interfere with scrolling, but if you want
to see the box, and the box has a preference for how
it's being seen, then let's honor it.
fantasai: It's better than the UA default.
MaRakow: Wouldn't it have a scroll-snap-type then?
fantasai: The scroll snap on the scroller is about snapping
behavior (vs smoothly scrolling).
fantasai: Here, let's move it into view using these settings.
fantasai: This is more refined than the course UA.
fantasai: We have the technology!
MaRakow: I understand, but fragment navigation gets a special case
for ignoring scroll-snap-type? This is an outlier.
MaRakow: Most UAs have the same machinery for scrolling, so
special casing is bad.
fantasai: Currently it's undefined how scrolling to an element is
defined
fantasai: because it's undefined, it makes sense to prefer to use
these things.
astearns: This makes sense.
astearns: I like this one except for the last sentence.
MaRakow: Same.
astearns: It's a "may".
fantasai: It's better if we do this.
fantasai: If you're going to a heading, you might want to say
"let's show the decoration around the heading".
fantasai: We've given control to the author about the breathing
space around an element. Authors have given us the info.
fantasai: Browsers can use it, but they don't have to (but it's
better if they do).
astearns: If the author is concerned, though....
fantasai: Then they would turn off snapping.
fantasai: The user wants the decorations around their elements.
astearns: This is weird and backdoor.
fantasai: We could add this as other properties if you prefer
a completely identical but independent set of properties...
astearns: Any other opinions?
bradk: fantasai makes sense.
bradk: We should do this for scrollTo and scrollIntoView() as well.
fantasai: This should occur any time we want to go to an element.
MaRakow: No objections.
RESOLVED: take section 7.3 with 2 issues
Types of Scrolling Methods
--------------------------
<fantasai> https://drafts.csswg.org/css-scroll-snap/#scroll-types
fantasai: Next: types of scrolling methods.
fantasai: Let's describe how scrolling works.
fantasai: We have a list of scrolling methods.
fantasai: We want to define the model of how snapping works.
fantasai: So we have a category of scrolling operations.
fantasai: Based on 1) if they have an intended end position and/or
2) if they have an intended direction.
fantasai: This is used to explain behavior that is in the rest of
the prose.
fantasai: The issue should be removed.
<fantasai> (Tab did the rewrite already; I'll remove it)
fantasai: It should be removed because it is already done.
MaRakow: Some might be controversial:
MaRakow: - categorization
MaRakow: Mouse wheel scroll should be classified as directional,
not inertial in our UA.
MaRakow: Fling gesture depends on UA a lot.
MaRakow: A kindle web browser has no inertia.
MaRakow: So that's more of a directional scroll.
fantasai: 'kay.
MaRakow: The definition is better split if you talk about
scrolling operations which are instantaneous vs play out
over a duration.
MaRakow: This separates the first two categories.
MaRakow: Directional scrolling makes sense.
MaRakow: A new category of active scrolls.
MaRakow: This is a scroll which is driven by a user over a duration.
[At this point the people from the Color breakout rejoined the room]
*** End Breakout Session Minutes ***
MaRakow: "explicit" and "inertial" is controversial as what is
categorized in each.
MaRakow: My suggestion: there is a different way of dividing
categories
MaRakow: which avoids confusion.
MaRakow: Let's say "instantaneous" vs "play out over a duration"
MaRakow: and "scrolls that are active over a duration"].
MaRakow: Like "if there is continuous input or not"
MaRakow: Directional makes sense, but it might need to be
reconsidered.
<fantasai> TabAtkins, the fling gesture without inertia is e.g. in
in an ebook reader, sometimes it's more like PageDown
or DownArrow than like smartphone flings.
TabAtkins: multi-interaction scrolling isn't a single interaction.
MaRakow: When you do the selection of a snap point, this depends
on one point in time - either when a driven scroll ends,
when an inertial phase begins, etc.
MaRakow: The timing is interesting and has to do with phase
transitions between active driving, inertia phase, and,
for instantaneous, the instant and the play out of the
inertia.
TabAtkins: What's wrong with the current categorization?
MaRakow: If you had a description of "active driven scrolling"
then you could say that the time we select a point is
when the driving of the scroll is completed.
MaRakow: This uses the "active scroll" definition.
TabAtkins: What is a "driven scroll"?
MaRakow: During a drag (touchpad gesture) or dragging the
scrollbar thumb.
MaRakow: During this, you don't want the page to be jumping.
MaRakow: So don't do this during the active scroll.
TabAtkins: We already define this during the spec.
TabAtkins: Don't snap until the scroll is "basically done".
TabAtkins: We snap "At the termination of a scroll"
TabAtkins: So, while the user has their finger down, it's already
defined that you don't snap then.
TabAtkins: 3 categories: intended endpoint, intended direction, or
both.
MaRakow: In general, you want to define the time period clearly.
MaRakow: active scroll operation: is okay there.
MaRakow: But we don't know the period over which the animation
plays out.
MaRakow: We have these input types in the section, but they might
fall into different buckets based on the UA.
TabAtkins: Prove it.
MaRakow: The fling gesture. If you're on a non-animating user
agent (kindle) doesn't have inertia.
TabAtkins: The way that your scrolling method works is that you
don't have an intended end position.
TabAtkins: The UA can interpret gestures differently.
TabAtkins: After the interpretation, you always end up with one of
the three buckets.
MaRakow: You don't have to worry about it.
MaRakow: Instead of saying that particular gesture ties to an
inertial scroll which ties to these other behaviors, you
can say the user did something and the result is either
an directional scroll, or an instantaneous scroll delta I
don't know.
MaRakow: No matter how they get into the situation, the behavior
is defined.
TabAtkins: We agree in semantics but not names.
MaRakow: Nope.
TabAtkins: How so
MaRakow: Mouse wheel, fling gesture, scrollto are different.
MaRakow: scrollbar/scrollto don't talk about inertia.
MaRakow: scrollto and scrollbar don't talk about whether they
should or not have an inertia phase.
TabAtkins: Because inertia isn't part of the definition.
TabAtkins: scrollby has a direction and direction.
TabAtkins: scrollto just has a postion.
TabAtkins: So the definitions fall out.
(general confusion)
TabAtkins: [clarifies point made above]
Florian: I have a 4th one!
Florian: "implicit scrolling"
Florian: This is where the user gave nothing. For example, the
user focused a button.
TabAtkins: This is the same as a scroll destination alone.
Florian: The conversion between what the user did and what the UA
did may what to take scroll-snap stuff into account.
TabAtkins: How is it not currently taken account.
TabAtkins: How do you want it to change.
TabAtkins: You can click a #link to focus something, and you will
snap there (as if you called scrollTo()).
astearns: MaRakow had a point that you're making these definitions
but you don't use them.
astearns: The other terms are not used.
astearns: Please describe why we need this section.
TabAtkins: They are used!
TabAtkins: Terms are just for general background.
TabAtkins: We have several bits about if there is a direction or
position.
astearns: We define categories "inertial" "directional" but we
don't use them.
astearns: We don't use the categories themselves.
TabAtkins: It just describes the types of things which has only a
destination, and has only a direction, and both.
astearns: For MaRakow, some of these things are miscategorized.
MaRakow: Yup.
MaRakow: astearns got it right. the interesting points are not the
category headings, instead they are the names you
reference many times.
MaRakow: Let's rename the headers to be the interesting bits.
TabAtkins: If you just want to prefer more on the actual
definition (these two qualities) then that's cool.
MaRakow: Let's go further and define at what point in time you
select a snap points.
MaRakow: Now it's not defined.
TabAtkins: The answer is "when the scroll operation is done and no
more active scrolling happens"
MaRakow: Let's define "active scroll operation"
TabAtkins: 'kay
TabAtkins: If you think it's possible.
TabAtkins: We are not disagreeing with notions.
MaRakow: Yep.
MaRakow: We don't need to dive into input types.
TabAtkins: ???
MaRakow: We have some categories, but different UAs disagree on
what goes into each category.
Florian: Some UAs may consider a fling in one or the other category.
Florian: We agree on, regardless the UA determined the
destination, it then has a destination.
Florian: If it has a destination and a direction, then it has a
destination and a direction.
Florian: It's not interesting how we get to these states.
TabAtkins: The ebook fling gives you a direction but no position
(or magnitude).
MaRakow: Let's move away from categorizing that fling gesture must
be an inertial scroll.
fantasai: Let's just use an example block to make it clear they're
examples.
MaRakow: These may be classified differently, and that's okay.
TabAtkins: We don't define how different user interactions are
classified on.
TabAtkins: Fling is different on a phone vs a kindle.
TabAtkins: These should be examples.
TabAtkins: We need another directional example to talk about swipes.
TabAtkins: The three categories are not wrong.
* fantasai notes that the fling gesture described is explicitly a
kind that is interpreted with momentum; the ebook swipe
doesn't fit this description
MaRakow: They are not useful.
TabAtkins: So I should just swap the first sentence into the DT
TabAtkins: and remove the "explicit" "inertial" and "directional".
TabAtkins: People incorrectly assign meaning to them so let's
remove them.
MaRakow: 'kay
astearns: Proposed resolution: add section 7.1 in the spec with
these minor changes ^^^^
astearns: & add a more precise definition of when an active
scrolling operation is done so we know when to start
snapping.
MaRakow: That depends on my text.
MaRakow: That is how we implement it.
astearns: Any objections?
<silence>
RESOLVED: Add section 7.1 after removing "explicit" "inertial" and
"directional" definitions, moving the first sentence and
adding a more precise definition of when an active
scrolling operation is done so we know when to start
snapping.
fantasai: Let's do 7.0 too
MaRakow: We need to update terms too.
TabAtkins: yeah.
fantasai: 7.0 is general background knowledge.
RESOLVED: Merge 7.0 too
fantasai: We are done.
fantasai: No we're not.
fantasai: "default axis" issue revisit. This was our strawpoll
earlier.
Rossen: We were following on IRC so the previous resolutions are
cool.
fantasai: But there were other people who did not vote!
astearns: There was a resolution to require an axis and not have a
default behavior (for now).
astearns: We can relax it later based on usage.
astearns: Let's not open it up.
TabAtkins: I don't have an objection.
astearns: Should we add fantasai and TabAtkins as editors of the
spec to grease the wheels of the merges?
astearns: What do you think MaRakow?
MaRakow: 👍
RESOLVED: add fantasai and TabAtkins as editors to scroll snapping
Scribe: fantasai
astearns: Did a merge discussion of scroll snap. Mostly merged,
added some issues.
TabAtkins: Did we discuss short name?
fantasai: MaRakow merged in the title change.
fantasai: I guess shortname should follow.
tantek: What's the proposal?
<MaRakow> yeah go go shortname
TabAtkins: css-scroll-snap
RESOLVED: css-snappoints -> css-scroll-snap
Received on Tuesday, 7 June 2016 18:26:24 UTC