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

[Houdini] Minutes Lisbon F2F 2016-09-22 Part III: Next F2F, AnimationWorklet, Serialization of TypedOM, Properties and Values

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 9 Oct 2016 20:39:22 -0400
Message-ID: <CADhPm3tuf+nqfScBSb7O=VGahGazKGXwX3fs2s5ALExnYfupJg@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.
=================================================


Next F2F
--------

  - Pending room availability, Houdini will meet on 10 Jan in
      Seattle.

AnimationWorklet
----------------

  - rbyers walked the group through the updates made to the spec
      which include addressing the worklet and address
      synchronization concerns.
  - There were concerns that this was exposing the ability for
      webdevs to make bad choices. However, it was felt that this
      was no worse than what existed currently.
  - RESOLVED: AnimationWorklet moves to WICG

Serialization of TypedOM
------------------------

  - RESOLVED: Turning a basic property into a shorthand or into a
              list-valued property should work correctly and not
              break things.

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

  - RESOLVED: Replace deregistration with a note that we're likely
              to add it later.
  - RESOLVED: For the grammar accepted by syntax, accept option 3
              (Just take the literal string. register("--foo-*",
              ...) succeeds, has to be written as "--foo-\*: ...;")
  - There was interest in writing spec text to provide a generalized
      resource mechanism by making a dictionary, though this quite
      possibly will end up in level 2.
  - RESOLVED: Use CSS grammar definition syntax for defining grammar
              of custom properties.

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

Agenda: https://github.com/w3c/css-houdini-drafts/wiki/TPAC-F2F-September-2016

Scribe: jet

Next F2F
========

  Rossen: Seattle Jan 11-13 for CSS
  Rossen: MSFT hosting.
  Rossen: Do we want 1 day of Houdini? When?
  Rossen: I suggest Tues 1/10
  Rossen: We'll arrange for 1/10 pending room availability
  Rossen: in Seattle.

  dbaron: Following meeting dates?
  dbaron: April is tougher to schedule (easter & AC meeting)
  Rossen: June or July in Japan also possible per Hiroshi
  shane: let's defer summer scheduling until January?

