[Houdini] Minutes Sydney F2F 2018-07-02 Part II: Layout API, Typed OM, Custom Paint

=================================================
   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.
=================================================


Layout API
----------

  - RESOLVED: Abspos parented to custom layout elements have static
              pos computed similar to flex and grid children (static
              pos rect coincides with parent rect) (Issue #775)
  - RESOLVED: The rules for abspos containing blocks is not changed
              with the presence of custom layout. (Issue #775)
  - RESOLVED: Custom layout must return all fragments, otherwise
              return an error and fall back to block layout. (Issue
              #775)
  - RESOLVED: Use Promises and add a note about error handling (Issue
              #750)
  - RESOLVED: No change on Issue #437 (percentageInlineSize /
              percentageBlockSize)
  - RESOLVED: Intrinsic size in orthogonal flows are taken according
              to the writing mode of the containing block, and
              intrinsic size calculations have to be consistent with
              all other places in CSS (per CSS Sizing). (Issue #776)

Typed OM
--------

  - RESOLVED: Add frremy as co-editor on css-typed-om, move nainar to
              former editor

Custom Paint
------------

  - RESOLVED: Deferred to L2 (Issue #763: optional arguments in paint
              functions)
  - RESOLVED: Custom Paint to CR

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

Agenda: https://github.com/w3c/css-houdini-drafts/wiki/Sydney-F2F-July-2018#proposed-topics

Scribe: heycam

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

Layout API
==========

Missing fragments and absolute children
---------------------------------------
  github: https://github.com/w3c/css-houdini-drafts/issues/775

  <div style="display: layout(foo);">
    <div id=child1></div>
    <div id=child2>
      <div id=abspos></div>
    </div>
  </div>

  iank: In the Layout API, it's possible to have multiple children
  iank: In the example in the issue, the second child has an abspos
        child in it
  iank: Its containing block is higher up in the tree
  iank: Inside of layout, we only lay out the first child, and return
        it
  iank: What should the behaviour of the abspos be?
  Rossen: Is there an expectation for anything to happen to the child
          box?
  iank: In the current API, you can just leave out children
  iank: and they don't lay out
  eae: Effectively it's display:none
  eae: so wouldn't it make sense for their children not to show up?

  Rossen: There are two things
  Rossen: either the abspos child will be lifted outside the scope of
          the display:layout function grandparent, or not
  Rossen: If it's lifted outside of it, I'm assuming layout will
          happen in the normal way
  iank: Your assumption is that it will display the abspos child
        somewhere else
  Rossen: If it's position is outside the scope of the display:layout
  Rossen: Would all abspos elements reach their containing block,
          during custom layout?
  Rossen: You can have a bunch of inner levels of custom and normal
          layout
  Rossen: Will there be a discontinuity in that process?
  Rossen: My assertion is that it shouldn't
  Rossen: One potential problem is that if you rely on something as
          part of the custom layout, in that interleaving, and that's
          not calculated, you might get wonky results
  Rossen: e.g. if you don't lay out child 2, and the abspos position
          depends on child 2's position, you'll have to synthesize
          something for the static pos
  Rossen: but that's about it, or you might have something that is
          switching writing modes or whatnot
  Rossen: but again my assertion here is that this shouldn't have an
          effect apart from residual things like static pos
  iank: I'm fine with that

  iank: What should happen with the static pos?
  Rossen: (a) we don't want to have a loss of content, regardless of
          what happens to the custom layout parent
  Rossen: i.e. the abspos box should not just disappear, unless you
          explicitly say so
  dbaron: So you're saying it should have its normal abspos
          containing block, and the custom layout is never an abspos
          containing block.
  Rossen: No
  Rossen: My assertion is the box with abspos element will always
          generate a box, and it will be parented to the appropriate
          containing block, which may or may not be custom layout
  Rossen: Distinction is propagating through custom layout layers,
          second is ending up at a non-custom layout containing block
  Rossen: So besides calculating some invalid or default static pos
  iank: Something along the lines of pretend that it did generate a
        (0, 0, 0, 0) fragment

  fantasai: For custom layout, unless we want to let it control the
            static pos, we could certainly just use the rules in
            flexbox
  fantasai: which is you pretend that the static pos rectangle is the
            whole flex container (the abspos’s parent)
  Rossen: What happens if a flex item is the whole area
  fantasai: If display:layout and child2 are both doing custom layout
  Rossen: The outer one is the containing block
  fantasai: The parent gets used as the static pos rect

  ...: if you didn't lay it out
  Rossen: Then its parent
  fantasai: But that box still needs a position
  fantasai: Why isn't there a box?

  dino: On child2 if you put display:none, what happens to abspos?
  Rossen: Same as always, it wouldn't display
  dino: Why is different from not laying it out?
  Rossen: We shouldn't introduce things that are like display:none
          just because didn't lay out a box
  fantasai: It should just be (0, 0, 0, 0)
  dino: Sure
  fantasai: The box should still exist, and you just happen to not
            position it
  Rossen: Just becomes a position and an empty rect
  dino: If it had a position, you'd use that
  Rossen: Which is what I would expect
  iank: Yes
  Rossen: If my containing block is some span e.g., didn't have
          anything else than the abspos, it still has a position
          calculated for it
  eae: Makes a lot of sense

  Rossen: The static position of an abspos element, with a custom
          layout parent, is based on that parent's fragment's box
  fantasai: Similar to how static pos of a box that is parented to a
            flex container uses the rectangle of the flex container to
            calculate it static pos, rather than any hypothetical
            "would have been" layout like block layout
  Rossen: The summary here is that the static pos of abspos elements
          parented to custom layout is the same as in CSS, based on
          the rectangle of that parent
  fantasai: Similar to flex/grid, not block
  fantasai: In block and layout they use the hypothetical position if
            they weren't positioned
  fantasai: For flex and grid, we don't try to calculate where it
            would have been, instead pretend you would have coincided
            with your entire parent

  RESOLVED: Abspos parented to custom layout elements have static pos
            computed similar to flex and grid children (static pos
            rect coincides with parent rect)

  Rossen: Next problem, you've computed static pos, that's great. You
          end up with a custom element that has position:relative
  dbaron: There's an easier piece we should resolve first
  fantasai: Proposal is that custom layout does not interrupt
            propagation of abspos
  dbaron: It doesn't change the rules for when something is an abspos
          containing block
  Rossen: The abspos is never exposed to the custom layout in any form
  iank: Other potential thing is about the behavior of the second
        child, in this case
  iank: You are thinking that child2 should get laid out with
        available size zero, and would still show up?
  iank: It's specced as not showing up
  iank: That might be something easier to resolve on

  RESOLVED: The rules for abspos containing blocks is not changed with
            the presence of custom layout.

  Rossen: Next is, if the containing block is custom layout
  fantasai: If you don't explicitly lay out a child the layout engine
            resolves its size and position to zero
  frremy: I'm fine with that, but it will not show up
  frremy: I think that's ok, but if I don't put return it, I don't
          want it in the layout
  frremy: Similar to display:contents or something
  frremy: If I don't want to include a particular element,
          implementing something like -webkit-line-clamp, I don't want
          them generating

  dbaron: If I were to try to think about how I wanted custom layout
          to deal with being an abspos containing block, I feel like I
          would want to two different options probably
  dbaron: Don't necessarily need both options in v1
  dbaron: One of them would be: I want a custom layout, might be an
          abspos containing block, I want it to handle things I'm the
          abspos containing block for using the default rules
  dbaron: I don't want to handle those in my custom layout, just handle
          the in-flow contents
  dbaron: Other option: I also want to take over layout for the
          descendants I'm the abspos containing block for
  dbaron: and in that case, in many cases I'd want to get those sets
          of children separately
  dbaron: i.e. process the in flow ones first, then the abspos ones

  iank: I could imagine an API that is two additional callback
        functions, one where you're routing children, yes pass this to
        parent, no keep this one to myself
  iank: and an out of flow layout pass, which gives you the children
        you're a containing block for
  iank: and go ahead and apply whatever abspos rules you want
  frremy: That's useful for the grid polyfill
  frremy: If you set grid-column on them you still need to be able to
          place them in columns, even if they're abspos
  frremy: Doesn't have to be in the layout step, could be a separate
          step
  Rossen: Only problem I have with this, is if you select which
          children you want to handle, that goes against the
          resolution we just had before
  frremy: What does grid do?
  Rossen: The API proposed, here are the children going through, I
          want to keep certain ones ... unless we specify we're not
          even going to expose abspos to your children
  Rossen: because you really don't need to
  iank: I think it's a niche use case, a callback for routing
  Rossen: But that's a more advanced feature

  Rossen: So, current issue is, element with custom layout, it's also
          a containing block for abspos, there's a descendant abspos,
          and the custom layout does no layout. what happens to the
          rest of the children?
  Rossen: One of the assertions we should have here is that that
          child, at that level, is just a normal first level child, it
          has to be laid out
  Rossen: It shouldn't be any different from other ones
  Rossen: So if I have two children that are inside of this custom
          layout, one is an immediate child, one is a descendant,
          regardless how deep the descendant is, it's something I need
          to handle at the first level
  Rossen: If I can decline layout for a first level child, I should be
          able to do that for the abspos descendant too
  Rossen: Might be different for layout logic, that's your business
  Rossen: But the point is that I have a collection of children
          fragments that came up to me, if I decide to drop them all,
          I can
  Rossen: From that point of view I don't think we need anything
          specific to abspos, but we still need to be clear as to what
          the rules are
  iank: Yes, we can discuss that

  fantasai: The original issue, we've got an element whose static pos
            we need to find, static pos is not the custom layout in
            this particular case, because it's a child of a child of
            the custom layout
  fantasai: Custom layout is responsible for laying out the child,
            when it does, that box will determine the static pos of
            the grandchild
  fantasai: If the custom layout doesn't lay out that child, we still
            need to know where the static position is
  Rossen: We resolved that
  fantasai: We resolved that for a child of the custom layout, this is
            for a grandchild of the custom layout
  fantasai: It's different because if we don't run layout on the child
            of the custom layout, we don't know where it is
  fantasai: It's a regular in-flow child of the custom layout, inside
            that is the abspos
  fantasai: The abspos's position is dependent on the size/pos of
            child2
  fantasai: We don't have answer for the size/pos of child2
  Rossen: My point in the beginning is that the static pos of the
          abspos, is the origin
  Rossen: This is relative to its parent
  Rossen: If the parent doesn't compute to anything, it will be to the
          origin of its parent
  Rossen: At some point there is some ancestor where that origin is
          defined
  fantasai: We didn't resolve on that
  Rossen: This is how custom layout is defined to work, relative to
          parent
  fantasai: I know it's relative to parent

  dbaron: I think we need a definition of what happens if custom
          layout decides not to lay out something
  dbaron: In our engine, layout code can't not lay out something
  dbaron: I suspect other engines are probably similar
  dbaron: If you get laid out at (0, 0, 0, 0), whatever it is, it
          should be defined somewhere
  dbaron: Once we have that definition, it resolves this.

[-- break 20 mins --]

  Scribe: fantasai (with heycam for fantasai)

  fantasai: Key question is what dbaron said, what do we do to
            fragments which are not laid out?

  frremy: A common use case for not laying out a child is when you
          want, e.g. lay out items until you run out of space and then
          have a continuation marker (like ...)
  frremy: you want to just stop laying out at that point
  frremy: Should try to address this in custom layout
  frremy: makes sense to not generate a box for items that aren't laid
          out
  frremy: rather than defaulting to (0,0,0,0)
  frremy: So prefer to define same as 'display: none' or define
          something else similar
  frremy: or throw an exception for now and figure it out later
  frremy: Don't think it's useful to create a box that's zero-sized,
          this isn't useful
  frremy: and not generating the box is sometimes useful
  Rossen: I think not showing things is useful
  myles: max-lines is similar
  Rossen: Should be able to not lay out. If we don't lay out anything,
          the question is would we absolute generate no fragment/box.
          Would we end up with an empty size and origin position?

  Rossen: We still have to answer questions like from the OM, what's
          the size/position
  Rossen: So what would make the most sense?
  frremy: Compromise would be to have a box at zero/zero, but it just
          doesn't paint
  iank: Agree that we should say it doesn't paint.
  iank: but what about the rest of the subtree?
  iank: Do we return zero for everything all the way down the subtree,
        or do we continue with layout?

  fantasai: For max-lines specifically, from an implementation
            perspective, I think it does make sense to lay everything
            out
  fantasai: That's a use case where you want to hide and show things
            dynamically, not having to re-layout would be useful
  fantasai: More generally I'm not sure
  fantasai: If you're not going to display the stuff
  fantasai: but you could display:none things you don't want to display
  Rossen: But this is a layout time decision
  eae: For max-lines it would be nice to not reflow things that aren't
       going to be displayed, unnecessary work
  koji: This could create next fragments, it's more about
        fragmentation, when the next fragment container is missing
  fantasai: You could make the same argument here
  fantasai: We will support fragmentation

  iank: It might be reasonable to say layout doesn't happen, and all
        CSSOM APIs return zero, getClientRects doesn't anything
  iank: Saying all this without impl experience, might change opinion
        based on experience
  iank: Everything returns zero, empty array for line boxes
  dbaron: I think this is a magical semi-displayed case
  dbaron: I'd rather have a layout and have the APIs return a
          consistent state
  iank: We could also define a consistent state
  dbaron: Sounds messy
  iank: I'm a little bit torn, agree with fremy that use cases for
        this are very valuable

  Rossen: Another lens to use for reasoning, how would you serialize
         your collection of children in the case that frremy gave?
  Rossen: e.g. for accessibility purposes
  Rossen: Would want accessibility tool to walk the same tree as
          what's visible
  Rossen: Would you synthesize things in the AT or what?
  iank: Not accessible to normal users, so shouldn't be accessible to
        AT
  iank: The way to make this decision would be, what should happen in
        the max-lines case?
  iank: Could also punt this for now, get impl experience

  iank: Our current behavior is that you need to return all the
        fragments. Otherwise we'll fall back to block layout
  Rossen: That's nice. Very predictable and verifiable
  iank: We should investigate, then reopen this issue.
  Rossen: In which case, this is an error
  iank: Yep
  Rossen: Fix your code. Make it work.
  heycam: I think it might be easy to accidentally lose your custom
          layout
  Rossen: Exactly
  heycam: Might be that you change your ordering in certain window
          sizes, and then it breaks
  fantasai: I think if you can't loop correctly over all the items in
            this list ...
  Rossen: You shouldn't be doing custom layout.
  iank: Grid iterates in a particular order
  frremy: But here you need to iterate in the right order

  Rossen: Sounds like for this level of where we are, this is a
          reasonable error case handling
  Rossen: It is simple, it's easy to describe, and should be easy to
          fix on the script side
  Rossen: With that, plus previous two resolutions, then we have a
          clear answer to what happens with abspos children
  Rossen: If we need to get more sophisticated later, we can
  Rossen: Implementation experience may suggest a better pattern
  frremy: Would need to feature detect somehow, whether the browser
          supports laying out all the boxes or not

  iank: Need to resolve on this, then: if you don't return all the
        fragments, we return an error and fall back to block layout
  iank: Falling back to block layout is what happens if the layout
        function throws an error
  iank: You can check by ...
  heycam: What about existing content, that falls back to block
          currently and throws an error, and then later it starts to
          drop content
  fantasai: Could fall back to content disappears?
  fantasai: But we don't like dropping content
  Rossen: We could fall back to 100em bright red...
  iank: Two ways to deal with that.
  iank: One is to use-count
  iank: Other, if that number is sufficiently high, we can add a
        layout option
  iank: It's a bit heavy handed
  iank: but we can use-count it to check
  ...
  philipwalton: Could put a note in the spec explaining what we're
                planning to do
  Rossen: This is simple, easy to spec, easy to explain, easy to see
          if you messed up. Can revisit later. It's a good solution.

  RESOLVED: Custom layout must return all fragments, otherwise return
            an error and fall back to block layout.

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

  iank: Did some benchmarking
  iank: The Promise solution is slightly slower, but not that much
        slower
  iank: That makes me lean towards Promises solution
  iank: Advantage of generator is that it's faster, don't have to kick
        the ? every time
  iank: there's some overhead for doing that
  iank: However, I think that's acceptable from an author expectation
        perspective
  iank: If it was 30-40% overhead, that might be a concern
  iank: but turned out to be not as much of a problem

  Rossen: What did you test?
  iank: Test was 100 custom layout elements
  iank: Went about 6 layers deep, and had two child nodes at each
        level and 4 leaf nodes
  iank: tree structure, roughly 100 nodes
  iank: used our perf testing framework
  iank: I did a synchronous version of the API, didn't have any
        generators, promises, etc. Just executed synchronously
  iank: That was about 650 runs per second
  iank: Our current impl was about 430 runs per second
  iank: so 50% off the synchronous one
  iank: Promises was 450 runs per second
  iank: Might be able to get it faster, push around 500 or something

  iank: We do lose a lot of performance by allowing async here
  iank: so something else to consider
  iank: One thing we could revisit later is, asynchronous layout
        engines
  iank: we could potentially get performance by exposing synchronous
        versions of layout APIs
  iank: so leave that door open
  iank: I'll need to do some work, spec wise, to get it so that an
        impl can run this synchronously
  iank: Still requires a queue to go through layout requests
  iank: Once I've got that written down, make sure it makes sense to
        everyone

  frremy: What if you await Promise that never returns?
  iank: When you call layoutNextFragment(), pushes a request onto an
        internal queue. If layout engine has exhausted that queue
  iank: It'll keep queuing its own tasks, flush that queue and check
        if resolved promise is done
  iank: If [missed]
  iank: Summary of the engine is, layoutnextfragment()), pushes onto
        internal queue for custom layout instance. Layout engine will
        enqueue a microtask.
  iank: Lay everything out and then queue itself again in case extra
        work
  iank: if it finishes, then... if promise is resolved, then done

  Rossen: So, resolution is to switch back to Promises
  Rossen: Any additional comments or objections?

  eae: Can we add a note about error-handling expectations?
  ACTION: iank to add note about error-handling expectations

  RESOLVED: Use Promises (and add note)

Naming for percentageInlineSize / percentageBlockSize
-----------------------------------------------------
  github: https://github.com/w3c/css-houdini-drafts/issues/437

  fantasai: Could also do inlinePercentBasis / blockPercentBasis
  iank: This is what you resolve percentage sizes against
  Rossen: “percentResolutionBasis” is kindof what this is about
  Rossen: but that's kinda verbose
  frremy: Issue was that there was some confusion, wanted to make it
          less confusing
  iank: It's easy to guess what the other names are, wanted to keep
        this one consistent
  iank: e.g. availableInlineSize / availableBlockSize
  Rossen: inlinePercentBase / blockPercentBase
  Rossen: Let's close this no change
  Rossen: Get an option more people would be excited about

  RESOLVED: No change

Intrinsic sizes and orthogonal children behaviour
-------------------------------------------------
  github: https://github.com/w3c/css-houdini-drafts/issues/776

  iank: I can say what I expect
  iank: I expect that Sizes is the intrinsic size contribution of that
        child in the parent's writing mode
  iank: Different engines will calculate it differently
  Rossen: That sounds overly vague for it to be any kind of definition
          in the spec

  fantasai: You're trying to say that the result of that should be the
            same thing that the layout engine uses for intrinsic size
            calculation
  fantasai: whether it's shrink to fit on [various things], intrinsic
            size keywords, ...
  fantasai: They should all return the same thing, which is the thing
            returned here, and just be clear about which axis we're
            grabbing from
  fantasai: I think we can put that in the spec, and is definite
            enough to not be vague
  fantasai: It's exactly what we're doing in the sizing spec in a
            number of cases: we don't define how to calculate the
            intrinsic size, but we require it's consistent across all
            the places we use it
  Rossen: I agree

  RESOLVED: Intrinsic size in orthogonal flows are taken according to
            the writing mode of the containing block, and
            intrinsic size calculations have to be consistent with all
            other places in CSS (per CSS Sizing).

Typed OM
========

  TabAtkins: No open issues to discuss, just a bunch of edits I need
             to make
  TabAtkins: Unless someone has an issue to discuss
  Chris: List of changes, DoC?
  TabAtkins: No
  fantasai: We should get TabAtkins's edits, publish a WD, issue a
            Last Call, wait a few weeks, and then go to CR

  TabAtkins: We have an implementation, one of our engineers is
             working on it.
  Rossen: Firefox?
  heycam: Not of Typed OM
  heycam: Q4 someone should start looking at it for Firefox
  fantasai: Is Blink shipping the implementation?
  eae: Yes

  dino: Does it have benefits? Is it faster?
  TabAtkins: Much faster for animations, e.g.
  shane: Performance numbers in the intent to ship
  tantek: You do that without it being in CR?
  tantek: Without anyone else implementing it? wow.
  shane: Depends on various factors, but yes.

  TabAtkins: Bunch of edits, but biggest task is filling in
             serialization of properties appendix
  TabAtkins: And that's easy for someone else to work on
  Rossen: frremy ?
  frremy: Sure.

  RESOLVED: Add frremy as co-editor on css-typed-om, move nainar to
            former editor

Custom Paint
============

  fantasai: Wasn't Paint supposed to be a CR?
  [people can't remember what's going on]
  [WD was published:
https://lists.w3.org/Archives/Public/www-style/2018Apr/0036.html ]
  fantasai: Are there any open issues on the spec?
  iank: One open issue.
  fantasai: Then let's close it and go to CR.

Optional arguments in paint functions
-------------------------------------
  github: https://github.com/w3c/css-houdini-drafts/issues/763

  TabAtkins: Somebody wants optional arguments in paint functions
  TabAtkins: It's a very reasonable request
  TabAtkins: However, this falls under the more general issue of
             optional bits of syntax in custom properties
  TabAtkins: which is currently not allowed because of issues around
             parsing ambiguity
  TabAtkins: So we need disambiguation support first

  florian: Is this a hard problem, or we need to solve it but haven't
           yet?
  TabAtkins: latter
  TabAtkins: Definitely not impossible
  TabAtkins: Support for more syntax-y things is slated for L2
  fantasai: So proposal is close deferred to next level?
  TabAtkins: That's what I would like
  Rossen: Any other opinions?

  RESOLVED: Deferred to L2

Publication
-----------

  fantasai: Is there anything else is needed for the spec?
  iank: No
  TabAtkins: TypedOM has changed how it handles image values
  TabAtkins: which might affect this, but it's not affecting this spec

  Rossen: Any objections to taking Paint API to CR?
  Rossen: No? Resolved.

  RESOLVED: Custom Paint to CR

  Chris: DoC? Changes List?
  <dbaron> there were 3 or 4 edits since the last TR version
  <dbaron> https://hg.css-houdini.org/drafts/rev/3a0546211ec0
           https://hg.css-houdini.org/drafts/rev/61ae417ae9ee
           https://hg.css-houdini.org/drafts/rev/acb3d3f259ce
  [discussion of administrative stuff to get to CR]
  fantasai: I can help IanK make the DoC and stuff

CSS Animation Worklets
======================

  TabAtkins: Nobody is here. Let's skip
  ACTION: iank to move spec to houdini repo

Implementation
==============

  Rossen: Demos and then lunch?
  Rossen: Or pressure IanK to do edits
  shane: We could spend the afternoon on getting the specs to CR.
  RESOLVED: IanK, shane, Tab, fantasai, and ChrisL to stay the
            afternoon and get specs to CR.

  dino: Other browser implementations of custom layout / paint / etc?
  Rossen: Custom layout only in Blink
  iank: Experimental. Going smoothly, might do an origin trial later
        this year
  iank: If authors like it, don't find any issues, will push for CR.
  heycam: We won't be looking at custom paint or layout this year.
          Pushed to next year
  dino: So everything we've discussed today is only implemented in
        Blink, nobody else. That's scary.
  iank: Paint API is simple to implement.
  dino: Worklet is tricky
  ChrisL: You need worklets for Web audio anyway
  dino: It's all new to us

  dbaron: For us the big obstacle might be TypedOM
  dbaron: Feels like biggest dependency of custom paint
  iank: You can do a stripped down version of Typed OM, which
        everything returns CSS style values, and upgrade up
  iank: People can feature-detect that.
  dbaron: I think that would be fine if we were shipping before you,
          that'd be fine
  dbaron: But if shipping 6mo to 1yr later, then we need to implement
          the same featureset you have, otherwise won't work
  dbaron: One question is whether there should be an alternative in
          the API that doesn't use typed OM
  fantasai: If you're going to do that, why not just use what iank said
  iank: Polyfill we've got out at the moment, doesn't use a whole
        bunch of typedOM stuff
  iank: If you just ship the style value part, should still work

  dino: How many WPT do you have?
  iank: Quite a few
  iank: For layout 80-100, more like 150 by the time we're done
  iank: paint API has 65 atm
  iank: Has a lot grouped in together into one test
  iank: Unsure about typed OM...
  iank: It's got like 4000
  [discussion of tests]

  Rossen: WebKit?
  dino: We'd probably do it in order.
  dino: Clearly we need TypedOM for paint, and also will give a lot of
        immediate improvements for developers
  dino: Other things, unsure how we'll prioritize
  dino: You see articles about people saying how cool Houdini is, but
        not so many people giving loud feedback about how they need
        this particular feature
  dino: Hard to gauge what people want more than anything else
  dino: Dunno how we'd prioritize, other than TypedOM coming first

  Rossen: We're in the same boat
  Rossen: It's going to be a sprint or two for us to put things
          together
  Rossen: Google spent significant time and resources getting to where
          they are
  iank: Main cycles for us were typed OM and worklet infrastructure
  iank: Paint stuff was relatively trivial
  iank: Layout stuff isn't particularly difficult once you've got the
        rest of the infrastructure.
  iank: Reason worklet took so long is because we were waiting for ES6
        modules to land
  iank: So we had working in a few months, but took awhile to get up
        to spec compliance
  iank: If we didn't have the ES6 dependency, would've been a lot
        faster
  iank: Paint was just a quarter
  Rossen: Paint seems easiest once you have the infrastructure
  iank: Typed OM was biggest engineering investment
  iank: Paint and layout are trivial after that
  florian: TypedOM was difficult because big, or because churn?
  shane: Both
  shane: We spent a lot of time adjusting spec and implementation in
         response to feedback, which others won't have to do

  Rossen: So, I think summary of implementation status is blink has
          quite a bit ready to go, Firefox has started on some of the
          properties and values, logical next one would be typedOM
  Rossen: WebKit and Edge have not started

  philipwalton: From developer feedback perspective, I don't hear
                people asking for typedOM, I hear a lot of requests
                for paint to animations, and lot for custom properties
                support
  dino: I would've assumed that what people want nowadays is custom
        layout
  dino: They write their react code, and want to do everything
        themselves.
  philipwalton: That was my perspective, but some developers want
                that, not everyone.
  philipwalton: You can't polyfill layout, but you can fallback nicely
                for paint stuff
  philipwalton: So that's what developers want now
  philipwalton: The things they can do now, they want to do
  florian: Also, these things can be easy enough that individual
           developers to do it
  florian: But layout is harder, so more likely waiting for a library
           to be developed; fewer individual users
  leaverou: My impression is also what Philip said. Primary concern
            devs have is transitioning and animating custom
            properties, not just via properties and values API

  leaverou: I've presented this API at several talks
  leaverou: The most common question I get is, why do we have to use
            JS for this? Why can't we have it in an @rule?
  florian: Type declarations, you mean?
  leaverou: Yeah
  frremy: Greg and I have been talking with devs. They're mostly
          unhappy about perf and not having proper APIs for things
          they want to do, not trudging through bad APIs
  ...
  Rossen: When you compare teams with highly-skilled devs on products,
          they will put anything they want, write their own middle
          layer if they need
  Rossen: Some person supporting small website, won't be writing
          custom layout
  iank: A bunch of things Material Design team wants to do, are easy
        in paint API, very difficult without it

  Rossen: OK. Anything else to discuss for houdini?
  dino: Are we meeting at TPAC?
  dino: Also why do we consider separating the groups because ppl are
        in both of them?
  TabAtkins: Not exactly true
  florian: ... split tracks
  TabAtkins: Yes, should meet at TPAC
  Rossen: I have room for Thursday, we have dedicated
  florian: So effectively 3 days for CSSWG at TPAC

  fantasai: The way we have scheduled this year is super uneven
  fantasai: Expect a lot of topics on the agenda for CSSWG at TPAC

  [Meeting closed]

Received on Wednesday, 18 July 2018 22:08:02 UTC