[CSSWG] Minutes Seattle F2F Wed 2014-01-29 AM III / PM I: will-change, Blending & Compositing

will-change
-----------

   Discussed will-change proposal, interaction with performance and optimization,
   and effects on stacking context generation. Tab was tasked with taking the
   proposal to the Performance WG for feedback. Holding off on FPWD for feedback
   on general approach.

   RESOLVED: publish will-change in the CSS WG repo as an Unofficial Draft

Blending & Compositing CR
-------------------------

   RESOLVED: Compositing to CR, pending the edit nits brought up today.

====== Full minutes below ======

will-change Proposal
--------------------

   http://tabatkins.github.io/specs/css-will-change/
   TabAtkins: Benoit suggested a property that authors could use to say
              ahead of time what operations will be done later
   TabAtkins: e.g. properties can cause element to be promoted to a new
              layer, can cause lag
   TabAtkins goes through http://tabatkins.github.io/specs/css-will-change/#will-change
   TabAtkins: this is a hint to the UA and has no visible impact on the
              element itself
   TabAtkins: other than possibly creating a stacking context (e.g.
              will-change: opacity will create a SC)
   krit: that's why I would not call it a hint!

   florian: if things going to change are in markup, the UA could figure
            it out
   florian: if they will change via script, why isn't this an API?
   TabAtkins: can't always tell that something is going to happen (e.g.
              if they happen via :hover)
   TabAtkins: often it's that user is going to flip a class in JS
   florian: so you're doing from JS, why not do it programmatically

   heycam: if you have animations on transforms that haven't started yet,
           you don't want to create stacking context before the animation
           starts
   dbaron: the spec says you don't create a stacking context before the
           animation starts
   dbaron: the problem now is that people are using hacks, like setting
           transform: translateZ(0)
   krit: and they do the hacks because they know that it's creating a layer
   dbaron: but they do the hacks because they work in some engines
   dbaron: engines do different things e.g. between transform and opacity
   TabAtkins: the compositing layer is undetectable. you can tell the SC
   krit: use of this would cause SC in many cases, e.g. will-change: top
   TabAtkins: no, only properties that create SC cause one in will-change

   dbaron: we don't want to guarantee authors a compositing layer, because
           we may not have enough RAM
   dbaron: but we can guarantee a stacking context (SC)
   dbaron: it lets the author give us a hint that they care about the
           performance
   dbaron: so UAs can improve performance in some cases

   florian: why is it a bad idea to have a property that creates a stacking
            context (auto | force)
   TabAtkins: this creates a SC because you want consistent behavior over
              time
   TabAtkins: you're suggesting element.willChange()
   florian: and a separate property for creating stacking context
   TabAtkins: it's convenient for applying this declaratively
   florian: but you're JS to change the content anyway
   TabAtkins: not necessarily; can't use the fact that some property might
              be animated in the lifetime of the document
   TabAtkins: this is more closely scoped in time
   florian: on hover, the author has no more info than the UA does
   florian: let's introduce a property to tell the UA something it can't
            figure out on its own

   sylvaing: do you change anything when you see that you have a transition
             or animation
   sylvaing: so will-change: opacity will cause SC, transition: opacity will
             not
   TabAtkins: this could be done as a JS api, but more convenient as a
              property. i don't really care which way this ends up

   florian: we have rejected in the past things in the past that are
            convenience/hint properties
   TabAtkins: two questions: 1) can the UA autodetect this, and 2) should
              it be in DOM or CSS
   TabAtkins: 2 UAs think this is a reasonable perf optimization
   florian: introducing JS is the point where the UA can't figure it out
            any more

   florian: why have a property when the UA can figure it out on its own
   krit: implementations will change over time, and the perf characteristics
         change
   krit: this property can't address that
   krit: this property may not be necessary in future
   TabAtkins: compositing isn't the only reason to have a slow start to an
              animation
   TabAtkins: we will continue to have animations that are slow to start
   TabAtkins: this is only a hint

   plinss: we should divorce the SC from the hint
   plinss: so we have another property that forces creation of a stacking
           context
   dbaron: then using will-change without that other property is useless
   dbaron: the second property will make this too hard for authors to get
           right and they won't use it
   krit: we already have the isolation property that creates a SC
   plinss: there are a lot of implicit behaviors in CSS (e.g. containing
            block) that should be explicit properties
   TabAtkins: i agree with you
   TabAtkins: this is going to be cargo-culted anyway
   TabAtkins: so keeping it as simple as possible is good

   SteveZ: if you add an optional argument that says "no-stacking context"
   Rossen: have you discussed with the Performance WG?
   dbaron: I think the Performance WG is mostly concerned with network and
           measurement
   Rossen: not necessarily. Suggest you should talk to them.
   Rossen: they have dealt with this issue, and may have valuable feedback
   Rossen: it's not IE-only. other companies were quite engaged
   ACTION: TabAtkins to talk to the Performance WG about will-change
   <trackbot> Created ACTION-615

   TabAtkins: want to take feedback before asking for FPWD
   dbaron: would like this to be a group editor's draft
   TabAtkins: I do have a "dream" status I can use for this
   krit: we want to get it reviewed, so it should be a W3C space
   RESOLVED: publish will-change in the CSS WG repo as an Unofficial Draft