AnimationWorklet
================

  <nainar> https://github.com/majido/animation-worklet-proposal/blob/gh-pages/README.md
  rbyers: We can scope down to bare minimum now
  rbyers: but that we can get consensus on in ~6 months or so.
  rbyers: Addresses synchronization concerns (eg. scrolling use
          cases)
  rbyers: ...but more synchronization can be a future level.
  rbyers: Addresses Apple feedback via a worklet design.
  dino: How does this cover parallax, spring, etc.
  TabAtkins: Houdini version of Scrolling Animations spec.
  rbyers: [goes over the Explainer]
  rbyers: [shows demo of custom timing function for a fade-in
          animation]

  rbyers: We already throttle rAF based on visibility.
  iank: Animation functions return TypedOM objects.
  dino: When do animations fire?
  esprehn: They start when the animator property is set.
  esprehn: We resolve then apply keyframes when animator prop is set.
  bz: It only returns a current keyframe?
  esprehn: Yes, the JS returns one per callback.
  dino: getComputedStyle() returns ___? run the animation loop first?
  shane: You get a null start time if you query an animation before
         a compositor round-trip
  shane: ...that computes the actual start time.

  dino: Explain root & children?
  rbyers: [demo: parallax scroll]
  rbyers: In this case, root is the document element
  rbyers: and the children are the items animating.
  bz: Is animator-root a comma-separated list?
  rbyers: Yes.

  rbyers: [demo: position-sticky]
  rbyers: Chromium position-sticky implementation won't be built on
          Houdini
  esprehn: but authors can use AnimationWorklets for such use cases.
  dino: Element transforms are clobbered by AnimationWorklet
        mutations?
  rbyers: Yes, just as with other animation libraries today.

  rbyers: [demo: synced scroller]
  rbyers: [shows how animator is slaved to another one]
  rbyers: [shows running demos]
  bz: Why is it hanging off window?
  iank: That will change.

  rbyers: [shows spring demo]

  rbyers: That's it for demos.
  rbyers: Open issues can be seen in GitHub.
  rbyers: Spec will change to apply to all properties (not just
          currently animatable ones).
  rbyers: We want webdevs to be able to reason about performance,
          eg., via console/devtools.
  rbyers: We expect to be able to animate off-main-thread (ie, no
          relayout-causing).
  esprehn: Seems reasonable to animate on main thread when needed.
  rbyers: Yes, but we should warn authors.
  dino: webdevs might make choices that suck on platforms that they
        don't test on.
  dino: eg., watch performance?

  rbyers: API specify root & all children, but not for different
          children.
  rbyers: Do we need that?
  esprehn: will-change is now implicitly set for all animations.
  dino: All the popular animatable properties create stacking
        contexts already anyway.
  rbyers: Are we past skepticism re: JS on the scrolling thread?
          Current design moves to a separate thread, not the
          scrolling thread.
  dino: Safari on iOS scrolls on a UI process.
  rbyers: Edge, Chrome going that way too.
  dino: I think my concerns were re: declarative vs. imperative
        model for these effects.
  rbyers: We should do both.

  dino: Fear of webdevs not using these tools correctly
  dino: are we providing tools that are easily misused?
  dino: With a declarative system, we can change implementations
        under the covers
  dino: but when we expose internals (eg, compositing thread) we get
        constrained to that model in the future.
  Rossen: And further, our architectures are a lot more different
          than say, the Style system
  Rossen: and we all do crazy stuff to get performance.
  Rossen: Edge is moving scrolling lower-level in the OS (not a
          separate process)
  Rossen: and exposing these primitives limits our ability to do
          that.
  rbyers: For user-driven scrolls, you already have to synch every
          frame?
  dino: Not Safari nor Edge.

  ojan: Compare a position:sticky polyfill today
  ojan: that slow down scrolling
  ojan: nothing in this proposal makes that worse.
  rbyers: Now in a worklet, no synch guarantees, but higher chance
          of keeping synch because of separate worklet thread.

  RESOLVED: AnimationWorklet moves to WICG

  <break length=20>

