W3C home > Mailing lists > Public > www-style@w3.org > January 2016

[CSSWG] Minutes Telecon 2016-01-27 [css-grid] [css-snappoints]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 27 Jan 2016 18:56:28 -0500
Message-ID: <CADhPm3s74cc7SFM_hhEjD0OLrSs9_uMVmKBrg8+WAqmzg6f33w@mail.gmail.com>
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.

Missing named line search

  - RESOLVED: Accept the new language as suggested in option B of
              this e-mail:

Snap Points

  - There were still concerns about avoiding behavior that feels bad
      to a user when using 2D scrolling, especially when combined
      with mandatory.
  - RESOLVED: Bring 2D snapping into the spec and mark as at-risk.
  - There were varied opinions on if there needs to be more
      terminology around the viewport to distinguish between
      different types.
      - MaRakow reported he wasn't blocked on this, so a decision
          wasn't needed right away.
      - It was agreed that the viewport terminology should be
          defined in device adapt, overflow, or the viewport specs.
  - fantasai explained that she believed having scroll-snap-padding
      and scroll-snap-margin physical and scroll-snap-align logical
      makes sense because scroll-snap-align interacts with the
      scrollers which operate in logical direction.
      - MaRakow felt that her example case didn't deal with the case
          when the user sets two properties on a 1D scroll. He'll
          make another example case to further the conversation.
  - The bikeshedding of the properties currently called 'mandatory'
      and 'proximity' will happen at the F2F, but it was agreed that
      the names should be improved.
  - The short conversation on splitting scroll-snap-type seemed to
      indicate approval of the split, but naming will wait until the

