W3C home > Mailing lists > Public > www-style@w3.org > September 2015

[CSSWG] Minutes Paris F2F 2015-08-26 Part II: Animations, Scroll Snapping [css-animations] [css-snappoints]

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 11 Sep 2015 14:33:52 -0400
Message-ID: <CADhPm3sp5BQ7wNVMwdBxKw5zGaz+qM=Xwcai4x_bdKSVxHRN6w@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:33 UTC