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

[CSSWG] Minutes Lisbon F2F 2016-09-20 Part VI: Scroll Snap, Timing Functions, Viewport API, CSS UI [css-scroll-snap] [css-UI]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 15 Nov 2016 21:28:23 -0500
Message-ID: <CADhPm3sp9ii29uiCw1ZuGAcz8dCU=+umgXm=deNw+OY=5oj7gA@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.
=========================================


Scroll Snap
-----------

  - RESOLVED: Accept fantasai's proposal (scroll-snap-padding is
              renamed to scroll-padding and scroll-padding reduces
              the area of the viewport that the UA considers
              “visible” when performing semantic scrolling
              operations.)
  - RESOLVED: No renaming of scroll-snap-type: mandatory |
              proximity, because no better proposals.
  - RESOLVED: No renaming of scroll-snap-stop: normal, because no
              better proposals.
  - RESOLVED: Accept the text in spec for snap scope.
  - RESOLVED: CSS Scroll Snap to go to CR

Timing Functions
----------------

  - RESOLVED: Split out timing functions into own module, Level 1 to
              include functions that have been implemented for
              awhile, Level 2 to include newer functions/proposals
  - RESOLVED: birtles shane dino MaRakow to edit

Viewport API
------------

  - This work will continue in WICG and Florian will join so he can
      participate more.

CSS UI
------

  - RESOLVED: If you click or click and drag in user-select:none
              area, doesn't affect any existing selection
  - RESOLVED: Keep outline-color: invert unless Edge decides to
              drop, in which case we drop.

===== FULL MINUTES BELOW =======

Agenda: https://wiki.csswg.org/planning/tpac-2016#agenda

Scribe: ChrisL

Scroll Snap
===========

scroll-snap-padding vs scroll-padding
-------------------------------------

  <Rossen> https://github.com/w3c/csswg-drafts/issues/395
  fantasai: Scroll snap padding changed to more general
            scroll-padding.
  fantasai: Define which part of viewport is in view.
  fantasai: Not to affect visibility but if it is in comfortable
            position for viewing.
  fantasai: Affects scrolling into view, through script or
            interaction, page up/down, affects scroll from caret
            movement,
  fantasai: similar things. No effect on layout or scroll origin
            except as affects snapping.
  fantasai: Declarative replacement for js scroll hacking.
  <fantasai> to accommodate UI elements floating over the scrollable
             area.
  fantasai: And request for caret operations.
  fantasai: Same effect for scroll snapping, but more interactions
            covered too and better UX.
  Florian: If we have this, it makes a couple of old proposals
           obsolete, and no need for the proposed properties.
  Florian: Simpler way to address that.
  MaRakow: There are objections around semantics of scroll snap for
           snapping purposes, usage patterns on scroll padding.
  MaRakow: Can't use one without affecting the other, see github
           issue.
  MaRakow: Do implementors have thoughts?
  dino: Apple has no opinion.
  jet: hmmm
  jet: I will comment on github.

  fantasai: This is last blocking issue.
  Florian: Since Sydney at least.
  fantasai: MaRakow argues that keeping things separate, odd because
            most use cases the value is the same one on scroll
            padding so one property for both uses makes sense.
  fantasai: can separate by making a shorthand later if needed.
  fantasai: Main use case for scroll-snap-padding is to block out
            things too close to the edge or covered by UI
  fantasai: Need to block out for all these scroll ops.
  fantasai: If you do want a difference then set scroll-padding based
            viewport
  fantasai: and then use scroll-snap-margin on snapping element to
            give a different spacing.
  fantasai: So all use cases addressed and common case is easy.
  fantasai: So accept this proposal please and make it easy to do
            good scrolling.
  TabAtkins: Agreed.
  TabAtkins: It's useful to solve things right now. Same for
             scrolling and snapping, make it generic of overflow
             control.

  jet: Is this from implementation?
  jet: We have an implementation
  TabAtkins: No it is super old and crufty.
  fantasai: Filed because of working through spec and seemed the
            author use cases not solved.
  fantasai: All are simply solved by widening this property
  fantasai: to more cases.

  MaRakow: I'm confirming no other strong opinions.
  Rossen: No strong ones but TabAtkins leans towards fantasai
          strongly now, as is dino.
  Rossen: So it is all you Matt.
  MaRakow: Scroll snapping is specific alignment in the viewport
           while the functionality is a range in view so
  MaRakow: not guaranteed to be the same as the box that what
  MaRakow: accessible in view box.
  TabAtkins: All approximately right and when a bit different,
             scroll-snap-margin handles just fine.

  MaRakow: Could other implementors read the issue and chime in?
  MaRakow: Does syntax get overloaded?
  MaRakow: Others seem to think not.
  <andrey-rybka> +1 for Elika's proposal
  fantasai: If you really want to do it with padding then we can
            split scroll padding into two longhands down the road.
            Doubt we will.
  fantasai: I'm not seeing the mismatch you think exists.
  fantasai: Theoretical purity that should not override author ease
            of use.
  <jensimmons> +1 to that — one property that does many things. Not
               multiple properties that are similar.
  MaRakow: I'm not objecting strongly, want other opinions
  MaRakow: on the githb issue.
  <andrey-rybka> just a data point but what Elika proposed actually
                 solves many use cases for Bloomberg

  Rossen: So as this is the last issue holding us from CR and to
          move forward, call for consensus on current issue as
          stated by fantasai. So no sustained objection?
  Rossen: You want implementors to give a full read before making up
          their mind?
  astearns: More support of fantasai's proposal.
  dino: Let's decide and adjust in CR if implementors find issues.
  Rossen: ok with that?

  astearns: This is the last open issue.
  MaRakow: No there are still some.
  fantasai: Two renaming but no proposal so rejected. One editorial,
            conciseness. One resolved already.
  fantasai: So just this one issue.
  Rossen: So apart from editorial ones, no outstanding design
          issues. MaRakow, agreed?
  MaRakow: Offscreen mapping is one.
  fantasai: Sitting with proposed text since june, at least.
  fantasai: accepted previously the text was not good.
  fantasai: Don't know what you are objecting to.

  Rossen: Almost out of time.
  Rossen: Call for consensus.
  Rossen: Any objections:
  (none heard)

  RESOLVED: accept fantasai's proposal

