W3C home > Mailing lists > Public > public-houdini@w3.org > November 2015

Minutes Sapporo F2F 2015-10-29 Part III: Scrolling, Typed OM, Worklets/Whatever They're Called, Next F2F [css-scroll-api] [css-typed-om] [worklets]

From: Dael Jackson <daelcss@gmail.com>
Date: Sat, 7 Nov 2015 09:50:55 -0500
Message-ID: <CADhPm3shXnsefXBRVQaKPpYXcfcKL_m-uLc57ZvXse1th43VYA@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Saturday, 7 November 2015 14:51:55 UTC