- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 3 Mar 2015 14:25:34 -0500
- To: public-houdini@w3.org
Input Extensions
----------------
- RESOLVED: rbyers, TabAtkins, marakow to work on CSS Scroll
Extensions
Asynchronicity and Threading
----------------------------
- There was some concern about if this would be in scope or if
there are the right experts in Houdini to make this spec
work.
- RESOLVED: Vollick, JacobRossi, (TabAtkins or Shane) to start
work on CSS async style
- The spec authors will work with webapps on portions that overlap
such as async DOM.
Houdini Process
---------------
- The group will hold off meeting again until there is more
concrete language to discuss and there is an agenda set.
- Priority order for decisions is that they will be made over
e-mail if possible, a telecon if e-mail isn't possible, and
lastly a F2F meeting.
===== FULL MINUTES BELOW ======
Scribe: jet
Input Extensions
----------------
rbyers: [on-screen demo]
<rbyers> Scroll sync test: http://tdresser.github.io/sync-scroll-offset-test/
<rbyers> Scroll header demo:
https://www.polymer-project.org/components/core-scroll-header-panel/demo.html
<rbyers> Scroll customization design doc:
https://docs.google.com/a/chromium.org/document/d/1VnvAqeWFG9JFZfgG5evBqrLGDZYRE5w6G5jEDORekPY/edit#
<rbyers> scroll-chaining:
https://msdn.microsoft.com/en-us/library/windows/apps/hh466007.aspx
rbyers: Following up on TPAC discussions,
rbyers: These are all experiments.
rbyers: My motivation is to enable native app scroll effects.
rbyers: I'm enabling customization to tweak scroll effects.
rbyers: Currently you have to extend input events to reimplement
scrolling e.g. <iframe> scrolls horizontally within a
container that scrolls vertically.
rbyers: The problems with things such as iscroll libraries is that
they don't feel "native".
rbyers: [demos scroll header (from Google material design)]
rbyers: [demos scroll offset test]
rbyers: [shows how native vs. JS scrolling fails to sync]
rbyers: The simplest solution: CSS scroll-blocks
rbyers: Currently it's on Chrome Canary
<rbyers> http://rbyers.github.io/scroll-blocks-on.html
rbyers: The demos are of different scroll-blocks settings.
rbyers: Chrome stops scroll blocking at 150ms.
rbyers: Threaded fast paths will be covered later.
rbyers: See CSS snappoints in IE, Gecko and Safari
rbyers: [demos CSS snap points]
rbyers: [demos JS implementation if snap points]
rbyers: You still need a hook when scroll happens (eg, setting
scrollTop)
rbyers: scrollState object (see doc)
rbyers: element.applyScroll = function(scrollState) enables snap
points.
rbyers: JS developer doesn't need to handle different devices,
rbyers: But complicated scenarios need more.
rbyers: For example, distributing scroll across multiple elements.
rbyers: See IE's scroll chaining for a way to do that.
rbyers: IE can selectively consume scroll events and not bubble up
events.
rbyers: distributeScroll( ) allows control for authors.
rbyers: We have 8 use cases to solve (as seen on native apps)
rbyers: 3 main capabilities...synchronize scroling, customizing
how scroll is applied, customizing how scroll is
distributed.
rbyers: Can we provide all 8 features, instead of 3 low-level
hooks?
rbyers: This proposed feature also explains what CSS does.
rbyers: These API's allow for customization over time,
rbyers: as primitives.
roc: You can't implement Gecko snappoints with this API as it
handles different gestures (not a generic scroll)
rbyers: scrollGranularity can potentially handle it.
roc: It's good that the API doesn't cover gestures.
roc: We want to be gesture-independent, but behaviors are gesture
dependent.
rbyers: We can differentiate between, for example, keyboard vs.
touch.
rbyers: distributeScroll = function(scrollState)
dino: Demo uses requestAnimationFrame( )?
dino: Does the top control needs to be aware of what scrolling
does?
rbyers: Yes, that's how it's implemented now.
dino: Twitter didn't modify system native scrolling behavior (on
iOS) for 'pull to refresh',
roc: Like they had to do in Android.
shane: This should allow override of system behaviors.
dino: Scroll effects can be so platform-specific.
dino: How do we make it so authors don't have to catch all those
cases?
rbyers: Enable 'pull to refresh' custom behaviors within native
scrolling logic.
rbyers: Pages that consume all touch events already override
native scrolling.
rbyers: This conceptual model should let us implement current
scrolling behaviors.
<rbyers> Scroll conceptual model:
https://drive.google.com/a/google.com/file/d/0B7mjRvOU-oG-anR5LVdQQ0xxbFk/view
rbyers: JS should be able to create the scrollState.
rbyers: Scroll bars are an open issue.
rbyers: Scroll bars don't distribute scrolling.
rbyers: None of this has landed in Chromium yet,
rbyers: We need to figure out threading.
dino: What's the fallback?
dino: How to use it and not break on other browsers?
rbyers: Sites already take advantage of Chrome's custom scroll
effects.
rbyers: polyfill on top of something such as a iScroll library.
krit: Are default scroll behaviors available? Like native defaults?
rbyers: Yes, as function attributes modify applyScroll, but can
call native implementations.
rbyers: Run in an isolated realm?
roc: No.
dino: yes!
rbyers: We need two ways: isolated (off main thread for
speed/safety) and not (main thread)
rbyers: Can we keep same semantics for compositor vs. main thread
usage?
rbyers: Can you transfer the scroll between the main thread and
the compositor thread (to prevent jank)?
rbyers: It's the same as Chrome does after 150ms of blocked
scrolling.
rbyers: You support scenarios like Google maps scrolling at 60FPS.
dino: How does the user handle cases for multiple devices (e.g.
can't do fast effects on mobile)?
rbyers: Maybe revert to native scrolling when performance is an
issue?
rbyers: mousewheel handlers are already implemented by sites (this
API is similar).
rbyers: Scroll deltas specified as CSS pixels?
rbyers: That's Currently implemented in dips (Chromium units).
Rossen: The next steps for this: find editors, draft a resolution
dino: Experiment/implement and report back.
rbyers: Prototypes are landing soon.
Rossen: fallback scenarios should be graceful
RESOLVED: rbyers, TabAtkins, marakow to work on CSS Scroll
Extensions
<bkardell> are there any plans to talk about style isolation here?
I mentioned it yesterday...
<jet> bkardell: not covered
<bkardell> not script isolation
<bkardell> or is that roc getting set up for next topic
<roc> nothing to do with what you said, sorry
<bkardell> jet: not covered as in not on agenda or out of scope?
<jet> bkardell: not in the next topic
<roc> I just wrote this as a summary:
https://wiki.mozilla.org/Restricted_JS_Execution_Contexts
<astearns> roc: for style extensions, is a new isolated world
needed for every property, or could a page have a
single world for all the registered properties?
<roc> astearns: ideally, if implementation allowed it, I think
we'd have an isolated world for every single parse and style
computation operation
Asynchronicity and Threading
----------------------------
<shane> vollick's doc:
https://docs.google.com/a/chromium.org/document/d/1wrBq3HMwxMTX521rE-qczF67YucdCRUsHuG3_oG5Cjw/edit
vollick: Asynchrony and Threads
vollick: Use cases: infinite scroller, components from untrusted
3rd parties, large team coordination on large apps,
material design "spinner" UI, synchronized effects (see
CSS Scrolling).
vollick: Performance componentization & performance isolation.
vollick: Web devs should be able to specify:
vollick: What can be asynch?
vollick: What can be deferred?
vollick: What can be preempted?
vollick: What's important on the page?
vollick: There's classes of solutions:
vollick: For example UI workers
vollick: Fancy Frames that can be asynch, preempt, detachable,
sandboxable, Delightful DOM with asynch mutation,
prioritized.
vollick: Wicked Workers (see doc), Snazzy Scheduler for hinting.
<bkardell> Yes please
vollick: Are people interested? To work on this in Houdini?
roc: DOM, frames, worker stuff are not appropriate in Houdini? DOM
experts aren't here.
Rossen: Can we invite them?
vollick: We need to involve the right people.
vollick: Please send me names.
rbyers: I have concerns about if main thread synch can be covered
by asynch proposals.
Rossen: Input and render parallelization in IE don't work as well
on low-end devices.
Rossen: Scheduler work should be prioritized.
vollick: For adding capabilities to workers, is spec needed?
roc: WHATWG canvas in workers spec exists.
<roc> I think this is the link, but it's not loading for me:
http://wiki.whatwg.org/wiki/WorkerCanvas
<dino> what about this one?
https://wiki.whatwg.org/wiki/CanvasInWorkers
<roc> hmmm.
<roc> dino: I think https://wiki.whatwg.org/wiki/WorkerCanvas is
the consensus proposal.
vollick: We need worker threads that can affect paint,
vollick: Such as motion blur on scroll.
rbyers: Synchronized Scroll (allowing JS to synch with main thread
scrolling).
rbyers: Asynch DOM sounds like low-hanging fruit.
vollick: The spec should articulate what can be asynchronous (but
not spell out thread creation details from engines).
rbyers: Ordering of events, etc. is currently browser-specific.
rbyers: The spec could specify how authors can modify that.
Rossen: We some initial ideas for initial spec-ing now
Rossen: Let's socialize these ideas with other groups (UI workers,
asynch DOM).
shane: asynch DOM needs to work out how it affects Layout.
shane: Let's start a draft here (in Houdini).
Rossen: Start with UI workers?
vollick: The features are orthogonal.
shane: We should resolve to work on it here or elsewhere
krit: Let's come up with a proposal first.
RESOLVED: Vollick, JacobRossi, (TabAtkins or Shane) to start work
on CSS async style
<rbyers> They will talk to webapps on the other bits discussed
(e.g. async dom)
Houdini Process
---------------
Rossen: How often should we meet/discuss?
<bkardell> f2f is pretty hard for me unless you all want to come
to my house or open a bridge :)
glazou: F2F meeting joined with CSSWG worked well here.
glazou: Doing that with the NYC meeting is harder.
glazou: Maybe it's better for the meeting to be after? Due to
budget constraints.
glazou: And once or twice a month we can do a telecon.
Rossen: Additional days before or after CSSWG F2F meetings helps
travel.
<dbaron> FWIW, this meeting was announced (without firm dates) 2
months in advance and didn't have firm dates until 2
weeks later.
<bkardell> There is an extensible web summit in San Francisco in
April - lots of people should be there + tag, maybe
good optional thing?
SimonSapin: Maybe we should do async decision making instead of
telecons/F2F?
dbaron: We should have docs to discuss before scheduling meetings.
dbaron: We need more concrete stuff for the next time.
Rossen: To move from "can" to "do" phase, yes.
rbyers: Do we propose Houdini agenda prior to scheduling CSSWG
meetings?
dino: For Houdini it's more important to synch with CSS than,
say SVG.
Rossen: Let's check back in a month before scheduling telecons?
ChrisL: Schedule a monthly telecon now, but assume canceled unless
an agenda is set.
SteveZ: And make every effort to resolve on e-mail and not telcon.
SteveZ: Email, telcon, F2F as priority order for communication.
Rossen: We're adjourned.
* bkardell claps
glazou: Thanks Google Sydney!
Received on Tuesday, 3 March 2015 19:26:05 UTC