<br type="lunch">

Blending & Compositing CR
-------------------------
Scribe: TabAtkins

   <smfr> http://dev.w3.org/fxtf/compositing-1/
   cabanier: We changed the sections from 4 onward to be normative.
   cabanier: There was a 3-week period for comments.
   cabanier: There was a comment from Eric about a stale ref, which I removed.
   cabanier: I've prepared a DoC.
   cabanier: And we've been working on test cases.
   cabanier: People have been contributing quite a few tests.

   cabanier: Working on impl in 3 browsers.
   cabanier: Right now, FF is probably the most stable.
   heycam: Did you do all three?
   cabanier: No, separate engineers.
   cabanier: People have begun experimenting quite a bit with it.  We've
             done almost no evangelizing, but people get excited anyway.
   cabanier: Some person made a bunch of cool demos:
   <cabanier> codepen: http://codepen.io/collection/Kgshi/
   cabanier: [shows off some of the demos]
   cabanier: So right now I think we're ready for CR.

   TabAtkins: I've been meaning to suggest some editorial rewrites for some
              time, but that shouldn't block CR.

   smfr: You've got some theoretical sections - I'd like to see more examples
         showing which CSS properties I can use to get each of the effects
         you're talking about.
   smfr: Like section 10.
   krit: Canvas also uses this stuff.
   smfr: Right, but I'd still like to see a simple CSS example.
   ACTION cabanier to provide more CSS examples in the Compositing spec.
   <trackbot> Created ACTION-616

   heycam: What were the LC issues?
   cabanier: Just one from Erik, about a stale ref.
   ChrisL: You still have a link to SVG Tiny in your abstract.  It should
           be changed to SVG 1.1.
   Action krit to change the Abstract link to SVG 1.1 in Compositing.
   <trackbot> Created ACTION-617
   <ed> it should also use the referencing syntax in the abstract, like
         "...sometext... [SVG11]"

   heycam: The other changes in your DoC, what are they?
   cabanier: They were from the previous LC.
   ChrisL: You'd usually start a new DoC. Helps with patent issues.
   ACTION krit to action rik to reduce the DoC to only the issues from this LC.
   <trackbot> Created ACTION-618
   ChrisL: [something about the wording of the abstract regarding the
            2dcontext reference]
   <ChrisL> its ambiguous on which spec is the normative definition

   plinss: How are we on tests?
   cabanier: [brings up the repo with tests]
   <cabanier> tests: https://github.com/w3c/csswg-test/tree/master/contributors/adobe/submitted/css-compositing
   RESOLVED: Compositing to CR, pending the edit nits brought up today.

Received on Thursday, 20 February 2014 00:19:48 UTC