- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 7 Nov 2015 09:50:55 -0500
- To: public-houdini@w3.org
Scrolling
---------
- A group has been working to map the current scrolling effects on
the web in order to enumerate all the variants in hope of
getting to a common set of declarations to allow control.
- There is both a desire to build a full declarative model and
concerns about running a script on the page, so dino has
worked out a demo that is mostly defined by web animations.
However, they still need to discover if it covers all the use
cases.
Typed OM
--------
- shane requested feedback on the section he's added about
Transforms.
Worklets/Whatever They're Called
--------------------------------
- iank reviewed his changes to the spec including a large section
of non-normative text.
- Since other specs are moving to using Classes, that approach
might be worth investigating for this for consistency's
sake.
- RESOLVED: Call them "Worklets".
Next F2F
--------
- The meeting is on 30 and 31 January and it was agreed two days
is enough.
- In the time before Sydney, shane will set up three telecons. One
will be to discuss the umbrella explainer document, one for
the Box Tree API, and one for the Parser.
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/css-houdini-drafts/wiki/TPAC-F2F-October-2015
Scribe: iank
Scrolling
=========
dino: My memory is terrible.
dino: smfr & myself had meeting with vollick & rbyers about Async
Style.
dino: Started enumerating all of the crazy scroll things on the
internet / apps, with the goal of getting a subset which we
can describe declaratively.
dino: Parallax is very simple with a simple linear or functional
mapping.
dino: There are more complex ones like pull to refresh, <state
issues>.
dino: It ranges from easy to hard, trying to work out a way to do
this declaratively, i.e. through web animations, to set them
up and perform on the compositor thread.
dino: We're getting lots of requests from our designers, like
update a current time of a video, use it as a mask, to draw
an element,
dino: 3d reveal use case, changes lighting.
dino: Animations here aren't necessarily tied to scroll, they
might drift a bit.
dino: It's not just scroll that we want to provide, but the
pressure, or touch input.
dino: Google use-case here was sidebar.
dino: They (rbyers & vollick) seemed to be keen to try and build
the declarative model.
dino: Something that we've said many times fearful of running
script.
shane: ojan and shane were similarly minded about this.
dino: You said that you had a demo with just a little bit of state
on the main thread.
<dino> Where the demo was mostly defined by web animations.
shane: It's low hanging fruit at the moment, but need to do the
exercise to see if it covers everything.
shane: Not saying no to full API yet.
Scribe: TabAtkins
dino: Our main motivation is that we've talked to our UI
designers, who spend time doing interesting things with
touch and gestures, etc.
dino: We've found when implementing the things they do, it's very
hard to get these things right.
dino: The more the system can fill in the gaps -- If they up-front
describe what they want to do, we can better detect when
they haven't thought of something.
dino: Internally we're developing tools that model these
gestures/interactions as state-based things, rather than
doing mockups and having someone program them.
dino: We spent so much time tweaking details of the effects, it's
now easier to build the tool they can build effects with,
which is almost purely declarative, so they can see the edge-
cases and tweak things themselves.
rossen: What's the current state of IsolatedWorkers?
iank: It's on GH under "Processors" right now.
shane: We'll need a bikeshed session to get a working title.
Typed OM
========
shane: I've added a section to typed OM that talks about transforms.
shane: I'd like comments.
shane: I'll continue adding new sections.
shane: What should I do? Email public-houdini?
rossen: You don't *need* to.
shane: Right, I just want review early so I can backtrack quickly.
dino: Don't like a/b/c/d/e/f, do m11, m12, etc.
shane: or r1c1?
TabAtkins: Keep it consistent with the existing matrix, please.
TabAtkins: So I think it's cool to ping the list, but remember to
direct feedback back to github.
dino: It's okay to call something matrix and scale... we're not
actually exposing?
shane: Can we put those on the CSS object?
TabAtkins: That's what it's for, please do so. It's meant to allow
short, easy names so we don't have to spend characters
disambiguating.
TabAtkins: Bug Heycam about how to do it - you need to do like
"partial interface CSS" for it, and attach the
constructor there.
shane: With the transform stuff, I tried to cut down on options by
collapsing translateX/Y/Z to one, etc.
dino: I like that, yeah.
shane: If you get one out of the OM, it'll stringify to the
specified transform functions.
shane: If you create new ones, it'll always serialize as a
canonical representation.
Worklets/Whatever They're Called
================================
Spec Overview
-------------
iank: I wrote a big slab of non-normative text at the start to
explain what I want the spec to eventually say.
iank: Sorta says it now.
iank: The global scopes of the processors are thread-agnostic.
iank: Not defined to run on a particular thread.
iank: For us, we can run paint on the main thread, Servo can spin
up N on different threads, if we have script on compositor
thread, etc.
iank: They run wherever the UA decides they should run.
iank: The other big property is they have multiple global scopes
associated with one processor.
iank: We'll need to have a discussion about this and randomness/etc.
iank: If you're multi-threaded, you can run the same script on
both, and feed callbacks to them randomly.
iank: Or always run a fragment in one.
iank: It should have a nice property of authors not depending on
the ordering of different UAs.
iank: If Blink paints elements ABC, and other UA paints it CBA,
and the painter from C depends on info established from A...
iank: If we have two globals, and we run them randomly, you can
never *rely* on C getting info from A.
iank: We probably want to require at least two globals and require
random assignation.
SimonSapin: One request is to pick a name and stop changing it. ^_^
rniwa: Because the method to register a paint class is on the
processor context, it appears to me that when we
instantiate this thing, the author needs to raise the class
again...?
iank: You just get one reference. There's 1-many between processor
object and the number of global scripts.
iank: So if you import a script, it gets loaded into all the
globals.
iank: So you register all your paints initially, and then they're
all registered.
rniwa: But you said you want to be able to tear things down,
right? Then your import is gone.
iank: The spec says you must keep the results of loading the
script around. So you can kill, then load it back up.
rniwa: Then why do you need class at all? You can just store
things on the global.
iank: Ergonomics. It gives you an init() method.
iank: Feedback from Paris that people wanted that to set up some
info.
rniwa: Assuming ES6, if this is a module, you can set up whatever
you want there.
rniwa: I'm unsure what ergonomics you have. When you create the JS
file, every time you kill and regen, you immediately load
the class again.
iank: But you want an instance per fragment for layout.
iank: For paint, we can go wider. But you need class per fragment
on layout.
rniwa: In the Paint API spec, it checks props on class, then store
the methods. I don't think we want to do that.
rniwa: If you modify a method, it won't do be affected.
iank: I think it actually looks up methods each time?
iank: Yeah, it does. Specified here.
rniwa: But in Paint spec is does check that the things are methods.
iank: Just to check the shape at register time. You can swap out
the methods still.
rniwa: Custom Elements are planning to use class, maybe Shadow DOM
too.
rniwa: We probably want to be consistent here. If one spec checks
shape, another doesn't, will be confusing.
rniwa: Perhaps is something to be discussed wider, maybe specced
in WebIDL.
iank: I agree.
iank: Custom Elements grabs the callbacks at reg time, and then
call them with the `this` value later.
rniwa: Right. We don't want to do that, either ^_^
rniwa: So good to do this in one place, like WebIDL.
TabAtkins: There's gonna be a Custom Elements F2F soonish, we can
discuss this with everyone there.
iank: So back to the top. It's callback based, it has a reduced
API surface relative to workers.
iank: [says something wrong about lifetime]
rniwa: Feel the terminology might be wrong, but I'm not annevk. Is
bz in this yet?
iank: Not yet.
TabAtkins: But Anne explicitly told us to hook him in soon.
rniwa: This looks like it might be in the Web Platform WG.
TabAtkins: Yeah, we agree.
iank: AudioWorker VideoWorker others probably want to use this too.
iank: A lot of this is left up to the UA.
rniwa: [something about needing an instance of the class]
iank: In the "invoke a method" algorithm, there's a "select a
global" thing. Might need to nail that down more.
iank: In that global, it invokes some hooks to lookup a class
instance on the scope.
rniwa: But you don't define how to instantiate the class.
iank: That's in the "lookup a class instance" bit.
rniwa: That doesn't make sense. When you invoke, either the global
already exists, so you're looking up existing things. Or it
doesn't, so you make a new one and have to create new stuff.
rniwa: So I think this needs to have two sections, for when the
global exists or doesn't.
iank: I can do that.
iank: It does work like that - the algorithm gives some hooks that
get you those operations. They create or return the class.
iank: But it might be doing a confusing amount of stuff at once.
rniwa: In layout, you can have a lot of things, one instance per
fragment, so you'd need to say...
iank: Yeah, you've convinced me actually.
Bikeshedding
------------
shane: A worker lives in a thread, it lives on its own, has an
event loop, can postMessage, is async to everything else.
shane: WebWorkers, ServiceWorkers, etc.
SimonSapin: Is the affinity to a thread required?
shane: The worker is tied to a thread, not necessarily unique to
that thread.
shane: These things don't have independent existence. No
independent even loop, don't live until main thread talks
to them, can't message them, etc.
rniwa: I think the significant difference is no event loop.
shane: Asynchronous too. Asynchronous in worker case, synchronous
here.
ojan: You can always choose to block on an asynchronous operation,
but these require blocking.
ojan: If you call offsetHeight, you *must* wait for the
layoutworker to finish.
rniwa: But you can speculatively call it beforehand.
TabAtkins: Sometimes, yes. But if there are pending style ops, you
must flush, then run layout blocking, before returning
offsetHeight.
zcorpan: This seems like exactly my model of what a "Task" is.
shane: This is an intimate part of the style computation process.
shane: Custom Paint isn't necessarily like that, but Custom Layout
is. It runs inside of layout, and the rest *must* wait for
it to finish.
ojan: I view Task differently. It's not necessarily something with
a new global scope.
zcorpan: Ah yes, I see what you mean.
shane: So I think we need to reject anything with "Worker" in it,
because it leads to bad expectations.
shane: So far suggestions are Processor and Worklet.
rossen: SynchronousWorker
TabAtkins: Please nothing that abbreviates to SW.
rniwa: I think I'm convinced *Worker is a bad idea.
shane: Maybe Task?
TabAtkins: "Task" is gaining an established JS meaning, as
something similar to Promise. Implies normal object
living in main thread.
rossen: From the point of view of an OS, where you have a
scheduler, which pretty much does same thing with
processes...
rossen: At any given time, it'll invoke one of them and wait,
maybe suspend things...
rossen: So I think these are a lot like processes.
TabAtkins: I think processes are closest to Workers.
shane: I think these are most similar to the context you call out
to when you use an FFI.
ojan: "Script Context"?
rossen: Context is already overloaded - global context, etc.
TabAtkins: Environment is overloaded in similar way.
rniwa: Environment is something that embeds the script, not the
object.
rniwa: IsolatedScriptRunner
rniwa: Or IsolatedScript
rniwa: I don't like "Runner" because this doesn't *run* the script.
It's the object that gets run.
astearns: Utility in surfacing the idea that these don't run in
order?
shane: Other thing for IsolatedScript is the name of the spec
would be "Isolated Scripts", which is exactly what we want.
ojan: Confusing to me that you can call importScript(), loading
more scripts into your IsolatedScript.
zcorpan: What about IsolatedWork? I keep coming back to "Work".
ojan: This'll imply a name for all the individual things.
ojan: Paint*, Layout*, etc
<TabAtkins> PaintScript?
SimonSapin: padenot says yes to IsolatedScript.
rniwa: Why do we need to be able to load multiple scripts?
TabAtkins: If you can load one, no reason to disallow multiple.
You could just concatenate.
dino: All custom painting happens in one of these things.
ojan: Right. One paint script. Multiple can run in parallel.
[suddenly, CONSENSUS ON WORKLET]
rniwa: It's a made-up word.
rniwa: So it's not overloaded, but eh.
[looks like worklet is a pre-existing word, but it's not widely
used and isn't totally inconsistent with our usage]
[discussing "worklet"]
astearns: So let's resolve to go with Worklet, at least until
Sydney.
RESOLVED: Call them "Worklets".
Next F2F
========
shane: We have two days in Sydney. 30th and 31st of January.
shane: I can probably still get extra time if you want us to go
for longer.
shane: But I doubt we'll have enough topics to overflow 2 days.
TabAtkins: I don't want to go longer.
ojan: I'll be there longer anyway.
rossen: Me too.
ojan: We can plan for informal discussions.
shane: We can set aside time for spec drafting. I found that
really useful with Alan yesterday.
rossen: Are you concerned about filling, or overflowing the days?
rossen: Last time in Paris, we had leftover time. This time we
almost didn't have enough, even though there was less time.
rossen: Two things I want to put a pin on.
rossen: We haven't touched Parser yet.
TabAtkins: Parser hasn't been a direct requirement of some of the
other spec the group has been excited about.
TabAtkins: I feel it's very important to keep Houdini usable as it
matures.
rossen: Maybe in Sydney, if there hasn't been time to work on it
yet, we can do some writing then.
rossen: Another thing is the Box Tree API.
TabAtkins: Box Tree is closely linked with Layout. Since we all
agree Layout is one of the later specs we'll do, I'm
fine with Box Tree waiting a bit.
astearns: But it might take a long time to agree one.
TabAtkins: I'm just concerned about firming up Box Tree before
Layout. Fine with working on it with recognition that
it's extra-speculative, more than other specs.
Rossen: It would be cool to have Layout and Box Tree to start to
firm up in Sydney.
shane: Sounds great.
shane: I can maybe try to set aside some space/time in Sydney.
shane: And maybe do small focused telcons to work on this. Those
were very useful for the other specs.
ojan: So you're looking for a forcing function?
shane: Not just - trying to set up conditions conducive to work.
If I set up a voice chat, something will get done.
shane: So voice chat doesn't need extra Sydney time, anyone can
participate.
shane: So let's do 3 - one for umbrella spec, one for parser, one
for box tree. Box tree after umbrella.
ACTION shane to set up 3 VCs, for umbrella, parser, and box tree.
Received on Saturday, 7 November 2015 14:51:55 UTC