W3C home > Mailing lists > Public > public-houdini@w3.org > February 2016

[Houdini] Minutes Sydney F2F 2016-01-30 Part II: Properties & Values API

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 21 Feb 2016 14:47:25 -0500
Message-ID: <CADhPm3vPzK_cqyuy=N2B1LOw-DP5F_w5+3BKz1GZ8w1zsaK=sA@mail.gmail.com>
To: public-houdini@w3.org
Cc: www-style@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.

Properties & Values API

  - The group decided to go issue by issue and see if enough
      decisions can be made to resolve on FPWD for the spec.
  - Due to implementation complexity, the spec won't introduce
      parse-time errors.
  - It was agreed that registerProperty() and unregisterProperty()
      should not trigger a CSS reparse and instead invoke whatever
      happens when you change style rules through the CSSOM, but the
      spec text needs to explain it better.
  - Apply hook will drop to the next version of the spec.
  - More formal description of registerProperty required, but won't
      block FPWD.
  - A better example using a typed custom property to define a color
      will be added (available here:
  - setProperty will be dropped in V1 in favor of just having types.
      If there's sufficient demand it can be added back in later.
      - The following types will be in the spec:
          - color
          - image (maybe)
          - url (maybe)
          - lists of values
          - transform functions (maybe)
          - url
          - integer?
          - angle
          - time
          - resolution
      - shane will look over animatable types and see if there's any
          others that should be added.
  - The spec will need to do substitution into transition/animation
      properties before animation so that this example works:
      animate: var(--props) var(--dur);


Agenda: https://github.com/w3c/css-houdini-drafts/wiki/Sydney-F2F-January-2016

Scribe: dbaron

Properties and Values API

Spec Overview

  <shane> link to spec:
  <shane> link to issues:
  shane: There's things to look at; the spec itself, and issues list.
  shane: We'll start with spec itself.
  shane: Let's go through inline issues and then those in the issue
         tracker, and work out how to resolve and edit now, or
         decide it can remain in FPWD.
  shane: So that all issues that need to be done for FPWD are done
  shane: Sound good?

  shane: We've been through this spec a couple of times, but if
         people are interested we can go through section by section
  smfr: How about a high-level refresher?
  shane: Properties and values API adds 3 things
  shane: (1) the ability to provide a type for values of custom
         properties, which are the types familiar with, through
         registerProperty where you provide a syntax, e.g. <length>,
         <number>, refer to existing properties
  shane: ... or |-separated list of things
  shane: (2) as a consequence of having types, allows custom
         properties to be animated
  shane: (3) (which I propose we drop) provides an apply hook that
         allows modifying the used value of other properties as a
         result of computed value
  Rossen: Computed?
  shane: Right, computed, not used.

  smfr: How does animation work?
  shane: Just through the types, no customization.
  shane: There's interest in customization for future levels.

registerProperty and unregisterProperty

  shane: Going through issues:
  shane: First issue is: when you call registerProperty and
         unregisterProperty, you need to reevaluate a bunch of stuff.
  shane: ... what we want to say is that you need to re-parse
         specified values of properties which are impacted ...
         properties named in register/unregister, and recompute
         style based on those changes.
  shane: So if I say registerProperty("foo"), I need to find
         references to foo (existing custom property).
  esprehn: Need to reinterpret tokens.
  shane: Need to recompute style.
  shane: I wasn't sure how to write that.
  heycam: What's the existing wording?
  dbaron: I think most existing wording is around static situations.
  esprehn: Invoke wording about how variables change?

  heycam: What happens with .style setters, zcorpan?
  zcorpan: They set a string, gets parsed, becomes part of cascade.
  heycam: So it updates style sheet, and implicitly recomputes.

  shane: One thing that isn't completely clear is that registering a
         property can change a declaration from compute-time invalid
         to being parse-time invalid.
  heycam: So this introduces parse-time invalid for custom
  shane: Yes.
  shane: --foo: url('donkey'); color: red; color: var(--foo); is
         computed-time invalid.
  heycam/dbaron: but color: var(--foo); is always valid at parse
  dbaron/esprehn: Agree var(--foo) shouldn't become parse-time
                  invalid as a result of registerProperty.
  esprehn: The thing you want to refer to is re-invoke the
           "Substitute a property" algorithm.
  <esprehn> https://drafts.csswg.org/css-variables/#substitute-a-var
  <esprehn> we want to modify that to support types, and whenever
            the type changes, you run that algorithm again.

  ojan: Why do you want a parse-time error?
  shane: It's only a weak desire, but adding understanding of
         computed-time invalid was something I hoped we could undo.
  ojan/dbaron: It adds a lot of implementation complexity.
  shane: Okay, let's not do it.

  esprehn: None of this happens at parse time -- tokens that get
           substituted in.
  esprehn: Type information just says that if you register, check
           that the tokens are the right type.
  ojan: With --foo: red; --foo: url('donkey'); we'd need to keep
        both around in case somebody called registerProperty on foo.
  shane: So you need to keep around multiple?
  shane: As long as it's ok for custom properties to fundamentally
         behave differently from standard properties...
  ojan: I like the simplicity, but makes it hard to get polyfills
  shane: Implementations can choose to do another parse run after
  heycam: If the type information were at the top of the style
          sheet, could avoid sudden change.
  heycam: Local to the style sheet.
  shane: Too much of a restriction -- polyfill would have to infect
         all style sheets.
  dino: <barely audible>
  shane: If you have a handle on a style rule through the CSS OM,
         that shouldn't change.
  dbaron: We don't have lazy parsing of declarations.
  shane: Neither do we.
  esprehn: Can't evolve the API, e.g., can't write the old thing
           first and then overwrite with the new thing

  heycam: Do typed things work inside @supports?
  shane: We haven't decided.
  shane: It's clear we need this to happen.
  dbaron: We need to be very careful if you can put things in
          @supports that change what engine supports.
  heycam: I think parse-time rejection would be ok for us.
  shane: Calls to registerProperty will require reparsing.
  heycam: ...
  dbaron: It requires storing the whole cascade of token streams,
          not just winning one.
  ojan: I'm reluctantly ok with this for blink now that we've talked
        about it. Need to tell authors to call registerProperty up
  shane: If you call registerProperty halfway through, you might...
  <shane> https://github.com/w3c/css-houdini-drafts/issues/63
  shane: we need this (github comment link) to be true
  <zcorpan> https://github.com/w3c/css-houdini-drafts/issues/63#issuecomment-177034609

  [heycam and shans clarify example and heycam agrees with comment]
  ojan: What happens if you try to register same property twice?
  iank/esprehn: It throws.
  ojan: I think this is a bad idea, but I'll propose: what if you
        say that registerProperty on a property that's been parsed
  iank/esprehn: racy.
  ojan: yeah, ok.
  shane: Come back to issue of how to phrase correctly.
  dbaron: I *think* it *changes* the specified value
  shane: Or can fix after FPWD.
  dbaron: Or at lunch.
  shane: Do we need the pseudo attribute on ....
  shane: Oh, wait, we're going to drop apply

  shane: Issues 2, 3, 4, 5, 6, 7, 8, and 9 don't matter
  ojan: Thing I'm sad to lose about dropping apply, need apply hook
        for polyfilling something like flexbox, since children of
        flexbox get coerced to display:block -- need apply hook to
        do that.
  ojan: Similarly for grid.
  iank: Also potentially another hook before layout, creating
        anonymous boxes.
  ojan: But supportive of dropping for v1, not mission critical for
  surma: Wouldn't you polyfill flexbox with layout worker, not with
  ojan: But if we had layout, you'd need apply hook.
  shane: When I remove it from here, I'll move it to a level 2 spec.

  heycam: High-level question; how will authors be polyfilling
          properties -- can't use official property names -- will
          they work like they do with prefixes, and then have
          another line that's the -- version?
  shane: Depending on how we can get custom paint and custom layout
         to perform, we may never need the not -- version.
  shane: I think it'll almost certainly be true of custom paint.
  shane: Many examples of people constructing complex DOM trees that
         are much better replaced by custom paint.
  shane: People can write custom border/background polyfills that
         are permanently polyfills.
  ojan: The thing I said makes no sense -- really developers will
        just need to switch over at some point, since we won't have
        magic that makes foo override --foo.
  dino: Maybe people will want to use the implementation version if
        it's there
  zcorpan: I was thinking you would use the standard property in
           @supports and unset the -- version there probably
  <zcorpan> though one can do @supports (not (foo)) { x { --foo:
            ... } } instead
  shane: If supported, could also registerProperty to an
         always-invalid thing so declarations dropped at parse time.

  shane: Houdini issue #67 -- seems like we can go to FPWD without
         an algorithmic description -- just a set of requirements.
  iank: Covers corner cases like which error you get when you do 2
        things wrong.
  heycam: Seems good enough.


  shane: We need to add an example -- using a typed custom property
         to define a color that's then used as a single stop in a
         gradient to animate a single stop.
  (shane types example into github issue #77;

  [discussion about difference between "<color>" and "<'color'>" in
parser syntax]
  <zcorpan> Value: <color> --
  dbaron: In this particular case they're the same.
  ojan: So this consistency is to match something that's only in
        specs today and not exposed to authors?
  dbaron: "<'z-index'>" references the values accepted by z-index;
          "<length>", "<number>", etc., are types.

  [esprehn and shane discuss implementation details]
  [esprehn doesn't like this]
  esprehn: It's not that simple in all engines.
  (Apple bison parser)
  heycam: It seems like you already have setProperty in the OM
  esprehn: Why is this a v1 feature rather than only types?
  dino: Yeah.
  shane: I could drop it and go back and improve the set of types in
         the spec.
  ojan: Between impl complexity and weird syntax worth dropping for
  ojan: and get back if we get developer demand.
  shane: It makes it impossible to tie a custom property syntax to
         an existing complicated property (e.g., shorthand).
  shane: Can't do things like the background shorthand.
  shane: This would be a single longhand custom property that you
         want to substitute into a shorthand later on.
  zcorpan: It seems a bit weird; might make harder to introduce real
           shorthands to API later on.
  shane: I can see weird; not clear how it makes it harder to
         introduce real shorthands.
  shane: Just for interaction with existing ...
  shane: In terms of paint use cases this is unimportant.
  shane: We need a more primitive level of type to do animation
         properly, so let's just drop it.
  iank: If we ever do it, "<'--foo'>" shouldn't be valid.

  shane: We have <length>, <number>, <percentage>,
         <length-percentage>, <custom-ident>, any ident
  [shane explains each]
  shane: We obviously need to add <color>.
  dbaron: Should we look over list of animatable types in
  dbaron: Maybe have <integer> vs. <number> -- most of the rest of
          is more complex.
  zcorpan: <angle>
  dbaron: and maybe also <time>
  zcorpan: <frequency> ?
  (discussion, probably not)
  smfr: What about lists?
  ojan: How do urls ... what's their type?
  ojan: It turns into image in most cases?
  [discussion about <image> type]
  dbaron: I think if you add <image>, you should probably also add
          <url> as an independent one.
  zcorpan: <resolution> (dpi/dppx).

  shans: Transform functions.
  esprehn: That's not a v1 feature.
  shane: There's strong animation use cases.
  shane: Not any harder than other ones.
  surma: does that include ???.
  esprehn: ...
  shane: That's already in the typed OM

  zcorpan: <position> type for background-position.
  dbaron: Probably not go down that rabbit hole.
  shane: We could have some form of rounding behavior for integers
         in typed OM rather than having different types,
  shane: and avoid having separate integer type.
  shane: I'm inclined to drop <integer> at this point.
  ojan: I think most critical thing is how soon to get multiple
        interoperable implementations, so would like to cut for v1.
  shane: We can drop angle, time, resolution, integer, url... keep
         lists of values, transform functions.
  [shane edits comment on new github issue he's creating;

  surma: What about timing functions for animations?
  shane: We're allowing use of the existing animation framework, so
         don't need that here...

  zcorpan: <image> contains <url>; doesn't make sense to drop <url>
           and keep <image>
  esprehn: For just animations, smaller list, but custom paint wants
           <url> and <image>
  <zcorpan> <image> = <url> | <image()> | <image-set()> | <element()>
            | <cross-fade()> | <gradient>
  dbaron: I'm worried about hacks where people use <image> when they
          mean <url>.
  shane: Do we even need <image> rather than just <url>?
  iank: One thing I was thinking for custom paint is that you have a
        handle you can draw to canvas rather than the bytes.
  iank: I think they're actually 2 separate things -- keep <image>
        but don't allow getting at the bytes
  ojan: This is not the existing image type
  shane: It is... the typed OM representation of the image type.
  heycam: I have some reservations about <image> vs <url> and
          treating them differently.
  heycam: If you could accept all CSS meta-syntax, if you decomposed
          <image> into how it was defined in the spec, it would be
          weird if it was defined differently.
  ojan: Say image url and transform functions are maybes, and we'll
        get back to them once discuss custom paint.
  shane: For some of these (color), how it's animated is the same
         across all properties, but for lists of values, there are
         different sorts of animation behavior.
  shane: Transforms has non-repeating list and repeating list.
  shane: It's fairly standard; list valued properties adopt one or
         the other.

  shane: One last issue, github issue #79 in css-houdini-drafts;
  shane: This example works per the custom properties spec,
  shane: but once we have typed properties, it won't work.
  dbaron: I don't see why it doesn't work.
  dbaron: I think ticking transitions/animations happens before
          computation -- transitions/animations affect computed
  shane: Maybe this is an implementation detail?
  shane: If everybody is clear that this should produce an animation
         of width, maybe just put example in spec.

  ojan: Question for implementors: does this animating make sense?
  dino: The whole thing is crazy.
  surma: People will try transitioning on their custom properties.
  ojan: This example and the one above it should behave the same.
  dbaron: It makes sense to me that they both work.
  shane: I'll import second one as example directly into spec.

  shane: To go back... want to ask one question about issue #99
  shane: Specifically, dino and smfr, which is better for you?
         Better to have a list of things or to reference property
  smfr: I prefer explicit list; referencing properties is harder for
  smfr: Angle, time, and resolution are just simple combinations of
        number + unit -- seems sad to defer them.
  shane: OK, can just put back on.

  shane: A little grunt work to get spec ready -- would like
         volunteers to help with that.
  dbaron: I can help.
  Rossen: Do we need a resolution to publish?
  shane: Let's make edits first, then come back for resolution.

  <br type=lunch>
Received on Sunday, 21 February 2016 19:48:25 UTC

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