- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 11 Sep 2015 14:33:52 -0400
- To: www-style@w3.org
Animations
----------
- The group agreed that the work on exposing the Animations APIs
should move from a delta spec to a real spec, but felt that
the edits to Animations level 1 should be made first,
especially as it would make backporting easier.
- RESOLVED: Add birtles as editor to Animations pending him
getting added to the working group
Scroll Snapping
---------------
- fantasai and TabAtkins brought their proposal to re-think how
the scroll-snap property works, especially in addressing what
they do with oversized elements.
- The proposal was that whenever you snap to an element and
it's larger than the viewport in some axis, in the
overflowing axis you then stop snapping to that element
from now on and instead the edges become the new snap
points.
- This would also move the model of snap points from
a point to point snap toward a box to box snap to
accommodate more robust behavior.
- There were questions about the functionality of snapping to
an edge in regards to it causing problems for those using
arrow keys when the edge is very close to the viewport,
such as 1px away.
- Several people indicated that they wanted to ensure the
wording on this was loose enough that the UIs could do
something smart.
- There were several questions about the value and functionality
of grouping and it was expressed that this was likely a level
2 behavior.
- The renaming proposal of changing scroll-snap-destination to
target had people on both sides of the fence, but ultimately
will remain named as-is.
- MaRakow, fantasai, and TabAtkins decided they would discuss
further and come back to the group with a list of needed
resolutions now that the broad re-thinking had been explained.
Originally this was to happen after the lunch break, but the
group needed more time.
===== FULL MINUTES BELOW ======
scribe: dael
Animations
==========
plinss: Let's get started.
birtles: The topic is CSS Animations level 2
<birtles> https://rawgit.com/shans/csswg-drafts/animations-2/css-animations-2/Overview.html
birtles: Most of you know animations as an API, but there's
another part to web animations. How do things like
repetition work? So CRR animations and transition are
using the definitions from SVG on how they work. If they
do that you can use the same API to inspect those.
birtles: I think it both Chrome and FF have been working on moving
to that code. If you're used to seeing some of that code,
it's using the API. We'd like to expose it up, but we
need a definitive way from CSS into that and the obvious
place is Animations 2
birtles: It exists as a delta spec to spec the cancellation event.
Shane and I have looked to add the definitions of how CSS
animations maps onto the other animations.
birtles: I wanted to bring this up today to ask how we should
proceed. I'm finding it difficult to handle as a delta
spec. I'd like to drop in text to Animations that's
covered by web animations. That's the initial topic and
other people might have suggestions for Animations level
2.
dbaron: I think the work...I don't think rewriting on top of web
animations will work as a delta spec, but I'm worried
about starting it at this stage because there are a bunch
of edits we need for level 1. If you're willing to
backport that's fine, there will be more work.
ChrisL: Short term it will be more work, but having a single
source where it could be edited would make sense.
birtles: I'd like to ship this and having the edits done in
animations 1 is a blocker.
fantasai: May I suggest you make the edits to animations 1?
birtles: Okay? I should check the scope, but tentatively yes. I'm
not a member of the WG.
dino: Isn't there something about having animations 1 so far down
in the rec track?
dbaron: birtles is agreeing to help with the things that need to
get done with Animations 1 so that we can get to
Animations 2.
fantasai: Who is the editor?
dbaron: Me.
RESOLVED: Add birtles as editor to Animations pending him getting
added to the WG
fantasai: dbaron is busy and since you're working on animations it
makes sense that you can help move it along and that
will help you.
birtles: That's the main issue in regards to animations.
shane: Do you want to talk about adding the animation composition
properties?
birtles: Not particularly. I was thinking of adding a property to
that branch, but it's not a priority.
plinss: That's it for animations?
Scroll Snapping
===============
<TabAtkins> https://drafts.csswg.org/css-scroll-snap/
[Archived copy:
https://lists.w3.org/Archives/Public/www-archive/2015Sep/att-0014/Overview.html
]
TabAtkins: fantasai and I have been reviewing snap points recently.
We have a few suggestions to go along with the scroll-
snap property. One in particular we think is required.
It's the handling of snapping elements when they're too
large for the viewport.
Overlarge Snapped Elements
--------------------------
[whiteboards]
TabAtkins: If you have a viewport and the element is too large for
the viewport and you center snap it, you have a problem.
If you want you can drag over, but it will snap to the
center or another point.
Florian: And if it's a lot bigger you won't be able to scroll.
TabAtkins: And arrows would be a problem too
TabAtkins: This will happen all the time. I expect things like
image galleries will be designed for a certain width
and on a smaller screen you will have overflow. So it's
problematic, common, and user-hostile.
TabAtkins: We came up with a proposed behavior. Our proposal is,
whenever you snap to an element and it's larger than
the viewport in some axis, in the overflowing axis you
then stop snapping to that element from now on. It
sticks there and no longer tries to snap. The edges
become the new snap points.
TabAtkins: It will try and avoid escaping, but if you fling well
past it will scroll off. You have to be a bit stickful (?),
but we believe it's a fairly general user friendly
behavior. This is similar to how existing apps work,
like gallery on Android and Microsoft phones.
TabAtkins: I think this is a fairly reasonable behavior and we
should mandate this.
fantasai: To do that, the spec needs to be working on the basis of
snapping an area to a position in the viewport, i.e a box
to a box as an alignment rather than a point to a point,
because you don't know how big the area is for the points.
So you specify not the points, but the box and the
alignment of the box. You position the box.
fantasai: You would say if you want the border box or margin box
and if you need additional margin there an offset
ability.
TabAtkins: Though that's not strictly necessary to fix this. The
minimum is a slight spec change and a behavioral change.
fantasai: You'd still need to know what the box is.
dino: I wasn't quite sure what fantasai said, but I think I
understand enough to support what you're proposing that you
snap to the edge when you overflow.
TabAtkins: We are happy to look into alternates or refinements,
but I think what we've described is a reasonable first
cut.
dino: Behaviorally, let's say you've got regular size elements and
scroll the big one into view. You're on a normal element and
you start scrolling into view, what happens when you get to
it?
TabAtkins: It should still do the normal snapping first. It seems
to be reasonable and simple.
hober: The implicit edges only activate after you snap.
fantasai: [whiteboard]
Florian: In general I agree with what you're trying to fix. I also
agree with your proposal. The thing I'm wondering about
is if this is the behavior we should spec, or if this is
a reasonable behavior and they might find other ways to
provide to move.
fantasai: I think we can allow UA to innovate as long as they let
the user get to each part of the content.
TabAtkins: I think we should spec based on requirements and
provide this as an example.
MaRakow: The discussion we had last night was about trying to
predict how it would feel. My experience is you can't
tell if it feels natural until you spec it. In the
stateful example it isn't intuitive in my experience. You
snap to the center at a top level and snap to an
individual and it's free panning. It's a good goal to say
if content is too large find a smart way to show all the
content. It's not clear this will solve every case.
TabAtkins: I'd love to spend time to prototype, I didn't have time.
TabAtkins: Are you comfortable with us drafting UA requirements
for overlarge?
MaRakow: We need to figure out how the phrase that. I think once
we prototype we'll understand what those requirements
need to be a bit more. There's a lot of ways to ensure
all the content is viewable and I don't want to go too
far without knowledge.
dino: Like if you make it 1px smaller you need two swipes.
fantasai: Once you'd swiped it's fine.
TabAtkins: If it's huge you might need to swipe twice.
dino: With the photo apps you can swipe to the edge and go to the
edge.
Florian: This concern about the ways you might interact is why I
was suggesting loose phrasing about the UI. I think we
need to change a bit the internal model so that you can
work around and propose a UI.
MaRakow: Your 1px example, swiping would take you out, but using
arrows you might not get out. Prototyping would catch
that. I like the goal to make large content easier.
TabAtkins: I'd be happy to help draft some text that says you must
allow the user to do the whole thing and maybe this as
an example and we can revise as we find better ideas.
Some sample that's better than nothing so you can see
you can do it this way or something better.
MaRakow: Let's start down that route.
fantasai: Robert O'Callahan would like us to get through this
sooner rather than later.
TabAtkins: We have several other edits to the spec which can be
built on top of the spec or a simplified version that
address some use cases.
fantasai: We'll go down the spec.
Overview
--------
fantasai: Some of the use cases are in the scroll snapping. A key
one is snap to the start or middle of each box. Those
are two of the use cases and that's how it would look in
our property [projector]
fantasai: There's a snap area that tells you if you're snapping to
the border or margin box with some offset.
TabAtkins: So whenever you scroll through, our example snaps just
before the bottom of the screen. This is similar to the
spec where you define the viewport as just above the
edge.
Florian: Just a bit of bikeshedding, the snap area with a em,
shouldn't it be a snap offset?
fantasai: Yes, we should probably split scroll-snap-align's
offsets into a separate property
<fantasai> e.g. scroll-snap-margin
TabAtkins: Here's a nice picture of it from the spec. The current
spec does it via snapping two points together. It sets
50% and 100px on the scrolling area, so slightly down
and 50% 0 on the item so the center top aligns slightly
down from the center.
TabAtkins: Or property instead says you always scroll to the top
and you'll treat the boxes as a little bigger. It's
just two different ways of looking at the same model,
but we feel the box based is more intuitive to the
author.
dino: So if you added your proposal to this, it would move the red
x...
TabAtkins: We talk about integrating in a bit.
liam: So you only do snap points when the used is scrolling or
dragging.
TabAtkins: You do initially and then whenever there's an inertial
scroll.
MaRakow: The common case was if you have a view port that's sized
like % as you resize the scroll. The size might change so
you might see half a photo. The snap point isn't about
the scroll, but a valid view.
TabAtkins: The gravity well describes it well...in a mandatory you
go all the way over to the next mandatory point. Which
is does depends on how strongly your design requires
the motion.
fantasai: We had a scroll-snap-align property in the spec and a
scroll-snap-area property.
fantasai: We can have scroll-snap-box: [border-box|margin-box|]
and scroll-snap-margin: [<length>|<percentage>]
fantasai: scroll-snap-area says what box we are snapping
fantasai: The align property says when am I snapped. What
relationship of me to my viewport causes me to snap?
fantasai: If you have center then the center is in the center of
the box and that's a snapping position. It works kind of
like background positioning.
Florian: Does edges mean start and end?
fantasai: Yes.
MaRakow: We talked about that last night and the behaviors you
would expect being directional.
fantasai: We'll get to that in the use cases.
hiroshi: Is it impossible to align to an arbitrary place?
TabAtkins: The current, what's currently written it's impossible,
but we were given decent use cases last night so it's
fine and we should extend that.
TabAtkins: We'll still want start and edges, but replace center
with a position.
TabAtkins: scroll-snap-align is scroll-snap-coordinate in the
current spec.
MaRakow: Before we move too far, the distinction between two
points and one offset, if it's more natural for the
offset to be one point or two and if it's more natural to
distinguish from the edge or the top.
fantasai: The other model is I want 100px of space between the
viewport and the edge when I'm snapping.
MaRakow: Where it's one offset, yes. The other case is when you
have two complex things where you want to share a
position. You have a bunch of cities on a map and those
cities might not be the center, you want to snap to the
center of the region and it's a more complex destination.
TabAtkins: That's the distinction between 1d and 2d snapping.
Florian: The map example, even if you're in 1d you may have
overlays over the edge of the scroller. In the example
you gave I agree it's more natural, but if you have an
overlay over the scroller saying snap to after the
overlay, you know the size of the overlay. Most of the
time one thing is fine, but once you're dealing with
overlay having multiple points.
fantasai: So also having scroll-snap-padding on the scroller?
Florian: Yes.
MaRakow: You can have the single point or you can do the mental
gymnastics.
<leaverou> what happens when the elements are overlapping?
Bert: Question on the edges. You could have a conflict where the
two edges are close, to which do you snap?
fantasai: Closest and if there's a tie, maybe the top one?
Bert: I don't want it flipping.
fantasai: Once you snap it's the nearest, so it wouldn't flip.
MaRakow: There's a lot that goes into which you snap to, you might
have velocity or weight. There's complex algorithm that
the UA might want to use. In general that's why I phrased
the spec in terms of here's a valid place to be.
fantasai: Use case #2 is a group snapping one, we should save that
for later.
2D vs 1D Snapping
-----------------
TabAtkins: 2d snapping. We have two examples. One is a flow chart
or a call graph, you have a bunch of boxes in a graph,
it would be nice to end where something is aligned with
the edge. To do that, our model is a type of
scroll-snap-type: proximity and on each edge you do
align edges.
Florian: And you could do margin 10px for comfort.
TabAtkins: Yeah.
TabAtkins: This shows off how some of the simple point to point is
insufficiently strong in some instances. This is edges
of a box so you have relationship necessary to do
something smart.
TabAtkins: Example #2 is a map. You're looking at Google maps,
when you fling to near a city, center the city and you
just give each city a snap-align of center.
TabAtkins: This example is similar the the example in the current
spec.
fantasai: The thing to distinguish when you're doing align to
edges, you might be happy that it snaps to a corner,
but it only snaps to one dimension, so snap points
will trigger in each dimension independently.
fantasai: With 2D snapping, you only snap whenyou're close to
the center in both dimensions.
TabAtkins: [whiteboards] You don't want a map with two cites where
one has centered vertically and one horizontally. The
algorithm in the spec distinguishes between 2d and 1d
to make sure it falls out correctly.
+--------------------------------+ <- viewport
| : |
| * City A |
| : |
|...*............:...............|
| City B : |
| : |
| : |
+--------------------------------+
Edge Snapping
-------------
fantasai: Next is slideshow. Let's say I have a scrolling
slideshow and each slide is given 100vh. I want to snap
to the slides because I don't want to be halfway between.
Sometimes you might have a slide that's a little bit
taller because I have a really long picture, like
redwood tree height.
fantasai: I want to be able to tell it to snap its edges so I can
scroll through it, but if I pull hard enough it snaps to
the next one.
fantasai: This is an example of snapping both edges.
TabAtkins: So your slides are a horizontal flexbox with mandatory
snap points. Each slide is 100vw and a min of 100vh so
that it can grow. As you go slide to slide it will
align to the edges and you'll be able to scroll within.
TabAtkins: If you do a flick down and it's too powerful, you'll go
down and hit the bottom.
Florian: Is this the same rules as for center snapping that's too
big for the screen?
fantasai: It's in terms of edge snapping.
Florian: It seems these might be the same, but we might want to
define separately.
fantasai: We currently define this as the behavior and the
fallback is this is how you would do it. We could say
could instead of should.
fantasai: That's a bunch of use cases.
Scrolling UI
------------
leaverou: With slides you have to scroll with the keyboard. I
imagine with snap points you have to scroll more than
half. If you have a keyboard you might not be able to
get to the next slide.
TabAtkins: The current spec, when you scroll in a direction, we
don't consider any snap points in the other direction
MaRakow: There's lots of ways to implement that. There are people
who want light flicks to return you. I left it vague in
the spec intentionally. One is that it's large enough for
escape velocity. Another is that inputs are also a
semantic meaning. 'home' and 'end' mean go to the end.
Arrow keys make more sense to go to the snap point, not
velocity.
MaRakow: Most UA should be able to come up with a sane way to do
this.
TabAtkins: We should put that in the spec where inertial is easy
to map, but that things like arrow keys need a semantic
meaning.
MaRakow: Arrow keys might want to maintain a small amount of
velocity.
TabAtkins: So if you hit the right arrow key, you definitely don't
want to go left.
TabAtkins: If you do a tiny inertial flick it might be okay to
bounce back.
MaRakow: Right now it's intentionally avoiding the details of
physics and inertia.
TabAtkins: Yes, but the distinction is important.
MaRakow: I can see that.
Edges (cont.)
-------------
MaRakow: As long as we're on the use case, for the edges value,
should that be influenced by the directionality? Robert's
e-mail said they had issues.
TabAtkins: Roc at some point suggested when we're scrolling down
we care about top and up is bottom but realized that
was a bad idea.
MaRakow: I'm worried snap points on each edge might be the same
bucket.
MaRakow: If they can snap half way up and half way down, it can be
a problem.
TabAtkins: [whiteboard] if it's contributing two edges, if you're
naively handling this you'll scroll a little bit.
fantasai: A lot of these cases will be start. There's very few
where you want edges.
MaRakow: You mentioned the flow chart and you have the edge of
each item being the snap point. If you have 20 elements
on screen, you lose track of what you're snapping. Each
pan or scroll is snapping a different element.
TabAtkins: I feel you and I'd like to see the flow chart example
in person.
fantasai: I can imagine having a message app where you have edges
on each message.
Bert: That's what I was thinking. That's a case that's useful.
dino: That's one dimensional. The flow chart there's so many.
TabAtkins: 1d and 2d are substantially different.
Florian: Does mandatory exist in 2d scrolling scenarios?
TabAtkins: Yes.
Florian: Edge mandatory in a flow chart would feel weird.
TabAtkins: The use case for mandatory is a 2d, though.
Florian: That's two 1d scrollers.
fantasai: So like Zelda where this is one room and then you go to
another room and it snaps in.
Florian: Okay.
MaRakow: One thing about the 1d case, ensuring that the element
you're snapping to isn't the bottom edge of an element
that's just off the top of the screen. Making sure the
thing snapped to isn't off screen.
TabAtkins: Start edge of the box goes to the start edge of the
scrolling container.
TabAtkins: That was the intention, though we might not have
spec'ed that clearly enough.
Bert: You skipped example #2, grouping. I think that case makes
grouping unnecessary
Review of Changes
-----------------
TabAtkins: That was our basic exploration of let's recase the
current spec into more familiar tables.
TabAtkins: Scroll-snap-type is the same. Destination we can keep
for compat, we think it's necessary. It will get auto
where it matches what the element is going.
fantasai: Renaming-wise it might be target.
TabAtkins: The new property that's not in is scroll-group-align.
On the children scroll-snap-coordinate is to -align.
I'm skipping area. Not too large.
fantasai: We're switching to an alignment model.
TabAtkins: We end on the same number of properties.
<leaverou> minor: shouldn't the initial value of scroll-snap-area
be margin-box? If there's spacing around the element,
you'd probably want that spacing when you snap to it,
in most cases, I imagine
Group Snapping
--------------
fantasai: Group snapping...
TabAtkins: Group based snapping isn't in the current spec.
fantasai: It's using the repeat syntax there.
TabAtkins: You might have a lot of items much smaller than the
viewport and you want to scroll in a paged method.
Rather than snapping each item, you can snap pages,
like an address book.
TabAtkins: So the meaning of this is the element does its normal
edge based, but it contributes the edges. If you look
at the edges, the start most and end most become what
you are not aligning. You take as many address pages,
the first and last are what's aligned, and we continue
down the scroller.
fantasai: [whiteboards] so I have a bunch of randomly sized boxes.
(Where each box here is the scroll-snap-area of the box.)
I line them up and take the first top edge. I go down
one screenful and take the last bottom edge that fits in
the screen, that becomes one page. I take the next top
edge whose position is >= that previous bottom edge, and
then find the bottom edge one screenful down from that.
fantasai: We're answering the quesiton, what is the set of whole
items that will fit?
TabAtkins: So if you know the size of the items you can use
wrapped divs, but if you don't know this does it for
you.
Bert: And this is dynamic?
TabAtkins: We haven't gotten into a ton of detail.
fantasai: I think we wouldn't recompute so your pages stay the
same since you can do something like "I remember seeing
that three pages ago" and want to go back.
SteveZ: Some of the better scrollers for text don't jump whole
pages, but give me the last few lines.
TabAtkins: That's basically example 2. So you collect a page of
whole paragraphs and when you flick you go up and get
the last paragraph you hadn't fully read yet.
TabAtkins: I would kill somebody to get this in my normal web
reading experience.
dauwhe: You want pages :D
MaRakow: I had similar questions to Bert. What happens if you
delete elements?
TabAtkins: If you change the DOM you should recompute.
fantasai: You don't change based on scroll experience, but if the
content changes you change the scroll groups.
MaRakow: So something like a twitter and I get rid of the stale
tweets, do I get new pagination?
fantasai: That applies to both.
MaRakow: The repeat is the first spec. The content moves and you
don't. If the goal is nice pagination this is nice.
TabAtkins: 3rd example is you have a lot of images like Pinterest.
They're irregularly packed and you don't know what the
size is going to be and they're going off the page. You
flick, everything you haven't completely seen goes to
the top of the page and it fills below.
Florian: How does that behave if all the images are bigger than
your page?
TabAtkins: Starting from the uncollected images...
fantasai: He's got a point. If you have a big giant image that's a
screen and a half. You don't want the first group to be
as tall as the image.
TabAtkins: [whiteboards] you have several small images in one
column and one huge image in the other. How the big
element behaves, I'm not sure.
Florian: And what if they're all too big?
TabAtkins: Your group would be overly large.
Florian: And then you get the behavior for when things are bigger.
A prototype would be useful.
MaRakow: You'll start issues with 2d as well.
fantasai: We think you can group in either axis.
MaRakow: But you can't have a 2d group that looks like an area?
TabAtkins: The bounding box and the group is what you're defining.
MaRakow: A 2d scroller?
TabAtkins: You could, yeah.
MaRakow: You'll get more problems with that because the pages
won't even be in a grid. If you can do both the first
page will be weird.
Bert: Grouping is overkill. I like snap points, but if you go too
far in pagination, it's better off using real pagination.
You can break the large box. The grouping is too complex, it
doesn't give you want you really want to get.
Rossen: Real pagination isn't meant for this. You'll start hitting
all the fragmentation rules which you don't want in
presentation media.
fantasai: You don't want to break into multiple pages.
fantasai: You want an image to be one continuous thing.
SteveZ: And you may want overlaps for a lot of your content.
You're scrolling in sort of pages, not real pages.
TabAtkins: And you can use scroll snap margins on the pages.
TabAtkins: Group snapping, we think is useful, but they're not
necessary for level 1. The big use cases are from
simple snapping.
Reconciliation
--------------
TabAtkins: You can handle over large stuff. The big issue is
renaming stuff. Do we want to do that now?
TabAtkins: scroll-snap-destination we can keep or change to target.
We'd like to add 'auto' value that sets to center
snapping. So destination. Keep or change?
Florian: The alternative?
TabAtkins: Target
fantasai: Unless you have another.
Florian: I like target better, but it's not very important.
TabAtkins: Anybody feel strongly?
MaRakow: If it's called target it starts to feel like it has
another meaning like event target.
hober: There is appeal in using something we're not using
elsewhere. But I see the appeal of shorter.
TabAtkins: So the addition of the auto to destination. Right now
if you want to center you have to say destination and
coordinate center.
MaRakow: What element does it copy from?
TabAtkins: Whatever element it's snapping to.
ojan: I haven't listened to all of this, but the destination vs
target, I think we should minimize changes as much as we can
because multiple browsers are shipping.
TabAtkins: It's a matter of if people are okay with changing. It's
okay to keep the names that are already here.
fantasai: smfr said they're under webkit prefix so it's okay to
change. Roc wants something stable soon, at this F2F,
but is okay changing. He thought the spec was stable
because it wasn't changing, but that's not a good
assumption generally...
hober: Question about auto. Does it always mean the destination
value comes from the coordinate value?
hober: Auto often means something difficult to describe. You could
use from coordinate.
fantasai: But auto can mean default. It can just mean do something
I can't express explicitly.
Florian: I'm not completely sure about auto. Depending on the size
of the scroller you get different things.
Florian: [whiteboards] if you're in mandatory type of things
you're past the middle of the second one.
TabAtkins: Don't mix edge and point alignments, it's weird.
fantasai: Or if you do, do it for a very good reason.
Florian: So in this whiteboard it's the author being wrong.
TabAtkins: You can do a lot of dumb things with scroll snap if
you're dumb.
Florian: Depending on how tall your screen is you can end up with
problems.
TabAtkins: Only if you have a small amount of information.
TabAtkins: So destination stays named as-is.
TabAtkins: MaRakow on auto?
MaRakow: I was thinking what coordinates would make sense with
auto. Top does...
fantasai: It works just like background position. 100% is the
bottom, 0% is top and it's continuous.
MaRakow: So if you have a coordinate that's an offset of 20px and
your offset 20px is that 40px?
fantasai: I think we may want to break and come up with a list of
resolutions that we need from the WG. Let's get on the
same page conceptually. Right now we're at a high level.
TabAtkins: We'll have auto on the table then.
fantasai: The critical items is switching to this box model.
hober: Are you looking for a resolution today?
TabAtkins: In so far as if we're switching to this model we need
to have a completed transition to this model in 2 weeks.
Mozilla has shipped unprefixed. Which Roc had a lot of
the concerns we had but he shipped since he thought it
was stable.
fantasai: If you're going to work on this, we've only shipped for
a couple of months, then do it and do it quickly. smfr
says Apple has it behind a prefix.
MaRakow: For the box thing, this ties into the other issue on the
ML of 2d scrollers vs 1d nested scrollers and the ability
to spec snap coordinates on a single axis and once you
have enough lines you have a box. I think there might be
some overlap there. I think the scenarios on the ML are
compelling enough that we should explore that.
TabAtkins: So how do you want us to help you?
MaRakow: Let's start over lunch.
fantasai: Opinions from other members of the WG?
Florian: I like the direction. I had the same concerns as Roc.
Writing Modes
-------------
Bert: One...maybe there was a note that the start keyword isn't
writing mode dependent.
TabAtkins: It is.
TabAtkins: It's been on the scrollers writing mode. We do
sometimes care about child vs parent.
fantasai: We need to clarify.
fantasai: The model should be writing mode relative so if you say
start edge in one axis that is the block axis, if you
switch the vertical writing mode, the thing that was the
block should translate to still be paragraph to
paragraph.
Bert: It only depends on scroll-x or -y.
fantasai: Overflow-x and -y are physical, but we'll have logical
equivalents. The scrolling behavior for snap points
should be logical as well.
MaRakow: It's logical and physical similarly. There's lots of
things where you have the photo where you'll go the same
direction no matter the writing mode.
Bert: But you're missing keywords.
fantasai: We'll have to look at grammar, for sure.
Bert: But then you don't need them all.
TabAtkins: You can still scroll in two directions.
Bert: If I have something scroll vertically, I set something as
start it goes from the top.
TabAtkins: We fixed it a while ago. If you don't have to specify
the axis you have start in both direction.
fantasai: If you want to snap in one dimension, not the other, you
have to say start: none
Bert: But I don't want it to be start on the right side.
TabAtkins: Then say start: none
TabAtkins: Or don't make yourself scrollable in the axis and it
won't matter.
Bert: This is getting confusing. Maybe we do need a left and right.
TabAtkins: Nothing you described so far requires physical
directions. If you just use start: whatever direction
are scrollable are snapable.
Florian: What about bidi?
fantasai: Horizontal will change based on bidi.
fantasai: You use the writing mode of the scroller.
Florian: It might not be the start edge.
fantasai: Alignment property works the same way.
Plan Going Forward
------------------
fantasai: Any other comments on if this seems like a good
direction? Should we work with MaRakow?
hober: In general yes, it's just a lot to resolve on at once.
hober: I think continue working.
Bert: I'm not sure about grouping.
fantasai: I see dbaron and dauwhe and SteveZ nodding.
plinss: Does anyone think we should abandon this and ship what we
got?
hober: If they continue working on this...
Florian: This replaces the old model.
fantasai: Otherwise we cannot do anything.
hober: So wholesale replacing is a bigger question.
TabAtkins: So it's replacing scroll-snap-coordinate with these two
properties. -align and -area.
fantasai: I'm not sure you can get overly large elements to work
correctly otherwise.
fantasai: If you have something aligned to the top, if you're
aligned to a particular position. The overly large stuff
kicks in if you can't see all of it. If you're top
aligning you only want to snap to the top edge.
Nevermind...
TabAtkins: I don't think edges are required if we're only doing
overly large.
TabAtkins: Who doesn't want us to work on edge snapping over the
next two weeks?
fantasai: We replace stuff or we do all these on level 2.
Florian: +1 to replace.
MaRakow: We should discuss and see if there are options to do it.
plinss: So lets break for lunch, you guys sort out over lunch, and
then we'll try and propose some resolutions after lunch to
get this address. Okay?
TabAtkins: Yes.
<break=lunch>
plinss: Let's get started.
plinss: Are we ready for scroll snap followup?
TabAtkins: We decided we need to talk about this more.
Received on Friday, 11 September 2015 18:34:51 UTC