W3C home > Mailing lists > Public > public-houdini@w3.org > April 2018

[Houdini] Minutes Berlin F2F 2018-04-09 Part II: Custom Layouts

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 25 Apr 2018 20:27:19 -0400
Message-ID: <CADhPm3uBspxqEsUhocXa8NGRj6S=6h1D+oj8TW-wp7gL+--FKQ@mail.gmail.com>
To: public-houdini@w3.org
Cc: CSS WG <w3c-css-wg@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.
=================================================


Custom Layouts
--------------

  - iank started by showing a demo of how he plans to have Custom
      Layouts be used. Demo code is here:
      https://github.com/GoogleChromeLabs/houdini-samples/blob/master/layout-worklet/masonry/masonry.js
      - iank plans to run benchmarking to figure out what speed
          improvement this introduces as well as to know if this is
          better handled through generators or through promises.

  - RESOLVED: Use the same worklet policy as Paint (with respect to
              selecting the global scopes: Issue #744)
  - RESOLVED: The instance is tied to the same policy as worklet
              swapping. (Issue #746)
  - RESOLVED: The lifetime of inputs and collections is the same as
              the policy for worklet swapping. (Issue #745)
  - RESOLVED: Accept the new parameter in
https://github.com/w3c/css-houdini-drafts/issues/747
              (Parameter is called LayoutOptions.sizing)
  - RESOLVED: No change on https://github.com/w3c/css-houdini-drafts/issues/748
              (Naming of LayoutFragment#inlineSize, blockSize)
  - The data returned in the LayoutConstraints object as defined by
      Houdini seems correct, even though there isn't compat on what
      produces the data and therefore data is different by browser.
  - RESOLVED: We will continue adopting generators for layout
              functions. (Issue #750: Generator vs. Promise design
              for the API)
      - Note that this resolution was intended to encourage further
          investigation around this topic and the group is open to
          re-investigating once there is more data.

===== FULL MINUTES BELOW ======

Agenda: https://github.com/w3c/css-houdini-drafts/wiki/Berlin-F2F-April-2018

Scribe: dael

Custom Layouts
==============

Demo
----

  iank: [shows demo] This was the simplest I could think of. There's
        a test class, 8 divs, display:layout.  It has a --padding
        property and a --columns property.
  iank: It's about 50 lines of code. [shows]
  iank: You can see we register the layout. We import properties
        --padding and --columns, we don't care about children.
  iank: Currently the constraints we're passing in has one useful
        thing. We're pre-calculating the inline size.
  iank: I added a thing where you can say you want the sizing to be
        1 and then you don't have to worry about sizing. Turns out
        to be useful because you don't have to worry about size.
  iank: The children all have style map, it contains nothing in this
        case. Only thing we have is the layout.
  iank: Next we're layout out all the children and forcing a fixed
        inline size on them.  It's fixed inline size/# columns.
        We're saying regardless of your max or min width you have to
        be this value.
  iank: Next thing is we've got all the fragments now, they have an
        inline size that we fixed it to. The block size,
        inline-offset and block-offset.  Everything is based on the
        parent's size.
  iank: We work through that and it returns the autoBlockSize. It
        takes the autoBlockSize and runs the sizing algorithm on
        it. Overflow is handled by the engine.
  iank: And that's it.

  smfr: Block and inline size is relative to the current layout.
  iank: Same with the inline offsets. It's relative to the current
        layout.
  iank: If we flip the direction or the writing mode, that works.
  iank: [shows flipping direction and writing-mode]
  Rossen: Awesome.

  smfr: How does validation work?
  iank: It works on the input properties as well as...basically it
        works with anything that changed in your inputs.
  iank: We've got the edges here that's the size of the box, the
        padding, etc. Anything in your style map or your children
        style map changes or you drop/add a child.
  Rossen: Is you made a content change you'd get call back with the
          same collection.
  iank: Yeah.

  iank: Edge case is if it contains size. All the standard
        validations.
  iank: We probably won't reach compat on number of times this is
        called and order. We've got different constraints.
  emilio: If you had the children with custom layout, can't you get
          into a situation where invalidating the children's style
          changes the parent and you get into a recursive situation.
  Rossen: No more then any CSS.
  emilio: Fair enough.

  iank: It is possible if trying to do perfect layout with a while
        looping. With this mode where you always have fixed inline
        size that's a little bit reduced.
  astearns: Is this what's in your github?
            https://github.com/GoogleChromeLabs/houdini-samples/blob/master/layout-worklet/masonry/masonry.js

  dbaron: With the invalidation it seems like you're doing normal
          layout validation less validating the input.
  iank: Exactly. When we recalc it goes through the properties and
        do style emulation.
  dbaron: To answer emilio in general in existing layouts there are
          cases where it invokes size on the child layout multiple
          times. As long as the parent knows how to handle any of
          the sizes you'll be fine.
  smfr: Can this run arbitrary script?
  iank: You're in sandbox. Everything is read only.
  smfr: On the main thread?
  iank: For us, yes. It's easier for that.
  iank: In a theoretical world you could have an engine with things
        that are asynchronous you could run this off the thread.
  flackr: Or you could parallelize.
  iank: Yeah.

  dbaron: Weirdest about this was how it uses generators,
          particularly where the non-final and final response have
          different semantics. For people seeing generators for this
          first time in this it's a horrible introduction.
  TabAtkins: It's using generators when it's semantically
             asynchronous.
  iank: Biggest problem I see...we can do either...biggest pro of
        generator is if other asynchronous things link into...if
        makes no sense to do a network request in the middle of
        layout. We're using promises for the engines that aren't
        able to handle it immediately.
  iank: We turned off things like dynamic import for worklets on
        thing link this.
  dbaron: Generator seems reasonable.
  iank: I'm fine either way. I want to do benchmarking and promise
        might work.
  dbaron: With generator each time it yields something the browser
          must process that before invoking again.
  iank: Yes. There's a layout fragment request. The engine processes
        that and next time it calls the generator it has to provide
        that. Promises have better error handling.

  majidvp: For your inputs is there a way to preserve the old ones
           and exit early?
  iank: You can't exit early. Fragments are only valid for one
        layout pass. Once the generator passes the elements get
        removed internally. If you try and invoke them later the
        engine says no, sorry.
  iank: What does make sense if...if you have from your style, if
        you've got something complex like manually passing something
        with a lot of overhead you can stash that on the instance.
  majidvp: The instance stays alive until the box?
  iank: Yeah, the box. Issue open for what is the lifetime for the
        issue, in this case the box.

  Rossen: Did you benchmark any of those?  If you just did normal
          block layout and you have the block size and you have 2d
          blocks, what's your expectation.
  iank: I would expect for simple block layout we'd be faster,
        that's my gut feeling, but I want to benchmark it.  If
        you're doing something very simple I expect this would be
        slightly faster.
  iank: This will be my performance test, my guess is custom layout
        is faster.
  iank: This is the amount of script, it's more complex then regular
        block layout. It depends on what outlining's cost is.
  Rossen: Cool.
  Rossen: If there's no more comments on the demo, we can move on to
          issues.

Need to select policy for selecting global scopes
-------------------------------------------------
  Github: https://github.com/w3c/css-houdini-drafts/issues/744

  iank: This one should be simple. Basically what is our policy for
        selecting global scopes? With paint API we set a policy that
        you must select between 2 and must not use more then 12
        times in a row. What would we say for layout.
  surma: Limit to 2000?
  iank: It's because you need "fewer" code you don't know where the
        state will be.
  dbaron: Because you want impl to be able to throw away that state.
          Webdev shouldn't debug against code that doesn't throw it
          away.
  surma: That's high.
  Rossen: That's why it's a not. If you're really constrained you
          can reuse it.

  Rossen: Why would layout have a different policy?
  iank: I don't think there's a reason. Same would be good.
  Rossen: I think this is how worklets works. Layout just follows.
  iank: Yeah. I think worklets is different because audio has
        different requirements. Whatever happens for the rendering
        type layouts.
  Rossen: Other opinions?

  smfr: If an author needs to do expensive computation it has to do
        it many times.
  iank: You can stash, but you have to be able to regenerate it.
  TabAtkins: You'll probably get some statements.
  smfr: So you'll have layouts that say every 30 times...
  Rossen: If you get called by 30 worklets with the same input you
          should work no matter the state of the layout.
  cbiesinger: We have the idea that some animations have a local
              state. The instance could provide a state object and
              if we construct we provide the state.
  iank: I think it's slightly different. With animation you want
        previous frame, but there's no reason you'd want that.
  smfr: There's a whole opportunity for custom layout like moving
        boxes.
  iank: That's fine if you feed the custom state.
  TabAtkins: If it depends on layout it will not let you cache as
             much.
  TabAtkins: [missed] The JS can send it straight in without
             redirecting through a custom property string.

  flackr: If we switch to worker2 and back to 1 is that the same
          instance?
  iank: That's the next issue.

  Rossen: Were there other reasons people believed we should have a
          different policy for worklets?
  dbaron: I wouldn't phrase it that way because worklets might be
          used more broadly,
  Rossen: Fair enough. No different policy the paint.

  RESOLVED: Use the same worklet policy as Paint

Lifetime policy for passed in objects, e.g. LayoutChild
-------------------------------------------------------
  github: https://github.com/w3c/css-houdini-drafts/issues/746

  iank: For a box with a layout instance it's tied to a lifetime of
        boxes. The box drops out of the tree.
  dbaron: This is the thing in the spec with a bunch of prose about
          these get cached by worklet and only cache is destroyed
          when box is dropped.
  iank: Yes. For example in our implementation if we have 2 layout
        level scopes both will have one instance. It lets you have
        expensive cached calculation = something
  iank: We could have a policy where we kill it every 1000 times and
        regenerate, but there's a value to keep them.
  dbaron: There's the same worry about layout global scopes...so if
          you're keeping worklet level every 1000 you'll get
          something after re-layout.
  iank: Yes. Is the global scope switching enough? Or do we want
        something more expensive.

  Rossen: Will you be allowed to reuse the worklet?
  iank: Yes. If you've got 2 boxes that run the same worklet, each
        will have its own instance.
  iank: A good example is 3. In our implementation we do specific
        caching on internals, you could do that here for layout
        reasons.

  fremy: Didn't we discussion a shared cache across worklets?
  iank: We did....
  Rossen: If what you want to share is the results...unless the read
          only cache is read/write that's okay. But then you will be
          producing a lot of generating. If it's read-only it has to
          be communicable. But that's a good first step.
  Rossen: In more complex layouts you have a ton of layout
          information you want to preserve between passes.
  iank: It's regenerateable.
  iank: That's why I prefer an instance that does live across many
        frames. Question is do we nuke this instance.
  Rossen: If I understand, the only cost we will have when we nuke
          the instance or somehow remove it, it's performant.
  iank: Yes. Should be cheap from our PoV to regenerate the state.
        That's the big question. This is somewhat edgecasey, but
        every minute need to recreate.
  Rossen: When we discussed 2+ worklets and all the costs, we did
          this for many reasons. Why should we change those for this
          case?  I would say for now carry the policy.
  iank: Policy doesn't require you to kill, just switch.
  iank: We're not wiping out a state we just have bad state.
  Rossen: My hope is anything you do that depends on global state
          should be discouraged. If we have an explicit reason we
          will care information on your behalf, that's fine. I don't
          see why this should be special unless we run into memory
          pressure. In that case you have to be prepared to
          regenerate.
  iank: Lifetime of the box unless UA needs to regenerate.
  iank: I'm also fine with that or just adding something
        preemptively.

  Rossen: If the stash will be not needed can't we make it explicit?
  iank: It is.
  Rossen: But if you have a stash that's necessary...if they have a
          stash where these are the things I spent 40 minutes
          calculating the perfect size and I want to preserve it...I
          can have all kinds of other garbage you shouldn't retain.
  iank: But people that have cached, we can always be there later.
  iank: Fine with tying lifetime to the box?
  TabAtkins: No worse then globals
  Rossen: What is lifetime of the box?
  emilio: Blink only destroys tree when display changes. So if you
          change display any parent box will be dropped.
  iank: Might be a reason why we nuke the instance every 1000 times.
        You drop the box on resizes?
  Rossen: Yeah.
  iank: May be why we drop periodically.

  iank: Reuse the instance no more then 1000 times as the policy?
  dbaron: How can you reuse more?
  iank: Global scopes changes, but don't tear down. Here we're
        saying you reached the max and we're going to tear it down
        and rebuild.
  dbaron: Might be good to have a sentence or two with explaining
          the algorithm.
  iank: Yeah.
  dbaron: As a reader if there had been 2 sentences explaining the
          algorithm I wouldn't have had to read the algorithm.
  iank: Reuse the layout instance no more than 1000 times, after
        that you must regenerate.
  Rossen: Or drop whenever you switch worklets.
  Rossen: Other suggestions? prop: The instance is tied to the same
          policy as worklet swapping.
  iank: Not explicitly.
  Rossen: If you switch event 1000 times you get it 1000 times.
  iank: I'm fine with that.
  Rossen: Let's see how it goes. If performance is decremented then
          let's discuss it. It's always easier to relax later.
  Rossen: Objections?

  RESOLVED: The instance is tied to the same policy as worklet
            swapping.

Lifetime for passed in arguments to layout, intrinsicSizes
----------------------------------------------------------
  github: https://github.com/w3c/css-houdini-drafts/issues/745

  iank: We've got a bunch of objects passed in. layoutChildren most
        interesting. You may want something similar as layout
        instance where you get passed the same child every time.
  Rossen: Or I can stash all the children and look them up.
  iank: But if you pass in new children you can't.
  dbaron: If you have this cache you need to define child ID
          carefully. If a child changes display type do you get a
          different child, if it changes overflow  do you get a
          different child?
  dbaron: Is this like, “do you have a different box type”?
  iank: Yes.
  dbaron: “Do you have a different box type” isn't interoperable.
          Blocks with and without scrollbars are different in Gecko.

  cbiesinger: Does the calculation matter on times when the child
              would change?
  iank: The reason you want to use this cache is similar to the grid
        example where from this current layout you want to
        calculate something based on the child's style.
  cbiesinger: You would need to store the old value for that case
  <dbaron> (cbiesinger was asking about the risk of a developer
           caching something that might not be valid after certain
           types of changes)
  iank: Right, but string comparison is cheaper then regenerating the
        object.
  smfr: Layout child isn't exposed to different custom layout, right?
  iank: Right. There's like 2 or 3 policies here. Like the others we
        can regenerate each time. There's also a question about passing
        in same style map.  We can start with regenerating each
        argument call and try to loosen.

  smfr: In the JS can't you say it's read only?
  iank: Yes, but you can use layout child as a key still.
  smfr: [missed]
  iank: Yes but this instance.
  smfr: Pure read-only is good. Caching should be like an API. You
        want the performance guarantee that when you run the code
        it'll go fast.
  iank: Cache has structure which is expensive.
  iank: We've made it faster, but it's not as quick.
  majidvp: You only have to clone the structure when moving global
           scope.
  iank: The object will always be alive. So you have to call every
        time.
  majidvp: You need to serialize and then destruct.
  iank: You have to serialize it out.
  majidvp: Cache is strictly there to help you cache the structure.
  iank: If you go back to you can twiddle things on the object then
        you can stay there.
  iank: That's why I'd like to keep this object for stashing state.

  smfr: Consistent but slow re-serialization or a faster but
        hiccupy. I'd prefer the consistent approach.
  iank: If we regenerate each time it depends on number of children but
        it can be much slower.
  iank: I can benchmark, but my hunch is creating them each time
        rather then trying to cache it'll be a substantial
        difference.
  smfr: You'll pay that in the long frame, though.
  iank: Yeah. But if you have something deeply bad you'll get it.

  smfr: I think these APIs are problematic if they're not
        performance guarantees. If the author wants to do a good job
        and they're penalized everything 39th frame...
  iank: That's why you may want to keep the instance around so when
        scope switching you get the guarantee. You've got an
        instance tied.
  smfr: 2 instances will have the author really confused.
  iank: If the author never recalcs from the complex thing then you
        get [missed]

  iank: What do you want to do?
  Rossen: Since you're the furthest in impl, what do we know so far
          in terms of requirements, expectations, and patterns.
  iank: We've got more people using it. We might give this to people
        and see if they run into issues.

  Rossen: To smfr's point and I sympathize, it should be fine to
          allow custom layout or paint to pass different information
          between passes.
  Rossen: We have a few issues. One of defining what the lifetime of
          the boxes are if this will tie in lifetime of other
          objects. This is the point dbaron was making. You'll
          regenerate boxes different times than Gecko. That's not to
          say the instances we keep should have same lifetime. That
          can be based on something else like a display property
          changing.
  Rossen: That will get us into trouble as custom properties are
          more common so we'll again be in a tight place for
          lifetime.
  Rossen: Other option is to say we have a policy that you need to
          redo everything at a certain time and that's a fine
          expectation.
  Rossen: I prefer to be as aggressive as possible on cleaning up
          and resetting. If the explicit stash is needed, define
          that, give that API, and let people stash something
          besides custom properties.
  Rossen: We don't penalize people running on an awesome device.  If
          we do have to have penalties we have information about
          what we need to keep.  Seems like the best compromise on
          both sides of the fence.
  iank: We can tentatively do that for now and see what happens.

  Rossen: If we want a resolution, not just a tentative what does it
          mean.
  Rossen: We can introduce and explicit cache which re-writes cache.
  iank: I don't think we want that yet.
  Rossen: Even better.
  iank: For now instances and layout children get nuked when we
        switch global scopes.
  smfr: Why not new children and instance on invocation?
  iank: I'm worried about performance. Invoking a constructor is a
        few ms each time.
  iank: Let's start with we nuke everything when switching global
        scopes.
  Rossen: Only thing we're adding is that input are also new
          instances.
  Rossen: smfr?
  smfr: I'd prefer the super clean APIs where everything is done
        internally. Authors won't be surprised. If we do anything
        else they will get confused.
  iank: Should we see if authors will get confused?
  smfr: If you can find some that are fresh.
  iank: We can do an origin question and find out.
  Rossen: Not per call?
  iank: Yep.
  Rossen: Objections to the lifetime of inputs and collections is
          the same as the policy for worklet swapping?

  RESOLVED: The lifetime of inputs and collections is the same as
            the policy for worklet swapping.

  <br type="lunch">

Review the LayoutOptions.sizing parameter
-----------------------------------------
  github: https://github.com/w3c/css-houdini-drafts/issues/747

  iank: This is...we had one layout option for the child display.
        This is one mode I think we should add that flips the type
        of sizing you default to.
  iank: As I was building examples it's really nice if you don't
        have to worry about your size. block-like is handled for you.
  iank: Like in my earlier demo you're always given a fixed size and
        you're given an auto block size.
  iank: Thing that makes it more custom is a manual sizing mode
        where you explicitly say the sizing.
  iank: If we use block-like initially it makes it a lot easier on
        impl to do it this way and less compat risk.
  iank: Is there any feedback?

  smfr: Minor objection to size as a word since it's height and width
  iank: This is the engine taking care of the size.
  smfr: But it's a scalar.
  dbaron: CSS is using block-size already.
  smfr: What happens with a discretionary of auto block-size?
  iank: In block-like it takes care of it for you. In some
        circumstances you'll get a fixed size like abspos and you're
        constraining the block.
  iank: I think for compat risk we'd want block-like as a default.

  Rossen: This sounds more like native layout. Sizing and
          positioning are parts of layout, but you're not talking
          positioning. Engine for layout more for native layout mode
          or something like that for the name.
  Rossen: Instead of 'sizing' to imply I want you to do layout on my
          behalf and the type of layout is block-like.
  iank: It's not simply layout. It's also the size of your fragment.
  iank: That's why I sort of....
  Rossen: ...Okay.
  iank: I'm fine calling it something else.
  Rossen: I see what your intention was.
  iank: With this sizing is block-like it's computed as if you were
        a block container and that's pre-computed.

  Rossen: So if you happen to be a flex-item all the flexing will be
          ignored?
  iank: If you're a flex-item the engine can work out ahead of time
        what your size is going to be. If there's flexing that fixed
        inline size will be increased by the flex amount. Inline
        synthesis is handled by the engine and all you need to do is
        the flex size and that follows the same rules as the block
        size.
  Rossen: I guess it's okay
  iank: You lose a little bit of power.
  iank: It also allows if we're defaulting like servo can do it's
        inline sizing pass at the moment. From what I've used it's
        much easier and a lot less work. What it gives you is what
        you want 95% of the time.
  Rossen: Was this edited in?
  iank: Yes.
  Rossen: Objections to accepting this new parameter?

  RESOLVED: Accept the new parameter in
https://github.com/w3c/css-houdini-drafts/issues/747

Naming
------
  github: https://github.com/w3c/css-houdini-drafts/issues/748

  iank: One feedback from Travis at TAG found it not saying
        border-box confusing.
  dbaron: Yeah.
  dbaron: As someone that works on layout code I'm used to knowing
          you have to work with border-box and you don't type it.
          Travis was looking at it further away from layout and he
          found it confusing.
  dbaron: I lean toward disagreeing, but if we change it should be
          sizes and positions.
  iank: Agree.
  iank: Unless webdev are really confused I'd lead toward us being
        shorter here.
  Rossen: If anyone goes to extent of understanding what layout
          fragment is I have a hard time believing that person would
          struggle.
  plinss: It's just knowing the difference of border and content
          box. Then what about box sizes and what do you do. Looks
          like it's more clarity.
  Rossen: Someone going through learning phases.
  Rossen: Objections to no change?

  RESOLVED: No change on https://github.com/w3c/css-houdini-drafts/issues/748

  iank: Any tag feedback we should discuss?
  dbaron: Let me see
  [discussion around next topic]

LayoutConstraints object - Are we ok with exposing information we
    don't have compat on?
-----------------------------------------------------------------
  github: https://github.com/w3c/css-houdini-drafts/issues/749

  iank: All engines have pretty good compat...what we'll pass
        through LayoutConstraints object...
  iank: When it's non-orthogonal writing modes we have pretty good
        compat on what we'll resolve inline percent and block
        percent to.
  iank: Problem is with orthogonal writing modes.
  iank: A few cases in the issue, we have nowhere near compat.
  iank: First example is what we resolve percent to.
  iank: Padding in this example is completely different on all
        engines.
  iank: Not arguing about who is right, I made lots of test cases
        yesterday and they're very simple.
  <gsnedders> iank: plz make sure all these tests are in WPT

  iank: Do we want to get compat here first? Go back and not expose
        this initially and just use layout sizing as block-like? Are
        we fine exposing this knowing that orthogonal won't be
        common?
  fantasai: I'm confused. Spec is clear.
  iank: No one follows spec.
  dbaron: Seems silly to remove the feature for that reason. It
          should be clear what the spec says should happen in that
          case.
  iank: Half the comments on the spec...like Size with percent size
        is one area of compat. For writing modes we only talk about
        available space.
  dbaron: I think, it might be worth thinking about which thing
          makes the most sense in the API. Do you want the thing
          based on the parent's writing mode or your own?
  iank: It looks at everything in your own writing mode, but all
        engines have different conversion.
  iank: Here's a good example where percent resolution for
        padding-left:10% varies. But the size you should resolve
        against isn't defined.
  fantasai: Flexbox issue.
  emilio: That was fixed recently in FF. If you test the nightly.
  iank: There's other cases here as well.
  iank: I'm fine with exposing all this, but it may be a while until
        we're toward compat.
  iank: Other option is strip LayoutConstraints and its just the
        fixed layout size and the engine handles it's quirks for you.

  majidvp: Is there a way inside the worklet to detect UA?
  iank: Only if you pass in a property.
  iank: Initially given the state of compat I'd only feel
        comfortable exposing the simple layout and forcing
        block-like on everyone.
  iank: Keep in mind this is only input going in. For giving inputs
        to reach children I think we can reach compat there.
  [silence]
  dbaron: I'm not convinced that the compat problems are that severe.
  dbaron: If Houdini specs are clear what these things mean people
          impl the Houdini bits can be clear.
  Rossen: You're saying code should work regardless of the inputs.
          If we need different inputs for different engines your
          code should do something right. It's to our benefit to
          work out compat bugs regardless of Houdini.
  dbaron: Gecko has a data structure with this in the parent vs
          other have in the child's writing mode. If the spec is
          clear you can do the right thing.
  iank: Yes. Engines can give you different things for different
        stuff.
  Rossen: So that's no change?
  iank: Yes. I need to write tests to make sure my interpretation is
        right.
  iank: Issue is not an issue.

Generator vs. Promise design for the API
----------------------------------------
  github: https://github.com/w3c/css-houdini-drafts/issues/750

  iank: From the author PoV...
  Rossen: The only difference is you added a *
  dbaron: You need an async in the second line.
  iank: True.
  iank: These are the pros and cons [further down the issue]
      Generator:
          Pro: May be faster wrt. bindings.
          Pro: More restrictive API, can't await on other APIs which
               might leak into the LWGS.
          Con: Less obvious error handling to for web developers.
          Con: Less obvious API as this pattern isn't common, and
               not many people use them (generators).
      Promise:
           Pro: More obvious error handling.
           Pro: Common pattern for developers.
  iank: If anyone else has something to add here, I'll come back to
        the next meeting with data.

  Rossen: Are generators broadly impl?
  iank: Yes.
  iank: Everyone does generators, though they haven't been used like
        this before.
  TabAtkins: We won't expose the functions you can't run.
  iank: We'll have to make sure in the future. We have to code with
        eyes open.

  fremy: You like this better because you can only allow some things
         to be sent?
  iank: It makes a tighter API. Promises are more familiar.
  fremy: Dev are familiar with converting in the background
  dbaron: After thinking about this, I'm feeling like the way devs
          interface with the engine here feels better described by
          generator and not promise.
  dbaron: I think because promises have this tie to an event loop
          thing where promises are running asynchronous on this
          micro-task. You're in the middle of this thing in the
          layout engine and it needs to call you many times.
  surma: I agree you're generating the list.
  TabAtkins: You're not though. We can call you fresh.
  surma: That's details. Conceptually it works as a generator.
  surma: I'm wondering if there's a place where scheduling with
         promises may become and issue and it wouldn't with promises.
  iank: I think there's work in FF to work promises at the right
        time. For the synchronous engines we would all the layout
        engine, make sure task queue is exhausted, make sure we've
        got a promise.
  surma: It makes more sense with generators even if it's 100%
         correct.
  dbaron: I think one of the weird things about generator is it
          produces the last thing at the end. You're using yield and
          return syntax to do much deeper things.
  TabAtkins: The yield at the top of the issue is not usefully
             yielding into the engine. It's saying do this layout
             and give me results. It's using a generator as an
             asynchronous iterator. It's possible, but not the
             preferred pattern.
  TabAtkins: It off doing it's own thing. If it was synchronous we
             wouldn't have to do this.
  surma: Both allow us to think about asynchronous and parallel
         layouts in the future?
  iank: Yeah.

  Rossen: I'm hearing mostly people leaning toward generators.
  TabAtkins: No.
  Rossen: Except TabAtkins.
  iank: We can also give two different versions and see what people
        expect.
  Rossen: TabAtkins would you object? Any objections?
  TabAtkins: I have weak objection and would like wider review.
  Rossen: Has there been review? TAG looked, did they say anything?
  Rossen: I went through Travis's comments and they were high level.
  dbaron: I don't remember this one.
  iank: I think notes from the TAG meeting are up.
  [everyone hunts meeting notes from TAG]
  dbaron: Minutes say "Travis: I have some review feedback to post
          to the issue."
  dbaron: We came back to it the next day, though.
  <dbaron> TAG minutes in
https://github.com/w3ctag/meetings/blob/gh-pages/2018/04-tokyo/04-06-minutes.md
  iank: [skim-reads]

  Rossen: There's a couple ways to get out. 1) We agree to adopt
          promise-based API 2) We stick with generators with a light
          objection from TabAtkins and then he can figure out if we
          should avoid it. If he comes back with reasons and we can
          change.
  TabAtkins: I'll bother Dominic.
  Rossen: Sticking with Generators will force the discussion.
  Rossen: Do we have people that object to promise-based APIs?
  TabAtkins: Performance aspect.
  iank: I want to do some benchmarking.
  iank: I think layout will be particularly sensitive to bindings.
  TabAtkins: My hope is we don't need to re-apply promises.
  iank: We might need special APIs.
  iank: I'll have everything hopefully done.
  Rossen: Prop: We will continue adopting generators for layout
          functions. TabAtkins will followup

  RESOLVED: We will continue adopting generators for layout
            functions.
Received on Thursday, 26 April 2018 00:28:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:53:28 UTC