- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 21 Feb 2016 15:05:46 -0500
- To: public-houdini@w3.org
- Cc: www-style@w3.org
=======================================================
These are the official Houdini Task Force minutes.
Unless you're correcting the minutes,
please respond by starting a new thread
with an appropriate subject line.
=======================================================
Scrolling Extensibility
-----------------------
- rbyers presented a demo and the use cases that they're currently
considering for scrolling extensibility.
- Each of the use cases had follow-up questions, but no one
objected to the direction the spec if going in.
- RESOLVED: Flesh out the explainers for compositor worker.
Experiment more and share data.
Meeting Wrap-Up
---------------
- RESOLVED: Publish FPWD of Worklets Level 1
- RESOLVED: Publish FPWD of CSS Paint API Level 1
- The May meeting was discussed and most people wanted to meet
adjacent to the CSS meeting again.
- There's hopes that properties and values will receive FPWD
during the CSS meeting over the next few days.
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/css-houdini-drafts/wiki/Sydney-F2F-January-2016
Scribe: vollick
Scrolling Extensibility
-----------------------
rbyers: So I thought what would be useful was to talk about some
richer scroll customization use cases.
rbyers: I've written up an explainer that goes over the basics and
has some code.
rbyers: Finally, I've got at demo that I can show.
rbyers: We talked about scrollers with cw, but the key difference
with hidey bars is that you have to know about scroll state.
rbyers: There's a bunch of extra complexity with this, but I would
like to be able to be able to implement our "top controls"
this way, but it's currently really hard.
rbyers: Rubber banding is another interesting case. We're actually
changing how the scroll input effects the output (to
introduce drag).
rossen: How's rubber banding different than pull to refresh?
ojan: Is it a strict subset?
rbyers: Yeah, there's some fancier stuff you can do with p2r, but
we usually start with rubber banding as it's simpler.
rbyers: We tried to build a p2r component for the web that was as
good as twitter's native and could only get to 90% and
that informed our approach.
rbyers: For example, when you start showing the p2r affordance,
the metaphor is that you're pulling a spring.
rbyers: If you change direction and the thing that happens isn't
that the spring contracts, it seems unnaturally.
rbyers: So you want to have control over who the scroll gets
shunted to.
rbyers: We also want to be able to implement scrolling by
adjusting something other than scroll top.
rbyers: We want it like regular scrolling in how it composes,
flings, accessibility, but we want to drive a rotation.
rbyers: ..for example.
rossen: I can you show that demo.
rbyers: <shows the demo>
rbyers: Currently when people want to implement this themselves,
they have to re-implement the world in JS and is a part of
the reason we only get to 90%.
rbyers: There are other cases where we don't want to change how
scroll is applied, we want to redirect the scroll to the
right scroller.
rbyers: One case we hit was where we hit the bottom of a scroller
in a fixed:pos element and we don't want the bubbling to
start scrolling the document..
rbyers: We want to implement Microsoft's scroll chaining with
scroll customization primitives.
rbyers: Facebook says that they use wheel listeners _only_ for
this purpose (to prevent scrolling the wrong thing).
heycam: This could also prevent you from zooming in on your map.
rbyers: <presents a demo showing the android "tongue" that appears
when you overflow and shows how it needs to know where
your finger is to glow in the right spot>
rbyers: err, overscroll.
rbyers: This is the end of the use cases. There are also some
links to some other effects at the bottom of the doc (
added by Florian)
rbyers: Are we missing any cases? Are there cases we don't care
about?
<rbyers> Use cases:
https://github.com/w3c/css-houdini-drafts/blob/master/scroll-customization-api/UseCases.md
ojan: As I'm skimming through the use cases. p2r in particular;
I'm not seeing mention of the effect that appears as you
show the p2r affordance. Is that mentioned?
rbyers: No, it was missed. There's often a little twister or
something...
rbyers: <adds prose to the use case live>
ojan: There's a huge variety of things people do here, which is
why I bring it up. Maybe they shouldn't, but..
<rbyers> Explainer:
https://github.com/w3c/css-houdini-drafts/blob/master/scroll-customization-api/explainer.md
rbyers: So here's the start of the explainer.
rbyers: I'm linking to one popular library, iscroll, that
reimplements the world.
rbyers: This has these downsides. 1) no threaded scrolling. 2) not
hooked into assistive technologies. 3) it's possible to
get stuck in them (they don't compose).
rbyers: 4) doesn't feel native; doesn't match platform physics.
rbyers: For now, we're trying to build on compositor worker. We
think that this an orthogonal concept and that we should
be able to disable threaded scrolling.
rbyers: This is controversial and is currently out of scope...
ojan: Can I add something most UAs have both a main and scroll
thread so it has to work in both?
rbyers: The edge only has one path, right, but can be joined with
the main thread?
rbyers: It describes scroll intent, the thing that appears
directly out of wheel touch keyboard or scrollbar dragging.
rbyers: The intent has stuff like delta velocity phase etc,
florian: Does this include things that the user didn't do?
Programmatically scrolling something, for example?
rbyers: No. Initially we included things like scroll into view,
but it didn't help with the use cases.
rbyers: home/end are kind of special and we don't consider them a
scroll intent because they're absolute.
tantek: Arrows can be ambiguous, either scroll or something else.
<tantek> or directional navigation
<tantek> per CSS3-UI
rbyers: Don't worry too much about the details, but we want to
hook some custom logic that translates the scroll intent
into scroll application.
rbyers: Here's an example using the CompositorWorker placeholder
syntax.
rbyers: It describes a carousel example that takes the scroll
delta and applies it to the x rotation.
rbyers: We have an API that lets you report what amount of scroll
intent you've consumed.
rbyers: For example, we may want to shunt horizontal scroll to one
elem, but vertical scroll to another.
rbyers: Anyone have a question on the big picture, pulling out the
intent to scroll.
smfr: It seems weird that you manipulate the scroll intent. Why
not return the delta?
rbyers: Part of the reason is historical to support bubbling. but
if we start scroll latching, this may not be necessary.
rbyers: If we really do want to affect many scrollers,
conceptually, we want to imagine the scroll intent flowing
through the scrollers.
smfr: I think you could do something functionally the same by
returning the used delta.
ojan: Do you support changing velocity?
rbyers: We only support changing the delta currently.
rbyers: If we scroll by one pixel, do we really want to let you
scroll 100 and potentially show the top controls.
rbyers: So we've restricted it to be consuming an amount from the
given delta.
esprehn: Can you explain how p2r works in this model?
rbyers: There's a bunch of models, but in our primary demo, once
you get to the point that you show the affordance, we
transform the whole scrollable area..
esprehn: That will shift the scrollbar.
rbyers: Maybe that's not the right way to do it. Let's talk off
line.
esprehn: You want to show padding..
rbyers: We could imagine scrolling at 100 and then scrolling to
the top adds friction.
rbyers: Maybe the right place to start is rubber banding because
it's simpler.
florian: There's an interesting round display use case. The top is
narrow so you want to squish content at the top of the
display as it scrolls by.
ojan: That whole discussion made me wonder if we should just allow
negative values.
smfr: We report them but it sometimes causes problems because the
code doesn't expect it.
rbyers: If you opted in, might be ok.
ojan: In addition to that we could let it accept negative values
if you set it.
ojan: Don't see why not unless it's an egregious compat problem.
esprehn: Is there any standardization behind the Microsoft
properties?
esprehn: In particular the chaining one.
rbyers: We wanted to build it on the primitives, but if it was
urgent, we could implement it.
esprehn: Something as obvious as turning off chaining would be
useful, in addition to scroll customization.
rbyers: <prepares to show demo>
rbyers: <demo is of a cylindrical scroller that turns in response
to scroll>
rbyers: Notice that if you scroll in the y-direction, it scrolls
naturally using platform scroll logic + fling.
rbyers: Scrolling in x rotates the carousel.
rbyers: <steps through the code>
surma: By eating scroll x means you'll never "get to the end"
rbyers: Yeah, because we've reimplemented scrolling, we can scroll
forever in that direction.
rossen: And if you want to allow chaining...
rossen: For example if after 180 degrees you want to bubble.
rbyers: Yeah, you add a conditional to stop consuming deltas after
180 degrees and it will propagate.
smfr: Naturally you would want this to come to rest on a cat in
the carousel.
rbyers: Yeah, we haven't hooked snap points into this.
rbyers: We may be missing primitives about exposing platform
curves, but currently we just take over fling when it
starts.
smfr: But if you're combining this and scroll snap, which comes
first?
rbyers: There's interesting API decisions. We may have multiple
scroll modifiers. You may want the consumer to compose both.
rbyers: We have this problem with other Houdini APIs because we
don't have CSS compositor.
rbyers: That's about all I've got. Our implementation does have
some more complexity. "distribute scroll", for example,
which is related to scroll bubbling.
rbyers: The document passes the scroll delta to each scroller in
the chain so that they have an opportunity to act.
rossen: What happens if you call scroll to?
rbyers: It's not an overflow scroller, so as far as CSS is
concerned, it's not scrolling.
esprehn: If it's not scrollable how did it get scroll intents.
rbyers: By registering an apply scroll hook.
smfr: It's like a wheel event handler.
rbyers: It's similar but at a lower level.
rbyers: Our next steps for scroll customization and compositor
worker is to finish implementing scroll snap and position
sticky.
rbyers: We know there will be some overhead by using JS, but we
should be able to compare with native implementation to
gather any other numbers?
rbyers: Anything else you would like to hear?
esprehn: I'm interested in hearing your opinion smfr. You scroll
in the ui process, right?
smfr: Yes, this would involve going back to the renderer. It's no
different that compositor worker. I'm not overjoyed about it.
rbyers: Does it really have to be in the same process? It just has
to be typically in sync.
rbyers: You, e.g., control input on the ui thread.
ojan: < shared a potential bubbling eg >
rbyers: Since we have scroll latching on iOS, then we're only
going to be scrolling a native or a custom scroller.
ojan: Where do we chain today in chrome?
ojan: If we don't bubble, why consume at all?
rbyers: Some composition cases. eg, hidey bars. one impulse may
scroll a bit and the leftover may need to be sent to the
native scroller.
esprehn: My question is that it feels like we need implementation
experience. Our architecture is more amenable to this,
but could we in 6 months, say, could he do an
investigation?
smfr: It's more than an afternoon and couldn't commit in 6 months.
esprehn: The primary risk of this API that's ahead of its time
that may be unimplementable in another UA.
smfr: If we had to choose between this and compositor worker, we'd
probably choose compositor worker.
ojan: To judge the feasibility of our stuff, seeing CW would be
very informative.
rbyers: I guess we should just be explicit about a design that
could work in all the engines. And we would definitely
block based on your feedback if we needed changes to make
it more implementable in your engine.
rbyers: But generally our approach with this stuff is not to block
progress on the absence of feedback.
esprehn: AI: finish explainer to the point to where someone can
implement it.
rbyers: That's a spec?
esprehn: No, just something less handwavy than what you've got.
ojan: For interop, yeah, we need a spec. But for "could we ship
something vaguely like this" we need rough feasibility only.
esprehn: We need something where we can start to experiment. And
the feedback we're getting is that compositor worker is
the place to start.
smfr: We're much more likely to implement the small declarative
features that will fix existing content.
RESOLVED: Flesh out the explainers for compositor worker.
Experiment more and share data.
rbyers: Separately. scroll chaining might be something we just do.
rbyers: Let's bring it to csswg.
esprehn Do you know what it is?
smfr: Nope.
rbyers: <shows the -ms-scroll-chaining property>
ojan: <described how chrome latches on mobile since recently and
how chrome plans to move desktop to latching>
esphren: If everyone always implemented -ms-scroll-chain:none
always, we wouldn't need the property.
rbyers: Well, might be nice to have the ability to bubble if you
wanted, but we removed it and no one complained.
rbyers: The potential follow-up is that since this is potentially
crazy for safari, if you can think of other ideas for
stuff like rubber banding in a declarative way? A scroll
delta transformation function, maybe?
rbyers: This is a case that I'm less convinced that we need the
power of script.
rbyers: Maybe a couple of declarative properties and latching is
enough...
ojan: I guess we're mostly done talking about scrolling.
ojan: We may have beaten the topic to death, but I'd like to
understand the performance concerns with running script
async?
rossen: We're always worried about folks writing slow code. This
will always happen.
rossen: But, assuming a middle ground where things are written
"ok", the generic case.
rossen: Yeah, I don't think I can bring anything new that I
haven't said before.
smfr: I'm more worried about the setup and teardown of global
scopes than just the raw performance.
smfr: And the security concerns.
smfr: It couldn't fit in the UI process, so it couldn't be as fast.
smfr: You can't have executable pages there.
Scribe: rbyers
vollick: But if it was async, you could post to another process
right?
smfr: But doesn't CW require it to be synchronous with scrolling?
vollick: No, just best effort.
ojan: I wonder if we could consider having more limited global
scopes - could they be theoretically more efficient?
vollick: Hopefully worklets wouldn't be coming and going very
frequently.
rossen: OK, we're done then.
<gregwhitworth> https://github.com/w3c/css-houdini-drafts/issues/116
<iank> https://drafts.css-houdini.org/worklets/.
<zcorpan> iank: just filed
https://github.com/w3c/css-houdini-drafts/issues/120
<zcorpan> iank: i guess interface Worklet shouldn't have that,
though
Meeting Wrap-Up
---------------
<Rossen> RESOLVED: Publish FPWD of Worklets Level 1
<Rossen> RESOLVED: Publish FPWD of CSS Paint API Level 1
<dbaron> We discussed next meeting, seemed to want to meet in May
adjacent to CSS, and people seemed happy with May 12-13
adjacent to CSS being May 9-11. And Google was going to
look into Bay Area hosting
Scribe: dbaron
shane: On properties and values: dbaron convinced me about the
special animation step not being needed. I had thought we'd
need to alter the set of steps to run for resolving style
would need to be altered, but one of those 2 things happens
when triggering animation, not calculating current value,
so there's no inconsistency.
shane: The other thing is that animations and transitions already
state that custom properties with a type should be
animatable.
shane: The only requirement is that the properties are of one of
the animation types.
dbaron: I think they should explicitly state that they have the
animation type.
shane: I hope for FPWD candidate by end of CSSWG meeting.
<tantek> Thanks to Google for hosting!
Received on Sunday, 21 February 2016 20:06:46 UTC