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

[CSSWG] Minutes Lisbon F2F 2016-09-20 Part V: Scroll Linked Animations, Writing Modes Level 3 Test Status, Scroll Anchoring, Media Feature: “reduce motion” user setting [css-writing-modes] [css-align]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 15 Nov 2016 21:28:09 -0500
Message-ID: <CADhPm3s=Xh66iePhub4gq+O=gt0hjEB_kV44Rdg5o6n1KN3W+g@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 Linked Animations

  - birtles introduced the two existing proposals and some issues
      that they have uncovered in trying to create these proposals.
  - RESOLVED: Accept this scroll linked animation work, to be done
              under the WICG

Writing Modes Level 3 Test Status

  - Koji reported that of the 995 tests there are 13 that are
      blocking the move to PR.
  - The tests on text orientation upright property have no
      implementations passing and fantasai was actioned to look into
      these tests more as she believes we need to pass these tests
      before progressing.
  - Koji will begin preparing a new DoC listing reasons why at-risk
      features are removed and any responding to any feedback
      received since the last publication.

Scroll Anchoring

  - ojan introduced the work being done in WICG to allow for scroll
      anchoring which addresses the common use case of content being
      added (such as an add) which pushes down existing content and
      effects scrolling.

Media Feature: “reduce motion” user setting

  - jcraig requested the addition of a "reduce motion" user setting
      for accessibility.
  - There was interest in adding this feature, but disagreement as
      to if work should happen on just this item or on a complete
      grouping of accessibility-related user settings such as
      monochrome and reduced transparency.
      - The group ran out of time on this topic before concluding on
          exactly how to proceed.


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