Serialization of TypedOM
========================

  shane: Firefox canonicalizes values for unconnected nodes
  dbaron: We always resolve ems but there are differences for
          computed style when unconnected.
  bz: Or display:none.
  dbaron: But that's mostly just our getComputedStyle serialization.
  esprehn: Would be a different serialization (like getComputedStyle
           but without resolving things that require unavailable
           knowledge, e.g., rem for unconnected font elements)

  shane: 1st phase: canonicalization 2nd phase: resolve relative
         units (eg, ems)
  dbaron: How is canonicalization different from OM getters now?
  shane: Today, either you never do canonicalization, or you do both
         phases.
  TabAtkins: Write out Value types for all of CSS over the next 2
             weeks
  TabAtkins: or just define the representation of everything.
  shane: How about we do that now and come back later?
  dbaron: OK...I just don't want us to invent new things unless
          there's a good reason for them.
  TabAtkins: Where there's no existing serialization, we'll define a
             CSSOM serialization
  TabAtkins: and TypedOM later on will use that.
  gregwhitworth: Will this quantify serialization for specified
                 values?
  shane: Yes.
  TabAtkins: We'll try to match getComputedStyle when we can.
  plinss: Don't carry over bad decisions.
  dbaron: Problem with old CSSOM is that it was poorly specified,
          and thus became UA-specific.
  dbaron: Shorthands does not occur in TypedOM spec.
  TabAtkins: Exist in Style values now.
  shane: Shorthands will be a CSS Style value.
  shane: We'll start with all longhands first.
  dbaron: btw, background-position is a shorthand

  Scribe: fantasai

  TabAtkins: Have to make sure turning a property into a shorthand
             doesn't mess everything up.
  ?: What does StyleValue.parse("backgroundposition", "center
     center") return?
  [answer missed]
  TabAtkins: Need to make sure upgrade to a list value works smoothly
  shane: Need to prepare 400 serialization things, then we can
         discuss stuff.

  RESOLVED: Turning a basic property into a shorthand or into a
            list-valued property should work correctly and not break
            things.

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

Should property deregistration be possible?
-------------------------------------------

  shane: Want to move on to properties and values issues.
  shane: Last issue on agenda topics list is, should property
         deregistration be possible?
  shane: Currently can register and deregister type ? property.
  shane: But people point out custom elements, the houdini of HTML
         world, ...
  [missed]
  shane: Problems with deregistering type of custom properties.
  shane: Requires an expensive flush.
  shane: Or have to carry around a lot of extra values.
  shane: Certain attraction to just not allowing property types to
         be deregistered.

  bkardell: What's the use case for deregistering?
  shane: Don't think there was ever a use case.
  TabAtkins: Because we wanted to have a declarative version of
             property type registration at some point.
  TabAtkins: When that happen, style sheets can go away and change.
  TabAtkins: Mess around with typed OM.
  TabAtkins: Didn't want anything to be time/order dependent.
  esprehn: Requires reprocessing the entire sheet.
  <dbaron> http://dev.w3.org/houdini/css-properties-values-api/
  TabAtkins: Adding or removing a custom property requires reparsing
             the whole sheet.

  Rossen: What is problem of deregistering?
  Rossen: Is there an actual technical reason to disallow it?
  Rossen: I heard something along the lines of hard and
          performance-taxing.
  TabAtkins: Requires the same full-world reparse that adding does.
  ojan: My feeling is the declarative thing you described, we can
        add deregistering when we add that. Don't have to do it now.
  shane: Can we resolve on that?
  plinss: As long as we make sure we don't build on the assumption
          it's not there.
  shane: So maybe add a note that it will be added later.

  RESOLVED: Replace deregistration with a note that we're likely to
            add it later.

Need to define the exact grammar accepted by "syntax"
-----------------------------------------------------

  <shane> (this is https://github.com/w3c/css-houdini-drafts/issues/112)
  TabAtkins: Simon brought this up before ... algos here, e.g.
             register property,
  TabAtkins: Have to take a property name and parse it.
  TabAtkins: Easiest way is to parse as an ident. Allows us to throw
             if it's messed up.
  TabAtkins: Do we have full CSS parsing? E.g. handle escapes,
             comments.
  TabAtkins: Or do we just do simplistic check for ident characters?
  TabAtkins: Simpler concept.
  TabAtkins: Useful possibly for other places in the platform where
             we want to invoke CSS parsing, but don't want to invoke
             comment processing etc.

  plinss: My one concern is that you can use CSS escapes to put in
          characters into the ident that otherwise wouldn't parse.
  TabAtkins: We could take up a straight up string, use that
             directly with no other parsing. Then have to manually
             implement "is this an ident" check, e.g. no spaces.
  dbaron: You can put escaped spaces into an ident.
  TabAtkins: It's extremely weird, can't literally type it.
  plinss: In general I think escaping should be kept where it's
          meant to be used, e.g. no CSS escapes in JS.
  plinss: Use a JS escape in JS.
  plinss: In favor of not doing any CSS parsing here.
  TabAtkins: querySelectorAll uses CSS escapes.
  bz: That's a much more complicated syntax, makes sense to reuse
      CSS parser.
  ...
  bz: In this case plinss was saying just use any valid string as
      the ident.
  SimonSapin: In the APi it's just a property name.
  SimonSapin: But in syntax definition of a custom property, using
              syntax of custom ident with escaping and all that.

  TabAtkins: Oh hey
  TabAtkins: Example {syntax: "red | blue ";}
  TabAtkins: What if I want "red | blue | 3d"?
  TabAtkins: Understand that as an Ident that I want to do.
  SimonSapin: Except it's JS so you'd have to do \\33 d.
  plinss: That's why you don't want to mix escaping.
  TabAtkins: This is invalid, not what I just said, cuz doesn't
             match <custom-ident>.
  TabAtkins: Even though technically possible to have a keyword "3d"
             in CSS if you escape the three w eg --foo: \33 d;
  TabAtkins: You can of course just take a <custom-ident>
             {syntax: "red | blue | <custom-ident>" }
  TabAtkins: But then you're being really weird.
  TabAtkins: So I will change register property to not do anything
             weird, just check it.
  TabAtkins: Right now checking if ident and throwing syntax error,
             then checking if already registered.
  TabAtkins: Can get rid of first check.

  TabAtkins: Oh, I remember why has to be an ident.
  TabAtkins: registerProperty("--foo", ...)
  TabAtkins: Need to check that the first one is a valid ident, so
             that when you write your stylesheet you're writing
             something useful
  TabAtkins: Suppose I put registerProperty("3d", ...);
  TabAtkins: Then .foo { \33 d: ...; } ...
  shane: That would parse as invalid in CSS.
  ...

  bz: So real question is "-- d"
  bz: You can express that as --\ d: ...;
  plinss: I think it's ugly, don't really see why anyone would want
          to do that, but don't see why it's bad.
  plinss: You didn't write CSS escape in JS string, because you're
          not writing CSS, writing JS.
  <SimonSapin> plinss +1
  TabAtkins: Rules for CSS idents are somewhat arcane. e.g.
             "--foo-*" be confused why it doesn't work
  fantasai: I don't think authors will be confused. Most people know
            a CSS ident is alphanumerics plus hyphens. Not gonna try
            that, or if see that expect the star to be some kind of
            magic syntax... if don't know about said magic syntax
            wouldn't try to use it.
  ...
  plinss: Need to escape that in the registered property. "--foo-\\*"
  fremy: In CSS can escape any character, e.g. \o
  plinss: My concern isn't people doing this, my concern is the
          tools.
  TabAtkins: If we throw on this thing, obvious right away.
  plinss: Dunno what custom CSS preprocessors are doing right now.
  plinss: ....
  TabAtkins: Won't work with registerProperty.

  shane: Three options, can we put it for a vote?
  <TabAtkins> 1. Manually check for name chars, then check it's an
                 ident. (register("--foo-*", ...) will throw)
  <TabAtkins> 2. Just parse as custom-ident. register("--foo-\\*",
                 ...) succeeds, has be written as "--foo-\*: ...;"
  <TabAtkins> 3. Just take the literal string. register("--foo-*",
                 ...) succeeds, has to be written as "--foo-\*: ...;"
  <dbaron> 4. instead of escaping the characters, escape from the
              meeting :-)

  shane: Currently CSS allows an ident to include *any* character in
         Unicode, if you use escapes for certain ones. If you do
         some half-parse-check thing, then you're introducing a
         limitation through registerProperty that isn't in CSS.
  TabAtkins: ident check would be reasonable-ASCII or above-ASCII
  fremy: What do we do if you use getPropertyValue.
  SimonSapin: Pretty sure getPropertyValue doesn't do any escaping.
              Just compares strings.
  plinss: Problem with #1 is that --foo-* is a perfectly valid CSS
          property name. Can just use it by escaping * . Now you
          prevent me from using it.
  TabAtkins: getPropertyValue + this plus other thing are new enough
             we can change it later if problematic.
  [Votes:
  <TabAtkins> 1
  <dino> 1
  <plinss> 3
  <shane> 1, then 4
  <fantasai> 3
  <SimonSapin> 3
  <dbaron> 3, then 1
  <nainar> 1
  <frremy> 3
  <surma> 1
  <gregwhitworth> 1
  <iank> 4
  <JakeA> 3
  ]

  shane: No consensus!
  shane: Any objections to doing whatever getPropertyValue does
         right now so we don't have to change it?
  SimonSapin: It does 3

  RESOLVED: 3 (Just take the literal string. register("--foo-*",
            ...) succeeds, has to be written as "--foo-\*: ...;")

Provide generalized resource mechanism
--------------------------------------

  <shane> https://github.com/w3c/css-houdini-drafts/issues/215
  shane: Make a dictionary, use it later.
  shane: @font-face does this.
  shane: @keyframes does this.
  shane: Seems like a useful way of providing bundles of info to
         subsystems in CSS.
  shane: Do we want to ? in custom paint sometime?
  dbaron: Fun issues like scoped style sheets.

  gregwhitworth: Does this feel like a requirement for v1?
  shane: Would want to push to v2, but wanted to get other opinions.
  gregwhitworth: Personally think everything else is really solid,
                 so bringing up something brand new with issues
                 dbaron mentioned, better push to v2.

  eae: Use cases?
  shane: Really nice things, you can specify paint resources in
         custom paint, can ??? rather than having to pass image into
         every single thing.
  shane: But don't have to have for v1.

  shane: Sounds like interest to put into spec prose?
  [general nodding]

How to express syntax of a custom property
------------------------------------------

  shane: Pretty much all I have.
  shane: Saved easiest question for last
  shane: Grammar issue
  TabAtkins: How to express syntax of a custom property.
  TabAtkins: Forcing authors to write CSS grammar in a string would
             be confusing.
  TabAtkins: Instead proposed using the constructors directly.
  TabAtkins: E.g. if only take lengths, instead of taking string
             that says <length>, would take CSSLengthValue (
             represent a length).
  TabAtkins: If take multiple lengths, take an array
  TabAtkins: This doesn't work.
  TabAtkins: We allow other types of combinations other than
             alternations
  TabAtkins: e.g. repetition.
  TabAtkins: We'd have to invent new syntax for that.
  TabAtkins: Also as we expand, we'll want to allow || and &&.
  TabAtkins: Want to allow full range of CSS grammar to be used.
  TabAtkins: Trying to base that on constructors becomes crazy.
  TabAtkins: Seems better to use a grammar syntax designed to do
             that.
  TabAtkins: We have one already: the CSS Grammar Definition Syntax.
  TabAtkins: So we shoudl use this.

  dbaron: Are you starting with a subset?
  TabAtkins: Yes, strictly.
  TabAtkins: Single values, single bar, and the plus combinator. No
             brackets either.
  TabAtkins: But want to expand on that in the future.
  fantasai: I'm strongly in favor of this. Authors who are working
            with CSS will be most familiar with this, and it has the
            full expressivity that we will want.
  leaverou: Totally agree.
  shane: Also lots of resources, easy to look up what it means, or
         to be "I want to be like this property" and just copy the
         grammar from that property.
  ...
  bkardell: By using the grammar, you create a giant crib sheet,
            people can go "I want to be like box-shadow, let me look
            up that and copy it"
  bkardell: Can you ask the constructors for the grammar?
  TabAtkins: Right now in CSS, if you want another property like box
             shadow, you use <'box-shadow'>
  TabAtkins: If a dev does that, and then we change box-shadow in
             the future, their code then breaks.
  TabAtkins: If you have a CSS box-shadow constructor and ask it for
             that, same problem.
  <fantasai> +1
  TabAtkins: Fine to copy from spec, cuz that's static.
  <leaverou> +1
  shane: At risk of calling down ire of Tantek...
  [tantek joins IRC as if summoned]

  RESOLVED: Use CSS grammar definition syntax for defining grammar
            of custom properties.

  shane: Break, then parser API. Official Houdini meeting is over.

  TabAtkins: Parser thing gonna give intro to WICG.
  <TabAtkins> SimonSapin: Parser API sketch
https://wicg.github.io/CSS-Parser-API/
Received on Monday, 10 October 2016 00:40:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 10 October 2016 00:40:24 UTC