[Houdini] Minutes Sydney F2F 2018-07-02 Part I: Properties and Values, Layout API

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


Properties and Values
---------------------

  - RESOLVED: Add custom property observers to L1 of Properties and
              Values. (Issue #555)
  - The PR in issue #767 (Multiple base URLs) should be merged in and
      a WPT added if there isn't already one.
  - RESOLVED: Add # to Properties and Values grammar syntax with the
              same definition and abilities as +. (Issue #768)

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

  - RESOLVED: No change in behavior [around constructors for layout
              fragments], add a note as to why constructors are not
              exposed. (Issue #760)
  - RESOLVED: Add a new LayoutFragmentResult object with a
              constructor. (Issue #760)
  - RESOLVED: Keep the layoutNextFragment name. (Issue #760)

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

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

Present:
  Rachel Andrew, Invited Expert
  Rossen Atanassov, Microsoft
  Tab Atkins-Bittner, Google
  L. David Baron, Mozilla
  Brian Birtles, Mozilla
  Tantek Çelik, Mozilla
  Emil A Eklund, Google
  Elika Etemad, Invited Expert
  Koji Ishii, Google
  Dean Jackson, Apple
  Ian Kilpatrick, Google
  Chris Lilley, W3C
  Peter Linss, Invited Expert, TAG
  Myles C. Maxfield, Apple
  Cameron McCormack, Mozilla
  Xidorn Quan, Mozilla
  Francois Remy, Microsoft
  Alan Stearns, Adobe
  Shane Stephens, Google
  Lea Verou, Invited Expert
  Philip Walton, Google
  Eric Willigers, Google

Scribe: heycam

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

Properties and Values
=====================

Editors
-------

  TabAtkins: One thing is editorship, since Shane is leaving
  Rossen: Who are the current editors?
  Rossen: We currently have Tab Atkins, Daniel Glazman, Alan Stearns,
          and Greg W.
  astearns: This surprises me.

  Rossen: There are currently two issues in this spec
  TabAtkins: There are a few in GitHub.
  shane: 16 open, a few need edits.
  TabAtkins: We can run over them.

Observer for property being applied?
------------------------------------
  github: https://github.com/w3c/css-houdini-drafts/issues/555

  TabAtkins: This has been something we're aiming for at some point
  TabAtkins: You want to be able to observe when and where a given
             custom property is put on an element
  TabAtkins: Right now the best you can do is you can do some
             processing on a custom prop, tell what grammar it's meant
             to have
  TabAtkins: You can't say that for every element with this property,
             do this JS
  TabAtkins: Only way right now is to walk the tree and ask the style
             for every element, not great to do in a tight loop
  TabAtkins: We already have things like this
  TabAtkins: xidorn pointed out you can use the transition events to
             get at this
  TabAtkins: but that's hacky, clearly
  TabAtkins: we're planning on this for level 2
  TabAtkins: At minimum, to observe specified values
  TabAtkins: and older proposal shunted out is for computed value
             hooks, don't know if we want to do that immediately
  TabAtkins: We have to define in more detail how that interacts with
             animations and transitions, which is complicated
  TabAtkins: so at least getting the specified value out of things is
             probably worthwhile
  TabAtkins: So we could put it in this level, or wait to the next
             level

  iank: This would only be useful for non-inherited properties
  iank: otherwise you are going to walk the whole tree anyway, because
        everything is ...
  TabAtkins: You would only do it for everything that doesn't have the
             initial value.
  shane: Unless, like observers, they're applied per element
  shane: in which case the inheritance doesn't matter
  iank: I think the use case is that you want to do some
        computation ...
  TabAtkins: Here's an example from a script that does this
  TabAtkins: A bunch of things they need extra JS for
  <TabAtkins> http://endtwist.github.io/kerning.js/
  TabAtkins: So I think it will be find on specified values for now

  iank: We're getting someone ramped up to finish the P&V
        implementation
  iank: had it landed behind a flag for 18 months now
  iank: getting it finished off next quarter
  iank: Given the number of cool demos, shipping it before Christmas
  Rossen: End of 2018
  iank: Probably earlier
  Rossen: The reason I'm asking, is the current proposed feature for
          Level 1, that's fine, it's still a WD
  Rossen: so I'm curious whether you're pressing to start shipping, we
          might need to start stabilizing this spec
  Rossen: With that said, I think it's still worthwhile to take this
          in L1 and see if we can make progress
  TabAtkins: Anyone else have implementation?
  heycam: We have half an impl, might pick up again in Q4 but probably
          not ready to ship in Q4
  TabAtkins: I'm going to fill in the parser section on how to parse a
             grammar string
  TabAtkins: obvious but handwavy
  TabAtkins: I have a lot of edits to apply to the spec

  Rossen: For this particular issue, we are resolving to have the
          observer for custom properties in L1, see how it goes
  Rossen: Concerns or objections?
  fantasai: I would say mark it as risk, I know we're not in CR now
  Rossen: We can do it once we get closer to CR

  dbaron: One other comment is, I think this is at a stage where it's
          ok to be adding new features, as long as they're reasonably
          solidly specified off the bat
  dbaron: So I think it's ok to add this if the text gets written
          relatively soonish and gets reviewed relatively soonish
  <fantasai> +1 to dbaron
  TabAtkins: I can promise to have the text written, and do as many
             other edits as I can, by the end of this month
  fantasai: Stabilizing for CR takes time, we don't want freshly added
            text that is shaky

  dino: The way this spec is now, it allows you to specify a way to
        interpolate custom props
  iank: You can define it to be non inherited
  iank: and also give it an initial value
  TabAtkins: And a level of grammar checking
  dino: Parse errors
  TabAtkins: Yes
  iank: A lot of demos at the moment are using it for animation, Ana
        Tudor has a bunch
  <iank> Ana Tudor demo: https://codepen.io/thebabydino/pen/MrZvNm
         (chrome canary + flag)
  iank: that's probably the biggest value as a standalone spec
  TabAtkins: This feature will be a huge uptick in use cases, when you
             can tell what elements have that property applied
  TabAtkins: So you think it should go in L1 to increase the value of
             the spec
  dino: I'm not necessarily saying that
  dino: but I'm fine with it

  philipwalton: Do we have any other observers?
  philipwalton: Are we thinking too small just looking at custom
                properties?
  TabAtkins: Possibly
  TabAtkins: The API shape that's in my head right now can definitely
             work with any property, just a string name
  TabAtkins: Only defined it for custom properties at the moment, but
             no objection to widening it if there's reasonable use
             cases and no major implementation issues
  TabAtkins: I know we handle custom props a bit differently from
             regular props
  TabAtkins: If you have use cases, please put it into the issue
  philipwalton: I think a lot of these use cases would be handled by
                calc() on the property
  dino: Might be nice to put more examples in, beyond animations
  dino: parse errors, non-inheriting, ...
  TabAtkins: Definitely.

  iank: [demos Ana Tudor's demo: https://codepen.io/thebabydino/pen/MrZvNm ]
  dino: So she's registering custom props for height, shadow,
        width, ...
  iank: Specifying things as angles, numbers
  iank: and then she's plumbing them into a huge transform effectively
  iank: So you can see scale effects, ...
  iank: all driven by one big transform, but animating different parts
        of the animation separately
  iank: and then setting a bunch of animations on it
  TabAtkins: It's being driven by one big transform prop, but
             independent animations on bits of it
  TabAtkins: This is a one element demo
  ericwilligers: This is one of the motivations for the separate
                 translate/scale/... props
  frremy: She also has a demo animating gradients
  TabAtkins: Several examples of gradient animation

  RESOLVED: Add custom property observers to L1 of Properties and
            Values

Multiple base URLs
------------------
  github: https://github.com/w3c/css-houdini-drafts/issues/767

  TabAtkins: There was a question of how should URLs resolve in a
             typed custom prop
  TabAtkins: If you give it an image type, how should you absolutize it
  TabAtkins: The resolution was to resolve like it would a real
             property, relative to the file it's in
  heycam: So where it was declared
  TabAtkins: Yes
  TabAtkins: As opposed to an untyped property, in which case the URL
             gets resolved in the property declaration where it gets
             substituted in

  TabAtkins: Now on to issue 767
  TabAtkins: Here we have two separate custom props, in two different
             style sheets
  TabAtkins: declaring relative URLs. And in a third style sheet,
             using the two together in a background-image
  TabAtkins: The question is, how will these resolve according to
             where the custom prop was declared?
  TabAtkins: The answer is yes
  astearns: There's a PR in the issue
  iank: This is Anders in Oslo, working on Blink
  fantasai: Seems reasonable to me

  dbaron: Even better would be a WPT
  iank: Anders will definitely add one
  TabAtkins: No resolution needed then

  astearns: Should Anders be an editor?
  TabAtkins: He's not in the WG yet
  eae: Probably not yet

Allow comma-separated lists in registered properties
----------------------------------------------------
  github: https://github.com/w3c/css-houdini-drafts/issues/768

  TabAtkins: The request is from Sam Richard, pointing out a lot of
             properties are comma separated lists
  TabAtkins: Right now the grammar for custom props allows just values
             separated by spaces, no repetition
  TabAtkins: I think it's reasonable to allow top level comma
             repetition
  TabAtkins: Would be happy to put this into the syntax spec

  fantasai: Do we have the ability to repeat without commas?
  TabAtkins: No
  TabAtkins: Not currently
  fantasai: Then I think those two should be added together, so people
            aren't forced to add commas just because they want
            repetition even when it would be inappropriate to use
            commas
  TabAtkins: That's probably reasonable
  TabAtkins: The grammar work to allow commas like a CSS grammar is
             similar to the work for space repetition
  TabAtkins: Will have to add a way to make that unambiguous, require
             the repeating part at the end or something

  birtles: We also need to specify how to animate the lists, if
           they're mismatched lengths
  <dbaron> (animation types are in
https://drafts.csswg.org/css-transitions/#interpolated-types )
  fantasai: Currently do you have multi valued properties at all?
  TabAtkins: Yes
  TabAtkins: Right now, you can do space separated repetition, but
             only of the entire thing
  fantasai: So you would add comma repetition of the entire thing
  TabAtkins: We don't have brackets yet
  fantasai: You just need a hash
  TabAtkins: That would only allow <length>#, not [<length> |
             <percentage>]#
  TabAtkins: Can only repeat a single term
  fantasai: That's a limitation currently for space separated values
  TabAtkins: Yes
  TabAtkins: At minimum, just adding that would work out ok though

  TabAtkins: The big issue is to define what the default list
             animation behavior is, and possibly allow a way to change
             which behavior you want there
  fantasai: Don't you have that question for <length>+ as well?
  TabAtkins: I'm not sure how that one animates
  TabAtkins: I think they just have to match in length right now
  dbaron: So that's the "simple list" definition in Transitions
  dbaron: The least common denominator thing is a generic thing that
          repeats the list
  dbaron: There are other things like for shadows with values used to
          fill missing spots
  dbaron: filters should have something similar
  TabAtkins: I think it does

  frremy: I think we should try to find an easy way to handle
          animations now in L1, then look at more complicated
          animations in L2
  frremy: I feel like we should have an easy answer in L1, try to find
          use cases for more something complex
  TabAtkins: So we can use simple list behavior now, then figure out
             what we need for later

  TabAtkins: Objections to adding the # multiplier to L1 grammar?
  dbaron: Adding both the # and +?
  TabAtkins: + is already in the grammar
  Rossen: Any objections?
  fantasai: So add # with the same definition and abilities as +

  RESOLVED: Add # to Properties and Values grammar syntax with the same
            definition and abilities as +

Properties and values API generally, again
------------------------------------------

  dino: Google has implemented it behind a flag, hopefully by the end
        of the year
  dino: Mozilla has a vague implementation
  heycam: Two vague implementations
  dino: So maybe for Q4 you'll have three vague implementations
  dino: ;)
  iank: For our implementation, most of the work was teaching the
        animation subsystem how to animate these things.

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

TAG feedback
------------
  github: https://github.com/w3c/css-houdini-drafts/issues/760

  iank: This is a bunch of assorted TAG feedback
  iank: A lot of editorial stuff, but 3 or 4 issues we can talk about

  iank: The first one is having a constructor for layout fragments
  iank: In summary, currently today the only thing that can produce a
        layout fragment is the rendering engine
  iank: Call on the child, say lay out this fragment, it does some
        work, and gives back a fragment
  iank: The useful information is the width and height of the
        fragment, and you can return it in your list of children
  iank: Do we want a constructor for this?
  iank: We can add this, I'm not objecting, but the constraint is that
        this isn't a valid fragment you could return to the engine
  iank: Just a placeholder for testing

  Rossen: The current design has a fairly rigid assumption of who can
          produce fragments
  Rossen: and be responsible for their lifetime
  Rossen: and it's not the script, it's the layout engine
  Rossen: Exposing a constructor, you are fooling the user that they
          have control over it
  Rossen: so I would push back on this issue with that reasoning
  eae: Unless it's a valid fragment, it would be more confusing than
       it's worth
  Rossen: Again, it would lead down the path of considering those as
          user space objects when they're actually browser objects
  dbaron: What would it mean to have a real constructor for a fragment?

  iank: What Travis brings up here is events in the platform
  iank: Synthesizing an event through the system
  iank: This is quite often used for testing
  iank: It's not a real event
  iank: They're already second class citizens
  iank: For us, I'm struggling to come up with use cases for
        synthesizing events like that

  Rossen: Again, the fragment projection we give back to the user is
          just an interface with a bunch of functionality to
          interrogate properties
  Rossen: It's meant to be a black box that you can move around and
          that's it
  iank: The things you can read from it are the width, height,
        baseline info in the future, and basically just position it
  iank: If the child is also a custom layout it can pass information
        up via structured cloning
  iank: but that's basically it

  iank: dbaron or plinss anything to add?
  plinss: That's reasonable
  Rossen: Probably something that they didn't grok entirely, and they
          look similar on the surface but they're not
  plinss: In general the TAG likes to see constructors on everything
  plinss: but I agree here
  astearns: Would it make sense to add a note saying usually we have
            constructors but not here?
  Rossen: If it's lacking explanation let's add that

  RESOLVED: No change in behavior, add a note as to why constructors
            are not exposed

  iank: The second point, is that we return an options bag from layout
  iank: which does some magic
  iank: Explicitly you return the child fragments, auto block size,
        some other info
  iank: The engine goes and synthesizes a fragment for you with
        correct internal representation
  iank: Should that operation have a constructor, so you can create a
        new layout result fragment
  iank: and check if that operation fails
  iank: There are some cases where that operation could fail
  iank: For example, you pass it auto block size, create a new result
        fragment, at the moment it's just an options bag
  iank: and then inspect what your output box size is going to be,
        maybe do something different based on that
  iank: The other thing that can fail is when you deserialize the
        extra data you can pass up the tree
  iank: When you try to structured clone that, like adding a
        SharedArrayBuffer or something
  iank: currently we just say it threw an exception
  iank: With a constructor the user could detect that it threw an
        exception
  iank: I think it's reasonable, but would need to work out what the
        constructor's option bag argument would be
  iank: It's not entirely clear to me yet

  frremy: When I tried it, something I found frustrating is you can
          have a big option you want to give, only a few props on the
          object can't be serialized
  frremy: then you have to clone the entire object yourself, by
          removing the stuff you can't serialize
  frremy: Maybe would be nicer to set null for props you can't
          serialize for example
  iank: I think that's a bigger ask
  iank: Structured clone is painful for people to use
  iank: Would that have been useful? there's a bit out of your control
  iank: Would it be useful to ensure that operation doesn't fail?
  frremy: Something like JSON.stringify, with a callback to handle the
          unserializable stuff
  iank: That would be a slightly larger change in the HTML spec
  frremy: I don't think having a constructor would change anything
  frremy: Only solution is to clone
  iank: Would it have been useful to just get say the auto block size?
  frremy: Not sure
  iank: I think that's a reasonable ask, shouldn't be too much work,
        not sure many people would use it
  iank: Can always add it and use count it, remove if it's unused

  iank: We need to add a constructor, not just returning a
        FragmentResultOptions, but a constructor for a type like
        FragmentResult
  iank: then run all the steps for user and layout, structure clone,
        sanitize the output
  iank: By running the constructor you could catch an error that would
        happen during that process
  Rossen: As to the larger question, about expectations of what
          happens if the script starts throwing?
  iank: I think we just fall back
  iank: I think that larger question is just a misunderstanding,
        editorial
  Rossen: Objections to adding the new LayoutFragmentResult object?

  RESOLVED: Add a new LayoutFragmentResult object with a constructor.

  iank: Final piece of discuss-able feedback here
  iank: Confusion about layoutNextFragment name
  iank: Do we want to go back to layout?
  Rossen: No
  Rossen: That's like call everything object
  iank: David or Peter?
  dbaron: I already disagreed with Travis on that one
  frremy: I like that "next fragment" knowing that you're getting a
          fragment
  frremy: "layout" is too general
  iank: Rossen and David want layout
  plinss: I tend to prefer verbosity
  iank: Ian and Francois don't care
  Rossen: Other opinions or objections?

  RESOLVED: Keep the layoutNextFragment name.

Received on Wednesday, 18 July 2018 22:07:54 UTC