- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 12 Nov 2018 19:22:50 -0500
- 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.
CSS UI
------
- 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.
===== FULL MINUTES BELOW ======
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
that
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
[presents]
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
cases
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
mode.
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
ranges
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
that.
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
CSS-UI
======
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
general
fremy: to decide to have dark form control
<tantek> reference:
https://drafts.csswg.org/css-scrollbars-1/#valdef-scrollbar-color-dark
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
about
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
info
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
forward
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
rings
florian: On the other hand, outlines are used for decorative
purposes all the time, and not having interop there is an
issue
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
precisely?
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
outline.
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
heycam
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
elements
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
fine
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
applicable
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
flexbox/grid
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