Scroll Linked Animations
  Scribe: dino

  birtles: Dean sent a proposal years ago, but it wasn't complete.
           Google and Mozilla have come up with separate new
  birtles: I'll give a 1 minute demo, and list a few issues.
  <dino> Mozilla's proposal - https://birtles.github.io/scroll-animations/
  <dino> Google's proposal - https://github.com/drufball/generalized-animations
  [birtles shows a custom build of Firefox with some scroll-linked
  myles: Is there any script in this demo?
  birtles: Yes, it's a mix of both. Declarative for easy stuff,
           script takes over after a while.
  [birtles shows a demo with a mix of scroll-based and time-based
      animations. switching between the two.]

  birtles: We've found three issues:
  birtles: 1. Transitions
  birtles: In many cases you want to represent behavior with
           transitions not animations. e.g. if you want something to
           appear, you need two animations for in and out.
           Transitions is just a state change. In other cases an
           animation is fine, since it is a run-once situation.
  birtles: It was a surprise to us that transitions were the most
           natural way to author many of these effects. This makes
           the animation-trigger feature less useful.
  birtles: We have drafted something called @trigger that can be
           used to change style based on scroll position.
  birtles: So issue 1 is do we need an @ rule or something.
  <birtles> http://www.nytimes.com/projects/2013/tomato-can-blues/?hp
  <birtles> http://cuberto.com/

  birtles: 2. Layout cycles
  birtles: Once you have the idea of triggers that can affect
           layout, you can possibly have a cycle.
  birtles: We have some vague wording in the proposal about freezing
           the scroll offset for the frame.
  birtles: This avoids a cycle within a frame, but you can still
           have flip-flop animations.
  dino: Transitions already has this issue.

  birtles: 3. Describing the scroll points for triggering animations
  birtles: Maybe we can use the scroll snap points syntax, but I
           don't know how to do it.
  Rossen: You mean scroll-snap events?
  birtles: No, about linking a scroll point to an element.
  [birtles describes how he wants something to happen based on the
      position of an element]
  fantasai: Scroll snapping lets you specify where a scroll for an
            element will be, but does not let you reference that
            from another rule.
  fantasai: Have a new property that is "when the scroll snaps at my
            scroll point, then something happens"

  Rossen: Thanks for this introduction, we've been waiting for this
          for a long time.
  shane: We need to work out what we are going to do.
  shane: I suggest a small group of people in an incubator.
  Rossen: Unlike fonts, this seems like a good example of something
          that could go to WICG and come back when it is more mature.
  Rossen: Please, if you want to participate on this topic, do so!
  astearns: It doesn't need to be a small group. It should include
            the type of people who are solving this problems with
  astearns: Make it as wide as possible.

  RESOLVED: Accept this scroll linked animation work, to be done
            under the WICG

Writing Modes Level 3 Test Status

  koji: The test status is linked from the agenda
  <Rossen> http://kojiishi.github.io/generate-w3c-implementation-report/css-writing-modes-3/status-2016-09.html
  <ChrisL> There are 995 tests in the test suite, 118 of that have
           only 1 or less implementations.
  koji: There are 995 tests in the suite. 118 tests do not have 2
        passing implementations.
  koji: I've categorized them.
  koji: Most of the 118 are related to this group. Only about 28 are
  koji: The suite depends on 5 other specs. I excluded them from the
        28. Then if I remove the MAY or SHOULD tests.... (form
        controls, etc)
  koji: This leaves 13 tests that are blocking our exit.
  koji: Of those 13, four categories...
  koji: 1. synthesized baseline
  <fantasai> of atomic inlines in vertical-lr
  koji: 2. text orientation upright property
  koji: affects the used value of direction
  koji: there are 0 passing implementations
  koji: 3. absolute positions
  koji: There are ~250 tests in this group, and 3 of them don't have
        2 implementations
  koji: 4. Glyph composition
  koji: edge case - text combine has a newline character, there is
        only one passing implementation
  koji: These all seem minor to me, and we've made a lot of
        progress, I propose that we allow these failures and move to
  ChrisL: We could make the case that 13 failures is ok.

  fantasai: For number 2, were you testing the used or computed
  fantasai: So upright text is in the wrong order?
  astearns: Could fantasai take a look at those 13 failures?
  ACTION fantasai to take a look at the 13 failing Writing Mode tests
  <trackbot> Created ACTION-794

  astearns: Have you filed browser bugs on these failures?
  koji: Some of them, but since authors have not complained, I don't
        think they are real world issues.
  Rossen: You should still file the bugs.
  jet: We do have Gecko bugs for all these! I see that browsers only
       have at most 80% complete coverage. Is that enough?
  astearns: The criteria is that each test has 2 passing
            implementations, not that there is interoperability
            between all tests.
  ACTION koji to file these writing mode test failures on the browsers
  <trackbot> Created ACTION-795
  <dbaron> FWIW, when I started looking through the Gecko failures,
           I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1244601
           (which accounted for quite a few) but then didn't get
           further on filing additional bugs

  Florian: I've informally looked at changing writing mode on table
           cells and got weird results. Have we tested this enough?
  koji: Yes.

  <fantasai> I think category 4 failing test is a weird edge case,
             don't need to worry so much.
  <fantasai> I don't think that's the case for #2. Those should be

  Rossen: ChrisL, can we go to PR in this state?
  ChrisL: We are dropping all the at-risk features?
  astearns: Yes.
  ChrisL: We need to write up a clear rationale for us progressing.
          e.g. we've filed bugs, they are not show stoppers, etc.
  Florian: Especially for the features that are at-risk, we've
           already got a +1 spec ready.
  ChrisL: That doesn't matter.
  koji: Do you have an example of such a document?
  ChrisL: An email to the group is enough.
  astearns: Informed by fantasai's review.
  fantasai: The category 2 failures need to be fixed.
  fantasai: That's right to left upright.
  koji: This is uncommon.
  fantasai: More common in hebrew than arabic.

  Rossen: Any objections to the at-risk features?
  fantasai: I think there are blocking tests. I don't think #2 are
            an edge case.
  astearns: Does it help to wait for the tests to pass?
  astearns: Why not move to a new draft now?
  fantasai: I would prefer to wait. Implementations might be doing
            the work now.
  astearns: Look at the test failures, see if we can address
            category #2, cut down the draft to features that have
            passing tests.
  astearns: What else is necessary?
  ChrisL: For any comments we received since we last transitioned,
          we need to show that we handled them. i.e. we need a new
  ChrisL: It's fine to have the DoC say that it will be address in
          the new version.
  [clarification on what the transition process is]
  fantasai: From the list of 13 tests, if we have implementors who
            will fix a few bugs, we should be able to transition.
  ACTION koji to prepare DoC for writing modes transition
  <trackbot> Created ACTION-796

Scroll Anchoring
  scribe: ChrisL

  <ojan> https://github.com/WICG/interventions/blob/master/scroll-anchoring/explainer.md
  ojan: Doing this in WICG at interventions github
  ojan: Mitigate common experience of an ad loading and pushing
        content down. Adjusts scroll position
  ojan: during layout, store scroll position, adjust it back if it
  ojan: Anchor deepest element at top of page. Restore to position
        after layout
  ojan: as if user scroll, but browser scrolled.
  ojan: Lots of webcompat issues, ugly heuristics
  ojan: like poorly done sticky headers that jump.
  ojan: Walk ancestor chain and any ancestor that modifies layout we
        don't do scrolling.
  ojan: They animate padding on body which works poorly, gives
        scroll loops.
  ojan: We want to add a css property to control this.
  ojan: On by default, opt-out to current behavior, or opt in for no
  ojan: Move to wicg in next 2 weeks.
  ojan: Ignore fixed position elements.
  ojan: Should we do that for abspos as well.
  frremy: Can you get intervention when only specific things happen?

  fantasai: Are you aware it is affected by align-content property?
  <fantasai> https://drafts.csswg.org/css-align/#overflow-scroll-position
  Rossen: MaRakow is not on call yet.

Media Feature: “reduce motion” user setting

  jcraig: Exposing user prefs through css media features.
  jcraig: Macros has this;
  jcraig: flying animations that fly out,
  jcraig: spinning starfield. chrome example. zooming (demonstrates
  jcraig: Make people ill, painful, vomit etc.
  jcraig: This is called "reduce motion". Want to expose to web.
  jcraig: prefers-reduced-motion.
  jcraig: We asked 3 years ago.
  jcraig: What do people feel about exposing these. Fingerprinting
          obviously, outweighed by accessibility benefits.
  jcraig: Other ones are harder to do - contrast settings vary by
  jcraig: Reduce transparency settings.
  jcraig: (demonstrates a carousel)
  jcraig: Allows page authors to decide how to handle it.
  Rossen: Thanks.

  gregwhitworth: What about platforms with no motion control. Return
                 true always?
  jcraig: They will be asking support for it.
  jcraig: May be a way to do with extensions or custom MQ short term.
  jcraig: Prefer to avoid prefixing.
  dino: Trivial to implement, huge benefits.
  bkardell: Discussion earlier was user preferences, that we need to
            invent new ways to set independent of OS.
  bkardell: Talking in cognitive accessibility taskforce.

  jcraig: dpub ig does not want to allow this (?)
  jcraig: We have had shipping settings for years while their
          taxonomy is thousands of possibilities.
  bkardell: Do they overlap
  jcraig: Maybe.

  Florian: Useful to many, easy, should do.
  Florian: Seems to be in a broader category of similar things.
  Florian: Color contrast somewhere in between.
  Florian: Not clear how to expose to web platform.
  Florian: I'd like to notice patterns before we settle on it.
  jcraig: Did a high contrast text setting for example. Microsoft
          can flip foreground/background. Android have text contrast
  jcraig: Others related to contrast, reduce transparency to boost
  Florian: Whole area of inserted, boosted contrast etc. clear to do
           something but not what.
  Florian: Expressing a user pref, kind of tempted to put in the
           same group. But maybe just do that one.

  esprehn: Like to see spec clarified first. monochrome, safari
           connects to accessibility setting, we connect to display
  esprehn: no-one on a mac has one.
  esprehn: Purpose of the mq was not clear.
  esprehn: Need to be clearer why it is.
  <fantasai> esprehn, I think that wasn't originally its purpose,
             but it has been effectively repurposed :)
  TabAtkins: Happy to put notes in, in general it is the output
  esprehn: Too vague.
  fantasai: It was originally for monochrome monitors, got
  * fantasai doesn't think the original editors thought about a
             monochrome mode on a color monitor.

  jcraig: Toggled red square green circle for colorblind.
          Considering collapsing that feature.
  esprehn: If it is tied to the accessibility setting say so and
           then we know.
  fantasai: I'm agreeing with Florian. In context of related stuff.
            Want to see all the requests you have had, in a draft,
            figure out patterns.

  Florian: It is tied to accessibility so privacy.
  Rossen: That was already mentioned.
  Florian: Suggested earlier that when a page has that from js, user
           gets a permission notification.
  jcraig: Screen reader directly exposes a disability. This is some
          benefit but used by many more people.

  <Rossen> [FYI: we're closing on this topic]
  jcraig: Next steps?
  dino: Listing all queries is ok but OS already has categories. No
        need to discuss them again.
  Florian: Different ones have different lists.
  dino: Reduce motion is unfuzz, easy to do. Go ahead with that.
  hober: Let's not let perfect be enemy of good.
  dino: Some are fuzzy, changed between releases.
  Florian: One on me to update draft.
  astearns: I'd rather start with this one.
  astearns: asap
  fantasai: It's easier when we have all of them to look at.. this
            is brainstorming.
  astearns: Brainstorming should not go in draft.
  astearns: We have a process. Put in the things we are definite,
            add a note about vague stuff.
  fantasai: We don't limit ourselves in early drafts.
  Florian: At least this one and reduced transparency.
  hober: Editorial effort, if editors want to do that then great.
  Rossen: We're out of time.
Received on Wednesday, 16 November 2016 02:29:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:05 UTC