Naming
------

  fantasai: Rename anything? No actual proposal.
  fantasai: So leave as it.
  Rossen: Can we live with mandatory and proximity.
  (no objections)
  RESOLVED: No renaming of scroll-snap-type: mandatory | proximity,
            because no better proposals.

  fantasai: scroll-snap-stop normal and always, rename normal.
  (no objections to keeping those names)
  RESOLVED: No renaming of scroll-snap-stop: normal, because no
            better proposals.

Snap Scope
----------

  <fantasai> https://drafts.csswg.org/css-scroll-snap/#snap-scope
  fantasai: Wording in section on scroll snap, if the top edge of
            a box is aligned over here way outside the viewport,
            shouldn't snap to it. Should not care that it happens
            to align, because we can't see it at all.
  (we film the interpretative dance)
  (literally)
  fantasai: Honestly don't know what the disagreement is so can't
            fix it.
  Rossen: matt?
  MaRakow: Point of snapping is to point to snap to the things out
           of view currently and is this corridor scrolling the
           feature only starts scrolling through the animation of
           the scroll.
  MaRakow: I understand the intention.
  MaRakow: Outside x direction of the viewport is not contributing,
           not strictly true.
  * ChrisL thinks this is poorly captured sorry does not follow what
           matt is saying actually.

  Rossen: Proposed text?
  Florian: I think this is the same issue as what I raised earlier
           about the wording problem regarding the corridor, for
           which I got convinced that it was fine.
  fantasai: Different topic.

  MaRakow: Might proposed something last time but not sure. path
           scroll would take .... considered for snapping.
  Rossen: Okay, fair if the spec does not say what exactly is
          considered outside, needs to be better defined.
  fantasai: Depends on which snap positions you consider to land.
            this however is not that.
  fantasai: What this prose is saying is that this position (with
            the top of the box aligned, way off-screen) is not a
            snapped position.
  fantasai: like the illustration in the spec, offset in the wrong
            axis so not snapped.
  fantasai: When looking for snap positions can consider it, that's
            up to UA, but can't snap to it unless also brought into
            view
  fantasai: So this is not about taking corridor into consideration.
            Simple answers question: is it snapped? no it is not.
  MaRakow: Have to choose one and need to know which are valid.
           Scoped through custom scroll, intersection on x axis
  fantasai: See the section on choosing snap positions
  fantasai: this XY cannot be chosen, it is not snapped.
  fantasai: Even if author manually aligns them there, ua is not
            snapped there.
  Rossen: this is in a different section.
  <fantasai> https://drafts.csswg.org/css-scroll-snap/#choosing
  fantasai: Section 6.2. this one is saying it is not in a snapped
            state.
  <fantasai> Section in question -
