- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 23 Nov 2015 20:15:37 -0500
- To: www-style@w3.org
Fragmentation
-------------
- RESOLVED: No change on issue 24.
Scroll Snapping Issues
----------------------
- RESOLVED: Issue 54 is closed with no change (the original
request was retracted).
- RESLOVED: Defer scroll jumping / "discrete snapping" feature to
level 2.
- There was tentative agreement to create a property to allow
control over if inertial scrolls can go past snap points.
- Tentatively it is called scroll-snap-stop and takes the
values 'always' and 'auto' (all names pending bikeshedding)
- There was a desire to see a written proposal before a final
resolution is passed.
- RESOLVED: If no snap positions defined, no snapping happens;
scroll freely.
- RESOLVED: 'overflow: auto | scroll' captures snap positions in
both axes, regardless of scroll-snap-type value.
- RESOLVED: scroll-snap-type applies to all elements, non-none
values trap snap positions of descendants.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2015#agenda
Scribe: dauwhe
Fragmentation
=============
astearns: Fragmentation was scheduled in the morning.
fantasai: There was an issue raised by hober.
dino: Can you link to that point?
<Rossen> https://drafts.csswg.org/css-break/issues-lc-2015#issue-24
fantasai: Issue 24
fantasai: hober can't remember; he denies it happened.
<fantasai> "hober: I liked the compound names with force."
astearns: hober liked the names with force-
Florian: That's my understanding.
dino: I don't think this is worth ... . he didn't raise an
objection.
fantasai: The question is, we have break-before which has values
column, page, region, auto
<fantasai> break-before: auto | page | column | avoid-page |
avoid-column
fantasai: We have avoid-page.
fantasai: It's a bit unclear what break-before: page means, it
means a page break before the element.
<fantasai> break-before: page
<fantasai> break-before: force-page
fantasai: Maybe having force- is clearer.
dino: I don't think hober feels strongly.
Rossen: I like shorter.
astearns: I prefer shorter.
RESLOVED: No change on issue 24.
fantasai: We need a transition request.
Rossen: We have two staff contacts in room.
fantasai: Transition request for fragmentation to CR,
Rossen: Chris, you'll do this?
astearns: Do we have tests?
Rossen: Some.
Rossen: More would be better.
astearns: It's nice to have a test for every section, just one,
when we make transition to CR
Rossen: I think that's the case.
astearns: It's nice to have slight coverage.
Rossen: That's all on fragmentation.
Rossen: we've exhausted the morning session items.
Rossen: It's fourteen minutes before noon.
Rossen: Any quick topics?
fantasai: Some short scroll snapping.
Scroll Snapping Issues
======================
<astearns> https://drafts.csswg.org/css-scroll-snap/issues-by-issue
fantasai: Let me find an issue that is not long.
dino: We were up to 28.
dino: 28 is simple.
fantasai: We planned to defer 28.
fantasai: I haven't updated it.
dino: We talked about 28.
Have the children determine the scroll snapping behavior (Issue 54)
-------------------------------------------------------------------
fantasai: We should do 54.
<fantasai> https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-54
fantasai: It's to determine whether mandatory or proximity per
element rather than per scroll container.
fantasai: So the question is we don't know how this works.
fantasai: Should we investigate or close as no change?
Rossen: That's the model where half elements mandatory, half
proximity?
TabAtkins: It's mandatory, but some don't have wide attraction
radius.
TabAtkins: That's dumb.
astearns: One with very large radius.
TabAtkins: Don't put in author's control.
Rossen: This is something we can push to level 2.
fantasai: It was raised by Florian.
Florian: I disagree with old Florian.
fantasai: Closed as no change.
RESOLVED: mandatory/proximity determined by container, not child
Add scroll jumping / "discrete snapping" feature (Issue 60)
-----------------------------------------------------------
fantasai: Next is issue 60.
fantasai: Scroll jumping / "discreet snapping" spreadsheet thing.
TabAtkins: Some spreadsheets scroll only by whole rows.
TabAtkins: I'm ok with deferring,
TabAtkins: unless the working group thinks this is crucial.
Steve: How do you make cut for level 1?
TabAtkins: The simplest possible thing that robustly solves
interesting cases.
Rossen: Let's record a resolution.
RESLOVED: Defer scroll jumping / "discrete snapping" feature to
level 2.
Specify whether inertia can skip snap positions (Issue 64)
----------------------------------------------------------
<fantasai> Discussing
https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-64
fantasai: Can inertial scrolls skip snap positions?
fantasai: Microsoft has a distinction between single and multiple
mandatory.
TabAtkins: The initial windows version had mandatory and
proximity, and a separate axis, single and multiple.
TabAtkins: Single meant that inertia captured next point.
TabAtkins: Safari is mandatory multiple.
TabAtkins: Microsoft is mandatory single (???)
MaRakow: The biggest problem with single is home and end keys.
MaRakow: Those should go directly to the start and end.
MaRakow: That's a too-strict interpretation of mandatory.
MaRakow: There's no distinction in Windows implementations.
TabAtkins: What should we default on?
TabAtkins: If we need both, what behavior is mandatory, and what
call the other.
Florian: Both makes sense.
Florian: Suppose I have a set of articles on one page, and I want
to go to the next one. I don't want to force to always be
on a snap position, but also I can't calibrate my fling,
so I just want the next one.
<fantasai> [Florian was talking about proximity single]
TabAtkins: It's a separate axis.
Florian: Multiple and single doesn't sound great.
fantasai: "This scroll point captures all inertia" might make
sense by element.
fantasai: For example, in Florian's case, you might want snap
positions within the article, don't want those to trap
all inertia,
fantasai: but want the snap points between articles to trap all
inertia.
dino: I don't think that use case is valid.
TabAtkins: Articles arranged vertically.
dino: I still think navigation to next one; it's hard to
distinguish between scrolling and swiping.
MaRakow: There's a lot of nuance.
MaRakow: There's two ways of describing single:
MaRakow: at least one vs no more than one.
MaRakow: Make single gesture, article is very long,
MaRakow: there's 2 ways of interpreting.
Florian: It's not incompatible with what you say.
Florian: If you have recognized gesture that does that; there's no
detection on my mouse wheel,
MaRakow: We're trying to define default action for certain inputs.
MaRakow: No spec says arrow down should doing something specific.
TabAtkins: We're just sorting out your two behaviors.
MaRakow: There's some potential leniency here.
<Florian> scroll-snap-stop: always | inertial
TabAtkins: Which behavior should we default to?
MaRakow: Leave it up to UA.
TabAtkins: Single vs Multiple changes behavior a lot.
TabAtkins: Does a fling go really far, or to next page?
TabAtkins: That's too different for it to be UA default.
MaRakow: UA could have a smart default.
TabAtkins: The two interpretations are not equally good
MaRakow: It can vary on whether UA has animation support, etc.
TabAtkins: None of them do.
TabAtkins: You have an amount of inertia.
TabAtkins: The amount of inertia calculated is a minor detail for
users.
MaRakow: There's some that will accelerate based on number of
gestures, etc.
MaRakow: Lots of UA-specific inputs that don't exist in all UAs.
TabAtkins: The fling gesture is universal.
TabAtkins: It gives you same basic behavior across all devices.
TabAtkins: Single vs multiple are distinct are distinct and
separate behaviors that authors will either want or not
want.
<fantasai> single = inertia cannot take you past one snap position
<fantasai> multiple = inertia, however it's calculated, can take
you past one snap position; you go until the nearest
snap position to your landing position
Florian: There's a bigger variation on author use cases.
Florian: In a slide show you mean go to next slide no matter how
hard.
Florian: In a carousel a big fling should go farther.
Florian: We need to know if inertial fling means go to next thing
or go far.
TabAtkins: Nothing else in spec allows such a gulf in behavior.
<Florian> scroll-snap-stop: always | inertial
Florian: I just pasting into IRC a proposed name.
fantasai: Given that you might want different behavior per snap
point in same scroller, either way we're going to have a
separate switch because it's on item instead of behavior.
fantasai: Both proximity and mandatory can have single behavior.
fantasai: The default for proximity and mandatory is to allow for
multiple.
fantasai: We can consider adding a switch for single for element
inside of scroll container.
Florian: The property would apply to element not container.
fantasai: Call it auto;
fantasai: it means multiple.
fantasai: From author perspective these are all methods of
scrolling.
Florian: You and I are bikeshedding.
MaRakow: Do you have proposal?
TabAtkins: Florian's scroll-snap-stop, naming tbd
TabAtkins: It can be deferred to next level, keep multiple (Safari
behavior) for L1.
dino: I'm happy with the default Safari behavior.
dino: I think there is a case for full screen don't use inertia.
dino: So I would prefer not to defer.
TabAtkins: Happy to do that.
TabAtkins: For majority use case we don't need it.
Florian: It belongs in level 1.
fantasai: Proximity is multiple for sure.
fantasai: That's least intrusive for users.
fantasai: Given that, multiple has to be the default.
Florian: I still want switch in level 1.
MaRakow: I want to see a proposal.
TabAtkins: I'll write up what Florian posted.
TabAtkins: We can resolve on default the behavior.
Florian: That's what they want a written proposal for.
Rossen: The proposed resolution as is, multiple always for both
proximity and mandatory
fantasai: Looking to adding a switch.
TabAtkins: Proximity doesn't force you to land,
TabAtkins: you can scroll around.
fantasai: (drawing at white board)
proximity: ____ _____
/ \/ \ multiple
____ _____
/ \ / \ single
| || <-- infinite hole, like when you miss a jump in Mario
mandatory:
(same drawing, except flat-top sections are curved
downwards ◠◠◠◠ )
Florian: In proximity you can stop anywhere,
Florian: but you cannot scroll past on an inertial fling,
Florian: a fling will stop you.
MaRakow: I have no trouble understanding.
MaRakow: What does it mean for compat, etc. There's more thought
needed there.
TabAtkins: compat-wise it won't matter as you are prefixed/flagged.
TabAtkins: behavior-wise, definitions are already in API guide.
Rossen: Let's move on.
dino: Lunch line is an issue.
Rossen: Lunch break.
Rossen: Given Matt wants a week, we have a proposed resolution in
a week.
fantasai: There's two more short issues; after lunch.
Rossen: 3pm we have joint meeting.
astearns: We'll resume after joint meeting.
<jchiba> https://www.dropbox.com/s/g3fwj38z8kagx01/snap-point-multiple.jpg?dl=0
<break type=lunch>
Scribe: fantasai
Define what happens when there's no snap points (Issue 69)
----------------------------------------------------------
<fantasai> https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-69
fantasai: Define what happens when there's no snap points.
fantasai: Do you snap to something, or don't snap or what?
fantasai: Tab and I figured if there's no snap positions defined,
scroll freely.
fantasai: If there isn't, you don't snap to anything.
<MaRakow> If a valid, reachable snap point exists, you must snap
to it (for mandatory)
RESOLVED: If no snap positions defined, no snapping happens;
scroll freely.
Define that snap point defined by element is triggered when targeting
fragment of element (Issue 72)
---------------------------------------------------------------------
<fantasai> https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-72
fantasai: [summarizes]
MaRakow: This is way outside scenarios that I've ever looked at.
MaRakow: I'm happy to go to with simpler one.
Rossen: Yeah, seems to agree with what I remember.
RESOLVED: 'overflow: auto | scroll' captures snap positions in
both axes, regardless of scroll-snap-type value.
Trapping Snap Points (Issue 82)
-------------------------------
<fantasai> https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-82
fantasai: Someone mentioned that it would be nice to trap
descendant snap points even if not a scroller.
fantasai: The original suggestion was to use snap-points-x/y lack
of elements value.
fantasai: Tab and I thought that's weird, snap-points-x/y are
about coordinates.
fantasai: But scroll-snap-type is about processing descendant snap
positions, so thought that a non-none value, or perhaps
a special "trap" value, would apply to all elements and
capture snap positions inside.
MaRakow: So snap positions are associated to nearest ancestor with
overflow: scroll | auto or scroll-snap-type: non-none
MaRakow: That seems reasonable.
fantasai: Variations on proposal is, non-none values, or do we
want a special keyword.
MaRakow: I would prefer non-none
fantasai: Seem reasonable to others?
<astearns> ...general head-nodding...
Rossen: Yeah, similar to how position traps things.
RESOLVED: scroll-snap-type applies to all elements, non-none
values trap snap positions of descendants.
Received on Tuesday, 24 November 2015 01:16:38 UTC