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

[CSSWG] Minutes Lyon F2F 2018-10-22 Part V: Scroll Linked Animations, CSS UI, Review HTML fieldset/legend spec [CSS-UI]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 12 Nov 2018 19:22:50 -0500
Message-ID: <CADhPm3vQsXMDGmqsWp4FJtJnf0vjdPeZuFL1nOFbKnjmbWZLCA@mail.gmail.com>
To: www-style@w3.org
Cc: majidvp@chromium.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

  - majidvp brought to working group up to date on the WICG work for
      scroll linked animations (https://wicg.github.io/scroll-animations/ )
      and showed a demo which also used the animation worklet
      (https://scrolltimeline-playground.glitch.me/ )
  - There was interest in having this work continue and a few browsers
      said they were either looking at it or that it was on their
      backlog to review.
  - Being able to do simple use cases for scroll linked animations
      without any JavaScript is an important feature of this spec to
      working group members.
  - There is a need to put in the spec guidance to help authors avoid
      some issues/pitfalls. Ones mentioned were to make sure time
      ranges weren't too small, use default arguments, and to enforce
      respecting the prefers-reduced-motion setting from users.


  - There was interest in developing a method to let authors opt in to
      having a set light/dark mode which covered scroll bars and form
      controls, but didn't bleed into iframes.
      - Concern was raised that this is similar to the system colors
          created in 2002 and since deprecated- if this is done it
          needs to not have the same problems.
  - florian will investigate adding more specificity to the defined
      outline properties while having 'auto' still allow UIs
      flexibility as a part of his work on UI4. (Issue #3184)

Review HTML fieldset/legend spec

  - There were concerns about introducing new properties and values
      that would allow arbitrary elements to be styled like fieldsets.
  - zcorpan will look to see if all the comments in github from
      fantasai have been addressed.


Agenda: https://wiki.csswg.org/planning/tpac-2018#schedule

Scribe: myles

Scroll Linked Animations

  <smfr> https://wicg.github.io/scroll-animations/
  majidvp: I want to keep this at a high level. Background: it's in
           WICG. We have in Chrome an experimental implementation. I
           want to inspire people who are experts on overflow to look
           at the spec. I hope we can turn the experimental
           implementation to be shippable in the near term. It's
           useful for web authors in general.
  majidvp: here are some demos
  <majidvp> demo link: https://scrolltimeline-playground.glitch.me/
  <surma> the demos require Chrome Canary + Experimental Web Platform
          flag on chrome://flags

  majidvp: The proposal for scroll linked animation was in 2014 by
           dino. Since then there has been interest from Mozilla and
           Chrome. Moved to WICG. Take a scroller and the scroll range
           to the scroller and map it to time. Then you feed it into
           the animation system. Then the animation is driven by the
           user scroll. It's declarative, so browsers can run it on
           their fast path. The effect can remain in sync with the
           scroller. Our implementation, we have a subset that's
           implemented. The simplest example is parallax.
  majidvp: It's synced with the scrollbar.
  majidvp: It's implemented with 2D transform. Most people listen to
           rAF and look at the scroll position and change style. But
           our example runs on the compositor thread, so it's fast.
  majidvp: Here's another example: you have something that translates
           on the horizontal axis as the user scrolls.
  majidvp: It is very simple.
  majidvp: Similar, here's another example: you swipe, and the bottom
           and top has some sort of fade and scale, and it's in sync
           with the scroll

  majidvp: Let's look at the simplest implementation.
  majidvp: How does it work?
  majidvp: Let's start with the animation. Our implementation was done
           for animation worklet, so ignore the first 2 words (About
           worklet animation and pass through)
  majidvp: So it's like a worklet.
  majidvp: The keyframe and scroll timeline is interesting. Usually
           it's the document time, but this is a scroll timeline!
           you're mapping a scroll source (my scroller) and the full
           scroll range to a time, with is 1000 ms. So scroll offset 0
           to max is time offset 0 - 1000 so I have a duration from my
           keyframe which is 1000, and the animation translates from
           y=0 to some negative value.
  majidvp: As I scroll from 0 to maximum, the background translates
           20% of the amount, giving you parallax
  majidvp: Doesn't have to run on the main thread, no event handlers,
           and it's simple and declarative
  majidvp: A scroll linked animation, in the spec, has a CSS syntax.
           We haven't implemented that, so I don't have any feedback.
           The basic feeling is that it works pretty well
  majidvp: questions???

  majidvp: We noticed during implementation that the spec hasn't
           throught about writing modes and directions
  majidvp: Normally when you change writing mode or directions, the
           scroller changes. Normally the horizontal scroller goes
           from left to right, but if the writing mode is RTL, the
           scroller is reversed.
  majidvp: The physical scroll offset (Scroll left and scroll top)
           when you switch the scroll direction, they stay the same.
           So my scroll right would be the maximum value and as I
           scroll it goes to 90 **0
  majidvp: The scroll timelines should be logical. So when you change
           the scroll direction to be RTL, you want the effect to
           match that
  majidvp: The current time should match the scroll origin, not the
           physical scroll offset
  majidvp: The spec doesn't talk about that but I have an issue
  majidvp: As you change writing direction, the timeline will match
  majidvp: Please look at the spec and find other issues!
  majidvp: Another implication: say you want to translate something

  jensimmons: Question: are you proposing a CSS spec that works with
              CSS & HTML only, or are you proposing new CSS which
              requires JavaScript?
  majidvp: The spec has syntax so it works for CSS only, so you could,
           according to the spec, there's enough syntax for CSS. We
           haven't implemented it yet.
  jensimmons: I think it would be great to make sure that use cases
              are easy to do in CSS-only. More complicated things can
              require javascript
  majidvp: Yes. I'll show you the syntax.
  <surma> +1 to Jen’s comment
  <tantek> +💯 jensimmons "would be great to make sure that use cases
           are easy to do in CSS-only"
  jensimmons: getting rid of the JS is the most exciting part.
  <fantasai> +1 to Jen's comment, too :)
  majidvp: The spec says: what you want to do is to link your
           animation to a particular scroller. Here's an example
  majidvp: The interesting bit is the animation timeline which is
           specifying that this is a timeline that is based on the
           scroll offset of a certain element. It has vertical inline,
           and the two values at the end are the start and end offset,
           so you can be linked to a portion of the scrollbar instead
           of the whole scrollbar. We haven't implemented it. Please
           give feedback. e.g. how do you guarantee it only selects a
           certain element, what do you do when that element goes
           away. When we implemented the Javascript, we found corner
  jensimmons: Does it require pixels or do ems work?
  majidvp: ems work

  heycam: Some people think / say that the use cases that scroll
          linked animations can solve are good enough that we don't
          need the animation worklet stuff. You have experience with
          both. What are your feelings?
  majidvp: We haven't done the integration of a scroll timeline into
           web animations. The demos use animation worklet.
  majidvp: Many effects can be achieved without animation worklet. But
           animation worklet is more expressive. You have a state and
           conditions and you have the power of script.
  majidvp: It gives you power to do the other 20% of animation like
           pull to refresh.
  majidvp: It needs the scroll offset and the state (direction of the
           scroll and the last state that was action)
  majidvp: Also scroll to action. I understand we want to enable
           declarative stuff, but there are a whole bunch of effects
           that are not possible there. They should be possible.
  majidvp: The other thing is scroll-linked that's stateless, do we
           want to enable animation work and touch other interactive
           effects that you're currently only able to do on main
           thread. Like multi-touch effect. Drag and drop, throw
           something away, physical effects. We want to be
           declarative, but it doesn't scale well. Animation worklet
           lets you do scrolling effects, the 20% that's stateful, but
           also lets you do more sophisticated like scroll, gesture,
           etc. They are complementary

  jensimmons: It would be great if there was a way the spec mandated
              that websites obey the user's prefers-reduced-motion
              setting. If devs (or their bosses) wants to override the
              user's preference, they can't.
  majidvp: If we want to do that, it's better suited to web
           animations. Here, we're just adding a new timeline. The
           timing model lives inside web animations.
  florian: prefers-reduced-motion is not prefers-no-motion. Subtle
           animations should be able to remain. Turning everything off
           is too big of a hammer
  jensimmons: I don't know about the details. Let's not bikeshed right
              now. CSSWG needs to enforce prefers-reduced-motion in
              any way we can

  majidvp: Interesting: a scroll timeline should respect the writing
  majidvp: However, the second part is most animations that people
           write today are transform animations. Transform is a
           physical property. So we're mapping logical input to
           physical result. It doesn't work well. An interesting idea
           would be to have a scroll timeline that works in logical
           direction for transform. Maybe transforms should have a
           version that is logical.
  majidvp: transform-inline and transform-block rather than
           transform-x and transform-y
  majidvp: Just ideas.

  fantasai: A few thoughts...
  fantasai: For the CSS property, we try not to have positional
            syntax, even inside functional notations. Instead we use
            the usual value definition syntax, and rely on types to
            organize syntax rather than ordering.
  fantasai: You probably don't need to pick the scroll by id selector
            if you default to the nearest scroll container. Then scroll
            can be a keyword. Or maybe it takes a time range argument.
  fantasai: When we have percentages or lengths, that allows you to
            handle animation triggers when you know exactly where an
            item is, like a scroll animation to trigger when it comes
            into view.But we want to encourage people to make
            resizable webpages. Using fixed lengths is not a good way
            to do it. Maybe we can re-use the scroll-snap properties
            to map elements to scroll positions. "this is what it
            means to be 'at that element'". And then that becomes a
            time point along the scroller, which has a length along
            with it, but the author doesn't provide the length, we
            calculate it for them. Then the author doesn't need to use
            fixed layout or a bunch of JS calculations to make the
            animations respond to the position of content.
  majidvp: yep.
  majidvp: The problem of depending on the size of the scroller, and
           percents currently are relative to an element, some effect
           depends on the percentage of one, and some depends on
           offset. So similar syntax to snap points are okay
  fantasai: You can reuse those properties, you just have to reference
            the element. "the offset I'm interested in is when 'this
            element' is in its snap position, whether or not snapping
            is turned on'

  majidvp: Another issue is sometimes because this API maps a scroll
           range to a time range, the time range could be selected by
           the author, if you specify your time range to be small, you
           can have quantization error. 1000px maps to 1ms, most
           browsers will lose precision if you're not careful
  majidvp: Maybe there is a solution to reduce the foot gun
  fantasai: If you don't provide a time range, what happens?
  majidvp: By default the timeline takes the largest time range of the
           associated animation. So animations have duration, it uses
           that. It's a good thing.
  fantasai: Yes.
  fantasai: Encourage people to use default arguments; and put a note
            in the spec warning authors not to use too-small time
  majidvp: I'm not an editor of a spec, so I'm going to try to talk to
           editors and encourage them to move it to CSSWG so more
           people look at it

  majidvp: I also want to ship a subset of this. Now it has CSS and
           WebIDL. A practical subset of it. It could be useful.
  astearns: When you say "ship" what do you mean
  majidvp: Right now you can do an origin trial for animation worklet.
           M71 - M73. The earliest time we could ship something is
  majidvp: As we implement we find corner cases, and I'm hoping there
           are good solutions. So I need more eyes on this.
  majidvp: This proposal has been started since 2014
  majidvp: I really hope to get some traction. We have the only
           experimental implementation. Firefox have some patches but
           they haven't landed. Original proposal from dino had an
           implementation in Safari
  majidvp: So the only real one I know of is ours
  smfr: webkit's implementation you're talking about is "scroll
        triggers" but we removed the code because we didn't advance it
        in a while. We like this proposal. I want to explore "scroll
        triggered animations" because it's interesting
  majidvp: There are 3 types of scroll animations. 1) moves as you
           scroll, in sync 2) triggered by scroll, when you reach a
           scroll offset, but the animation is time-based. The spec
           has both but we removed scroll triggered animations.
           Motivation: scroll linked animations are the ones you want
           on the fast path. The one that is exposed to the main
           thread is asynchronous and it's best effort, so it's
           difficult to get in-sync scrolling. For triggers, as you
           hit a point, you start something that's time based. That
           could be done on the fast path. Your start point could be
           delayed. It's not the end of the world. For those use
           cases, it's fine to have a scroll event and then trigger
           the animation. That's why the editors removed that in favor
           of the first kind. I'm not opposed to fitting that model in
           here. Just wasn't as important performance-wise
  smfr: The biggest challenge for scroll triggered animations is how
        to describe them declaratively

  gregwhitworth: We are interested. We have an engineer reviewing this.
  gregwhitworth: By "We" I mean "Edge"
  heycam: For us, Brian and Botond would like to get back to this and
          push it forward again. It's not in our short-term, it's in
          our backlog, but with renewed interested form other parties,
          it would move up
  majidvp: I'm very excited there is interest.
  majidvp: Thanks.
  fantasai: It's a great idea, would be happy to have it in the CSSWG
  smfr: I want to draw attention to the proposal for logical
        transforms. Big change. Transforms 3 to figure it out????
  astearns: woop woop

  scribe: fantasai

Dark Mode

  fremy: Last time introduced MQ for others to detect dark mode
  fremy: When we introduced, seemed highly requested and useful idea
  fremy: But I've been working on form controls lately, and one of the
         big issues is they are not stylable and not interoperable
  fremy: Obviously we want to make things better
  fremy: But it's annoying that you can detect dark mode, but can't
         switch controls from light to dark
  fremy: Most platforms these days have native dark theme controls
  fremy: When I was reviewing spec for scroll bars, one property we
         introduced was proposing to introduce dark scrollbars
  fremy: Was thinking maybe we should generalize to form controls in
  fremy: to decide to have dark form control
  <tantek> reference:
  fremy: My proposal is to have just like scrollbars,
  fremy: dark controls vs light controls
  fremy: Wanted to see if other people were thinking about this
  fremy: thought it was a good or bad idea

  smfr: Definitely thinking about how authors can tell browser that
        they have designed for light mode or dark mode
  smfr: Form controls is part of that, but also focus and other things
  smfr: Want a way for author to tell us if they designed for light
        mode, dark mode, don't care
  smfr: Also some UAs may want to automatically invert colors on the
        web page
  smfr: We do this in our email application
  smfr: So do we allow authors to request dark mode? Allow authors to
        optin somehow
  smfr: Use a media query?
  smfr: There are some conflicting desires
  smfr: We would like authors to say "I have designed this page with
        light and dark modes in mind..."
  smfr: Maybe a CSS property, color-scheme: light || dark
  <tantek> "Allow authors to opt in somehow" sounds like a media query

  <AmeliaBR> Many browsers have different form styling defaults iff
             the author has not set key styles. So in that case, I
             would expect the browser to use their dark UI versions.
             But I really like the option of being able to set (as an
             author) appearance: dark
  <AmeliaBR> (Wouldn't necessarily be for the entire page, could be
             for a section.)

  smfr: We're not sure that web authors should be able to have a
        mixture of light and dark controls on the same page
  smfr: Also acknowledge that pages can have iframes, don't want to
        propagate into iframes
  smfr: So proposal for a property
  smfr: inherited, overlays with appearance, tells us which theme to
        use for form controls
  smfr: Another version is a meta tag
  florian: no, no no
  smfr: And we have to figure out how the opt-out works
  smfr: How does author say "please don't darkify my colors"
  smfr: "please don't invert my content"
  fremy: Think automatic inversion is not something we're concerned
  fremy: Maybe it's a meta info in the email header
  fremy: For websites, I really like the css property and I like the
         way you phrased it
  fremy: List all the themes you support, if you support dark thing
         and os is in dark mode, you'll get dark controls/select/etc
  fremy: ...
  fremy: Seems reasonable/sensible to me
  fremy: If you want to work on, or I should work on?
  fremy: Don't want to duplicate work
  fremy: I know we're not discussing on scrollbars, but they have
         similar issues
  smfr: For scrollbar property, we have heuristics that look at body
        background color
  smfr: If author has a preference on theme, we'd use that for scroll
        bars. Can override with scrollbar-color property
  krit: What about themes that are between light and dark
  fremy: That's why you list all the themes you support
  fremy: Maybe have a list in preference order?
  * fantasai notes https://drafts.csswg.org/css-forms/
  Rossen: High contrast mode, dark mode gives you dark color. High
          contrast feature specifically targets ensuring sufficient
          contrast between foreground / background
  Rossen: Because of that premise, we'll go to extent of changing all
          bg and foreground colors to match OS scheme
  Rossen: In order to allow web authors to take things in their hand,
          we have a high-contrast-adjust: none property
  Rossen: This element and its subtree will be in control of the user
          and they can specify whatever colors they need
  Rossen: It's something that was requested, to get OS colors
  Rossen: Say I can do a good job of using them where I need to
  Rossen: Why I was discussing env() spec to see where this is going
  Rossen: Ideally expose some variables that will reflect bg and
          foreground colors at least
  Rossen: And then control parts could internally be using environment
          variable color as initial value
  Rossen: And then we don't have to specify the override properties
  Rossen: Much rather go down that way for all of these controls
  smfr: Our use case is trying to preserve intent of the author
  smfr: yours is match the os

  dbaron: Some of what Rossen said sounded very familiar in that we
          had system colors in CSS2 in 1998
  dbaron: The ones in CSS2 were copied from the Windows API at the time
  dbaron: I made some proposals in 2002 to extend the set to work
          better on other platforms
  dbaron: But some of what you're asking for is something we already
          have and decided to deprecate
  dbaron: So it makes me wonder what we're going to do better this
          time and why we want a new version of the whole thing
  dbaron: I've also been thinking a little bit about form controls
          since I know in the past, Gecko had done more to try to
          honor whatever the user's native theme actually was
  dbaron: The end result was that users with dark themes got web pages
          that didn't work very well
  dbaron: This might be a way out of that, but not clear to me how
          light/dark choices interact with user's choice of them
  dbaron: and whether there are good APIs for this
  dbaron: If OS APIs moving towards being able to tell light vs dark,
          or if moving towards no choice other than light or dark...
  dbaron: Not clear to me what the OSes are doing
  smfr: For us it's just light/dark
  smfr: Be interested to know other OSes
  dbaron: Desktop Linux has a very powerful theming system, so can get
          just about anything

  astearns: Do you have something we can move towards,
  astearns: Accessing specific colors to match OS colors seems out of
            scope for this discussion
  astearns: Anything more to discuss about the author specifying how
            to handle light and dark and letting UA to deal with that

  fremy: I'm OK
  fremy: I think we have enough to move on from now
  fremy: Will come up with a more concrete proposal
  fremy: Wanted to see if there was other interest, agreement on way
  dbaron: One of my concerns is making sure that other browsers have
          the ability to use the necessary OS APIs to get this
          information out
  dbaron: Whatever you depend on should be on documented exposed APIs
          on Windows and Mac
  fremy: For us it's a requirement, so yes

  astearns: Anything else?
  astearns: OK, close this topic

Defining Outline
  github: https://github.com/w3c/csswg-drafts/issues/3184

  florian: Outline property is quite loosely defined, and to a certain
           degree intentionally so
  florian: There's a design reason and a process reason
  florian: Design reason is because outline is used for focus, and we
           didn't want to constrain too much how UAs draw their focus
  florian: On the other hand, outlines are used for decorative
           purposes all the time, and not having interop there is an
  florian: Process reason was that for L3, we were trying to wrap up
           and didn't have a clear proposal or interop
  florian: So question is, now in L4, do we want to define this more
  florian: Should we pick a behavior and have everyone conform to it?
  florian: Or are we still thinking we don't want to constrain the
  florian: Wanted to see where the WG stands on these types of issues
  florian: Should we try to constrain and find inteorp, or leave open
           to experimentation by UAs?

  smfr: Special behavior in webkit only happens on auto style
  florian: That could be a reasonable compromise
  florian: Let auto do whatever, then gradually narrow down behavior
           of the rest

  florian: Specific issue triggering this discussion was raised by
  florian: Seems like you have some interest in increased interop?
  heycam: Even if we didn't get to a world with mandated behavior,
          would be helpful to have more guidelines on which boxes
          contribute to the outline rectangle

  florian: Was contacted by person from Google who works on this
  Aleks: I'm implementing this, so that's my interest. My take on
         outline, I talked to fantasai about them
  Aleks: There was a difference for us between focus outline and css
         outline, and that was annoying
  Aleks: Would be nice to define whether focus and css outlines are
         the same or different, and if different then define css
         outline strictly for interop
  Aleks: When you're tabbing through, you get the "tabbing outline"
  florian: If you put 'outline: auto', do you get the same outline as
           the focus outline or something else?
  Aleks: That's a weird edge case in my opinion
  florian: Current suggestion is to allow UA to do whatever for 'auto'
           style outline, and otherwise tighten up what the outline is
  florian: So I think that's a direction we can look into
  <tantek> outline was always intended to represent the focus outline,
           period. and if there's been a divergence it's because
           implementations were lacking, likely unintentionally.

Review HTML fieldset/legend spec
  github: https://github.com/w3c/csswg-drafts/issues/3094

  zcorpan: A few weeks ago I did a project to specify rendering model
           of fieldset
  zcorpan: There's active implementation in gecko and chromium
  zcorpan: Remaining issue is finding a way for web developers to turn
           off the rendering model that fieldset employs
  zcorpan: There was a proposal to use -webkit-appearance for that,
           but would be open to other ideas

  florian: I remember fantasai filed a whole pile of issues against
           your spec
  florian: Have they all been resolved?
  fantasai: You got rid of the legend property?
  fantasai: I don't think there should be one
  zcorpan: We can look into that

  TabAtkins: We don't have opinions against or for 'appearance'. Do
             have an opinion on whether it should work on random other
  TabAtkins: If there's a case of "this is how it's turned on to
             fieldset/legend, and here's how to turn it off" that's
  zcorpan: Enabling on random elements was more of a side effect, not
           a goal
  zcorpan: I'm also working on appearance property, and don't think
           it's a perfect fit for fieldset
  zcorpan: It doesn't affect layout on other elements, just changes
           what's rendered, typically
  zcorpan: So would be open to probably adding new properties for
           opting out to the layout model for fieldset

  fantasai: I don't want to add to new properties that opt into a new
            useful layout model, but only work on one element
  fantasai: If the goal is to only have a switch that work on certain
            HTML element, appearance seems appropriate.
  fantasai: If we make a new property, it should be generally
  florian: +1
  zcorpan: So do we want it to be generally applicable, or do we want
           it to be limited?
  florian: The somewhat quirky version that's applicable to HTML is
           not nice to generalize as-is
  florian: IIRC it does strange things to borders
  fantasai: But isn't that what makes it special? Otherwise just use
  zcorpan: There are various interesting layout effects, but main
           thing is placement over the border
  florian: Clipping border is kinda weird
  fantasai: Seems reasonable to me

  fremy: Introducing a lot of stuff for this, and MS and Google agree
         that we don't want to add a generalizable thing.
  fremy: Agree with fantasai, that if we're just trying to define for
         fieldset it's too much
  fremy: I'm not even sure we need a way to turn it off, because why
         would you use fieldset if not for that rendering
  fantasai: Because fieldset has specific and useful semantics in form
            controls that you may very well want, but that doesn't
            mean you want that particular rendering model
  fremy: The reason is that it makes forms more accessible to people
         with AT
  astearns: Sounds like y'all should have a hallway conversation or
            something, 'cuz we're done for today.

  [Meeting closed]
Received on Tuesday, 13 November 2018 00:23:44 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:09 UTC