https://drafts.csswg.org/css-scroll-snap/#snap-scope

  Rossen: Just ended up there by chance anyway, still not considered
          snapped.
  Rossen: Make sense?
  MaRakow: I think so.
  Rossen: So this addresses your issue.
  MaRakow: Think so yes.
  Rossen: Minor editorial clarifications in CR, lets resolve to do
          so.

  Rossen: Any objections to moving to CR?
  fantasai: lets go to CR
  <andrey-rybka> +1 for CR
  (no objections)

  RESOLVED: css scroll snap to go to CR
  RESOLVED: to accept the text just discussed

Timing Functions
================
  scribe: fantasai

  birtles: Can we please start another spec?
  birtles: Wanted to define timing functions for both transitions
           and animations and web animations in one place.
  birtles: Currently in Transitions, it's kindo f awkward.
  birtles: Talked about having a frame timing function.
  birtles: Apple has spring timing function.
  birtles: Also talked about things like script-defined timing
           functions,
  birtles: Multi-segment timing functions,
  birtles: all these things need to have a home.
  birtles: So proposal is we make another spec for timing functions
  birtles: and take it out of CSS Transitions and put all that stuff
           there.
  [general agreement]

  fantasai: I think it's a great idea
  fantasai: I would like to see that if it's pulled out of
            Transitions Level 1.
  fantasai: We have two levels of this spec
  fantasai: one with the interop stuff that should go to CR like 2
            years ago
  fantasai: And one with with all the new stuff.
  dino: Do we need an incubator? Can we just go.
  Rossen: This is existing work, just splitting work that's in one
          spec into another spec
  Rossen: Continuing existing work.
  Rossen: Don't see any reason to incubate, nothing new there.

  Rossen: Would ask Tab, would you agree with this statement or not.
  TabAtkins: Wasn't listening, so yeah sure.
  shane: I want to answer for Tab, answer is it depends.
  shane: Apple's spring timing function fundamentally breaks timing
         function model.
  shane: Would rather not see it in a timing function spec.
  shane: Think we could accommodate it with the same syntax Apple
         proposes declaratively in the scrolling animations spec, if
         we generalize that.
  sam: Which aspect of it fundamentally breaks the timing model?
  shane: Previously, timing functions couldn't alter the duration of
         the animation.
  TabAtkins: More specifically, none of the timing functions had an
             opinion on what the duration is.
  TabAtkins: Have to do the math on spring, then set duration
             accordingly.
  TabAtkins: Otherwise looks stupid.
  dino: Only looks stupid if you pick a stupid duration value.
  shane: I thought the way it works was to change duration.
  [confusion]

  Rossen: Seems like agreement on continuing working on this.
  Rossen: Let's go back to request for splitting work so we can
          continue working on it.
  Rossen: Then we can decide on what stays and how it stays.
  Rossen: Do you agree with this, Shane?
  shane: If the timing functions you want to consider require...
  birtles: We can decide on where spring() lives later.
  shane: I'm fine with that.
  Rossen: Any objections?

  RESOLVED: Split out timing functions into own module, Level 1 to
            include functions that have been implemented for awhile,
            Level 2 to include newer functions/proposals
  RESOLVED: birtles shane dino MaRakow to edit