Group Reminders

  - Please remember to reply to the e-mail about spec publications
      (available here:
  - Also, please continue to continue reviewing tests to keep the
      testing backlog small.


Agenda: http://lists.w3.org/Archives/Public/www-style/2016Jan/0250.html

  Rossen Atanassov
  David Baron
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Brad Kemper
  Simon Pieters
  Anton Prowse
  Matt Rakow
  Francois Remy
  Florian Rivoal
  Lea Verou

  Tab Atkins
  Daniel Glazman
  Peter Linss
  Myles Maxfield
  Edward O'Connor
  Alan Stearns
  Ian Vollick
  Greg Whitworth

  Scribe: dael

Missing named line search

  Rossen: Let's get going.
  Rossen: Do we have any additional agenda items?

  <Rossen> https://drafts.csswg.org/css-grid/issues-wd-20150917#issue-26
  fantasai: The named line search as described in the email was
            doing some non-consistent things. We changed the rules
            and wanted whoever was interested to review. This was
            the last week to review so if you didn't want to you
            didn't. I won't go over them.
  Rossen: We went over it on our end.
  <Rossen> https://lists.w3.org/Archives/Public/www-style/2016Jan/0123.html
  Rossen: The edits and the conclusion captured in this thread
          (above) makes sense.
  Rossen: We're good with that resolution.

  fantasai: Did we resolve?
  Rossen: We can sure. Do we have enough other implementors? Anyone
          from webkit who can look or Mozilla?
  fantasai: It was raised by the Mozilla implementor so they should
            be okay. TabAtkins and I made the change so I'm assuming
            webkit is okay. The webkit implementor said on the
            thread they liked it.
  Rossen: Okay. Do we have any objections?

  RESOLVED: Accept the new language as suggested in option B of this

Snap Points

2D Point Snapping

  Rossen: Keep, drop, or at-risk?
  Rossen: Who wants to take that?
  MaRakow: I can speak where it is. We talked to...Apple spoke to
           their concerns about the complexity at the Japan F2F. I
           was going to omit it, but Google wanted it on the table.
           I don't have a super strong opinion, but I'd like to
           decide to keep or drop now.

  Rossen: We don't have to resolve to keep if it's there. If you
          want drop or at-risk we should resolve.
  MaRakow: It's not in the spec, but in the TabAtkins and fantasai
  Rossen: It's not part of an official spec. So if we want to add it
          let's resolve.
  Florian: I'm not sure I agree because we've agreed to align to the
           proposal. I'd rather a resolution either way so that we
           don't have to debate which spec is official.
  Rossen: We have an official one and it's part of our charter.
          There's changes being brought from the proposed spec. We
          did resolve to have the slow combining of the spec. As the
          wording from last week's resolution is masterfully crafted
          by fantasai, we're not rubber stamping, we're moving many
          of the terminology pieces.
  Rossen: The topic was brought to the group to see if this part of
          the spec is to move forward or put at-risk.
  * fantasai thinks the point of Florian's comment was to avoid this

  Rossen: So, what is the proposed resolution at this point?
  MaRakow: I'd not resolve at this point, but leave it out, but I
           wanted to make sure everyone had a chance to speak.
  fantasai: We'd prefer leave it in and marked at-risk. I think a
            big part of Apple's concerns was from unclarity and
            we've clarified. TabAtkins and I believe there are
            reasons to keep it so we'd prefer in the spec and at
            risk instead of drop it.
  <Florian> +1 to fantasai
  Rossen: So the proposal is to move it into the WD and mark as

  MaRakow: fantasai, do you have what would remove it from at-risk
           in either direction.
  fantasai: at-risk is in the draft and gets dropped if there isn't
            sufficient interest to implement. The WG likes it and
            thinks it's a good idea but it needs implementor
  MaRakow: So keep or cut depends on if there's other
           implementations when we want to go to PR.
  Florian: Yes, if it's not implemented we can drop it quietly. If
           there's implementations we keep.

  smfr: My concern isn't implementation complexity, but experience.
        We do axis locking on scrolling. My concern with 2D is you
        have a situation where you're scrolling on one axis and 2D
        will move you on the other axis. I want implementation that
        doesn't feel bad to user. A polyfill to implement this
        behavior may help us see what it feels like and work out
        details in JS form.
  Florian: I don't think spec requires you go off axis, especially
           if you're in proximity. What proximity means is up to you.
  smfr: But mandatory + 2D would feel weird.
  fantasai: The intended use case is for something like a 2D map
            where you want to pan. A map or a planet or a game where
            you're going between worlds in 2D. If you're doing
            scrolling with a scrollbar it will be awkward. It's
            intended for other cases.
  smfr: So what about when a user without a trackpad encounters
        content like that?
  Florian: I think a map like that with proximity is logical, but
           mandatory can be odd.
  fantasai: You have that problem without snapping. If you're
            navigating something like the Super Mario Bros map with
            a scroll wheel it won't work.
  smfr: So I prefer to mark it at-risk. Once we have an
        implementation we may not like it.
  fantasai: Seems good to me.

  Rossen: So, resolution is to bring it into the spec and mark as
  Rossen: Objections?

  RESOLVED: Bring 2D snapping into the spec and mark as at-risk.

Viewport Snapping

  <Rossen> https://drafts.csswg.org/css-scroll-snap/issues-2015-12#issue-6
  MaRakow: This is talking about the terminology in the spec for the
           scrollable region in question. Is it a visual viewport or
           a new term? fantasai has proposed scrollport, I think.
           There was debate on that.
  MaRakow: The visual viewport implies some of the shared technology
           the browsers have for UI and what's viewed by the user.
           The content you see on screen is the visual viewport.
           That's the term in the spec.
  fantasai: It wasn't clear to me that viewport was being used for
            the scroller rather than the main root. And we have
            places in our syntax where we use viewport to refer to
            the root viewport.
  fantasai: The issue is that we need a new term for the portion of
            the viewport that is the boundary of snapping so we
            wanted the active region used for snapping for this
            viewport. We were discussing terminology for that. I'd
            heard scrollport in a couple of places. So that could be
            the viewport of any scrollable box. The root is the only
            place that has the distinction. So do we introduce it as
            the visual viewport and the viewport of all scrollable

  Florian: I think I'm in favor of fantasai's proposal because it's
           complex enough to need to understand and hard to learn.
           If we can keep the terms clear I think it will make CSS
           more learn-able.
  MaRakow: The visual viewport only pertaining to the root may not
           stay true. One item we added back in IE10 was to declare
           a region with overflow as zoomable. I think that's
           functionality we'd like to introduce and that has zooming
           at the root and sub elements.
  MaRakow: I wouldn't expect that the split in the long-term be
           unique. I think if we want to distinguish between root
           and element viewport, we might want to specify the root
           for vw and vh
  Florian: It's also meta-viewport, @viewport
  MaRakow: Right. All those things we'd want to distinguish.
  <smfr> iframes have viewports too
  Florian: We would need to disambiguate all of CSS at that point.
  Florian: I think a hierarchy of terms for visual and root and
           another term that's for scrollable...these are clearly
           related...but keeping layout as the root is more clear.
  MaRakow: But then there's still the case for sub-elements. You'll
           have visual and layout and scrollport and then there's
           too many terms for the number of concepts.
  Florian: Do you need to have zoom for this to matter? You have an
           element that's overflowing and scrollable
  MaRakow: Only case where they're different dimensions is when you
           have a zoom, currently. You can imagine other features,
           but that's the big one.

  Rossen: It also makes the difference...most obvious is any
          container that can position fixed position. The root
          viewport, but also iframes. We also have a device:fixed
          positioning which is similar to fixed but doesn't get
          effected by zoom so any UI you want to attach on the side
          of a viewport (using the term loosely) the optical zoom
          may or may not effect those.
  Rossen: For naming sake, the scrollport only talks about scrolling
          but doesn't have panning or other manipulation you can use
          to target that.
  Rossen: Is this something we need to discuss for scrollsnaps or
          should this be in the viewport spec that Florian plinss
          and I are working on.
  Florian: This kind of term definition belongs in that root spec or
           the device adaptation spec.
  Rossen: I'm just curious if this is worth being captured in any
          way in scrollsnap.
  Florian: It's good to know which term, even if defined elsewhere.
  fantasai: It should be defined in overflow.

  MaRakow: Either way, I think I can make an unambiguous spec
           without another term.
  fantasai: I think it's fine.
  Rossen: For this issue, do you not need a resolution.
  fantasai, MaRakow: no
  Rossen: Okay.
  Rossen: So we decided to take this into device adapt, overflow, or
          the viewport. Between these specs one can define this.

Physical/Logical Coordinates Mismatch

  <Rossen> https://drafts.csswg.org/css-scroll-snap/issues-2015-12#issue-7
  fantasai: TabAtkins and I replied to this. I don't think I added
            it to the list.
  fantasai: Let me find it.
  fantasai: This may need to be at the F2F
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2016Jan/0138.html

  fantasai: MaRakow pointed out that the coordinate system for
            scroll-snap-padding and scroll-snap-margin is physical
            and scroll-snap-align is logical. He was listing the
            background in that we added logical to margin and
            padding so both coordinate systems will work in both.
  fantasai: scroll-snap-align is logical for a few reasons. The
            direction that you're scrolling is almost never going to
            want to be physical because the direction of the
            scrollers are logical. So we designed scroll-snap-align
            to match that scrolling are mostly logical. Also when
            you set the axis you can choose physical or logical and
            you pay attention to that.
  fantasai: So we don't think it's harmed by being just logical. We
            could add physical and have them both expressible, but I
            think you'll always want to be logical even when
            referring to physical. If we find we want it in the
            future we have the space to do so, but we can limit it
            now. That encourages authors to do the right think and
            limits testing.

  MaRakow: I don't think it helps for mismatch between horizontal
           and vertical.
  fantasai: You can use the scroll-snap-type and say x or y. That's
            provided. In the alignment if you give one keyword it
            applies to both axes.
  MaRakow: I looked at your example and when you give two keywords
           which is the first?
  fantasai: We wanted to be consistent with how alignment and
            box-alignment works.
  MaRakow: The example in your mail is only a single keyword for
           align, but the issue arises with two keywords. So I don't
           think your example covers the situation.
  fantasai: The situation is...
  MaRakow: If someone wants a thing only scrollable in one direction
           so the specify x and then they specify center and none,
           we want it to work.

  Florian: Why would they specify both? Why put both keywords on
  MaRakow: It's not an argument as to if it's a good idea, but if
           you have two, which is the first and which is the second?
  MaRakow: The spec needs to say what happens for two.
  Florian: The author would make his life harder. The simple way to
           author is one keyword in one direction. In the vast
           majority of cases the contradiction doesn't happen. If
           you use it the normal way there is no contradiction. You
           can get yourself there but you don't have to.
  MaRakow: I'm not saying this is the way you should build it, but
           if someone uses two keywords which is first and which is
           second? I'd like the spec to say something to keep it
           consistent. I'm not saying you should use two, but if you
           do what do you do?
  Florian: I was trying to go after that we should try to have the
           syntax that makes sense in most use cases. If the
           scroller is 1D, if you have two we have to decide, but
           it's not common. I think fantasai made more sense in her
           argument for what we do when there's 2D. That's the
           scenario that it makes sense to look at.

  MaRakow: So it would help to have an example that more clearly
           shows when the problem arises?
  Florian: So I think because setting one keyword for 1D the logical
           option is to set one keyword, so that's neutral. So we
           should look at the 2D scenario and see what's more
           relevant to express for that scenario.
  MaRakow: I don't think it's unique between. The only thing that
           changes isn't if you can scroll, but if snapping is
           interesting in the other axis. I can do an example with
           overflow in both directions and you want snapping
  Florian: Yeah, probably that would help. It's a good thing to

  fantasai: The default of scroll-snap is to work in block. We
            default to doing only one axis because we imagine that
            that's the most common. If we were to default to both
            directions the author could assume it's great on their
            big screen, but it could give horrible behavior on a
            smaller screen. To prevent that which could be common we
            made the default to accept both.
  fantasai: The default is logical. So it makes sense that
            snap-align should be logical. If there's compelling
            cases for when logical isn't appropriate we can add
            physical keywords. I'm just not seeing a case for that.
  Florian: So what we need to address this is 2D snapping and 2D
           scrolling example.
  MaRakow: I'll see if I can come up with a better example.
  Florian: Thanks.

scroll-snap-type Bikeshedding - Mandatory/Proximity

  <Rossen> https://drafts.csswg.org/css-scroll-snap/issues-2015-12#issue-1
  <Rossen> https://lists.w3.org/Archives/Public/www-style/2015Dec/0177.html
  MaRakow: The proposal is 'near' and 'always'. I would agree that's
           there's better names than 'mandatory' and 'proximity'.
  fantasai: I'm the same on this issue. We could do better, though
            I'm not super excited about those names. I'm open to
            other ideas.
  MaRakow: If it helps, I can add an issue to the spec saying we're
           searching for better names.
  fantasai: We'll have more people at F2F so that may be better for
  MaRakow: I won't be there, but if something comes up...
  Rossen: We can try and find a time you can call in if you'll be in
          the office.
  MaRakow: I won't be in the office, so I won't be able to call.
  Rossen: Bikeshedding can be re-bikeshedded. So fantasai proposes
          we take these to the F2F, look for better ideas, and bring
          them back as proposed changes.
  Rossen: Would that apply to the next issue?
  Florian: Probably.

Splitting scroll-snap-type

  <Rossen> https://drafts.csswg.org/css-scroll-snap/issues-2015-12#issue-3
  fantasai: We can talk about if we agree on splitting. But names
            should wait.
  Florian: I can see why we can, what's the use case?
  MaRakow: It's a goal to make it more clear as to which type of
           snapping applies to which axis. I have a hard time
           telling which would work better, but it's a lot of info
           into a single property. If we can be clear which snap
           types are for which axis it's a good goal.
  Florian: Splitting into 2 properties makes sense if we expect them
           to cascade separately. Do we expect that?
  Rossen: Good point. I don't see why they couldn't.
  Florian: You can, but is it useful?
  Florian: Is it a writing mode story where if you're mandatory or
           proximity it's fixed but if you flip...eh, maybe.
  Rossen: I don't know how much the inheritance model helps anyway.

  MaRakow: Seems like we maybe need a good example that shows an
  Florian: I think the split is possible...just...wondering how
           often you'll want.
  Florian: You can rely on default and be fine but you can rely on
           the shorthand. Sure. If we can get good names, why not?
  Rossen: Sounds like we came back to needing more people and more
          bikeshedding at the F2F.

Group Reminders

  Rossen: Spec updates. This is a nudging. We don't need to discuss.

  Florian: Related to the updates, how are we on testing and
           clearing the queue?
  Rossen: What in particular?
  Florian: We still have quite a few things in the test queue.
  Rossen: Right. It did move, but not significantly reduction. There
          was a lot of move right after the discussion we had. I
          would have to go back and see. I'm not sure if that was a
          momentary surge.
  Florian: I think it was.
  Rossen: I don't think we'd be able to decide a lot more on the
  Florian: Yep. Just a nudge.
  Rossen: Fair enough. If you can help reviewing tests, please do so.

  Rossen: Let's call it a day. We'll see most of you in Sydney. Safe
Received on Wednesday, 27 January 2016 23:57:27 UTC

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