Viewport API
============

  rbyers: ...
  rbyers: Got some compete pictures and stuff, but short summary.
  rbyers: Trying to incubate a new API that will finely explain
          pinch zoom.
  rbyers: Not trying to make all browsers behave the same.
  rbyers: Not trying to fully define space.
  rbyers: But incremental step to expose a simple API that lets you
          reason separately about the space that the page is laid
          out into and the space that the viewer sees.
  rbyers: So, basically relative geometry and position of the layout
          and visual viewports.
  rbyers: Worked with websites, bunch of bugs.
  rbyers: Sites are broken because make assumptions about this.
  <rbyers> https://docs.google.com/presentation/d/1VxLlMTgrq11Q-ltPXyg5_7YuDAo00sbdElsRe752sQg/edit#slide=id.g861a184b2_2_237
  rbyers: Think simple API can be used to address these cases.
  rbyers: Demo/presentation
  rbyers: Get a sense of the behavior.
  rbyers: Talking a lot with MaRakow, he's given a lot of feedback
          on the API.
  rbyers: Here's the repo:
  <rbyers> https://github.com/WICG/ViewportAPI
  rbyers: Trying to get bare bones simple bit, incubate and iterate.
  rbyers: Experimental implementation of this in Chrome now if you
          turn on experimental features.

  Florian: Looked over, seems good to me. Happy to keep in WICG.
  Florian: I think the terms visual viewport and layout viewport
           should go into device-adaptation because more than just
           you is depending on these terms.
  Florian: Please file issues against me on specific things you need.
  rbyers: Most CSS specs need to be updated to say which viewport
          for every place they say viewport.
  rbyers: And no two browsers agree on which one for these things.
  astearns: Florian, will you join the WICG group?
  Florian: Yeah.


CSS UI
======

user-select: none and selectionchange event
-------------------------------------------

  <astearns> https://github.com/w3c/csswg-drafts/issues/319
  Florian: Have a thing selected, and then click something with
           user-select:none
  Florian: Should it unselect? Should it?? or ???.
  Florian: I was tasked to ask the editing task force.
  Florian: Multiple people said doing things inside user-select:none
           shouldn't affect selection.
  Florian: Think we should resolve on that.

  hober: I think it should match platform convention.
  Florian: What is native behavior of clicking "user-select: none"
  hober: Behavior of clicking on an non-selectable area of the UI.
  Florian: Safari already doesn't match what Mac OS does.
  johannes: ... when you cannot select them, you should not lose
            your exiting selection.
  esprehn: user-select:none causes us to unselect things, and we
           want to change that behavior.
  Florian: I think that's a separate issue. No interop, chrome and
           edge said they'd match Firefox, and editing TF agreed.
  * fantasai is confused what the behavior was

  Florian: If you click or click and drag in select:none doesn't
           affect existing selection.
  Rossen: Any objections?
  <andrey-rybka> +1 to resolve

  RESOLVED: If you click or click and drag in user-select:none area,
            doesn't affect any existing selection

  dino: There should be an escape clause for platform convention.
  dino: There are definitely parts of UI that are non-selectable in
        the platform.
  Florian: The fact that different browsers behave differently was
           confusing JS users, so request was to harmonize browsers.
  Florian: Safari would have to change, but after change would match
           its own platform better. So what's the problem?

 Remove outline-color: invert
 ----------------------------

  <astearns> https://github.com/w3c/csswg-drafts/issues/423
  Florian: outline-color has two color values. One is 'invert',
           which is initial value. If can't 'invert', defined to
           fall back to initial color.
  Florian: There are two implementations, one relevant (Edge), two
           irrelevant (IE, Opera). No process block.
  Florian: Browsers are allowed to not implement inversion if
           impractical.
  Florian: Don't see any value in removing the value. But people
           have asked to remove the value.
  Florian: Use case that justifies this value is real, and we have a
           relevant current implementation. Would rather not drop it.
  Florian: Fact that Edge/IE have this feature and want to continue
           having it, I think we should keep it.
  Florian: If they want to drop it, then we should of course drop it.
  fantasai: So proposed resolution: keep invert unless Edge decides
            to drop, in which case we drop

  RESOLVED: Keep outline-color: invert unless Edge decides to drop,
            in which case we drop.

  Rossen: Going back to the agenda, we have 10 minutes left
  * fantasai would like to get first-baseline last-baseline sorted,
             is blocking css-align atm

CSS Text Decoration
-------------------

  fantasai: With regards to text-underline thickness/position, has
            to be separate property from the existing -position
            property, because that one is language-dependent and
            intended to inherit through independently from other
            properties.
  fantasai: Probably want an -offset property for position control.
  <bobbytung> -offset +1

  [Meeting adjourned]
Received on Wednesday, 16 November 2016 02:29:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 16 November 2016 02:29:27 UTC