[CSSWG] Minutes and Resolutions 2012-08-15 Wed PM I: Filters, Transforms, Masking

Filters
-------

   - RESOLVED: Publish Filters FPWD
   - RESOLVED: Dirk Schulze (krit) as editor on Filter effects

Transforms
----------

   - Discussed interpolation of rotate3d()
   - RESOLVED: Publish WD of Transforms after rotate3d() animation is resolved

Masking
-------

   krit introduced the FXTF Masking proposal to the CSSWG
     http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html

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

Filters
-------
Scribe: fantasai

   <krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
   Vincent: FPWD request for filters
   * fantasai can't hear
   krit: Spec is a combination of predefined filter effects, SVG filter
         effects, and CSS shaders
   krit: Are there any questions?
   alan: SVGWG already agreed to publish
   fantasai: Last time CSSWG discussed this, we concluded we wanted several
             "targets" of things to filter
   fantasai: One was the background, another was background + border as a
             single unit, another was borders only, another was content
             only, another was entire element as a whole
   fantasai: Can I apply e.g. an opacity filter, or a blur filter, to any
             one of these things listed above?
   fantasai: If not, I think that's an issue
   hober: ok with just marking that as an issue
   fantasai: sure
   <cabanier> fantasai: are you thinking of blending and compositing?
   <cabanier> fantasai: It's in there. I haven't heard of doing this for
              filters too (but it makes sense)
   fantasai: no idea what the technical term, only that we want to be able
             to apply filters to each part
   fantasai: We've had requests for background-filter, border-filter,
             etc-filter (replace filter with opacity, or shadow, or whatever)
   fantasai: We decided we should do this generically with filters, rather
             than adding a new property for each
   fantasai: So this module needs to be accommodating those requests somehow
   ACTION krit: mark this as an issue
   <trackbot> Created ACTION-505

   alan: Anything else?
   * fantasai is a little confused why everything's prefixed with FE but
              supposes that's inherited from SVG?
   RESOLVED: Publish Filters FPWD

   Alan: Propos krit as editor on Filter effects
   RESOLVED: krit as editor on Filter effects


Transforms
----------

   <krit> http://dev.w3.org/csswg/css3-transforms/#animation
   krit: Talked about interpolation, and request for some tests
   krit: All browsers do ?
   krit: All browsers do matrix decomposing
   krit: ...
   <krit> http://wiki.csswg.org/topics/interpolation-rotate3d
   krit: Let me post a link
   krit: What I tested was browsers interpolation on rotate3d
   krit: Actually looks like all browsers do magic decomposing (matrix
         decomposing)
   ????
   * fantasai gives up trying to minute, can't hear what's being said
   krit: Suggest that when rotate3d() is involved we always to matrix
         decomposing
   <krit> for rotate3d we always decompose with matrix
   <krit> thats is what all browsers do with the exception of chrome
   <krit> chrome does number interpolation if the roatate is arround 0,0,1
   <krit> 0,10
   <krit> or 1,00
   <krit> I can change the behavior of Chrome in  WebKit to match all
          other browsers
   fantasai: Is matrix decomposition satisfactory for what users would
             want to do?
   <krit> I would expect that users want number interpolation
   <krit> but that is not what browsers seem to do
   dbaron: Not that great
   <krit> It seems unlikely that IE10 can change the behavior
   <krit> it is already ready for shipping
   sylvaing: current behavior is used in our app frameworks - could be
             tricky to change
   <silence>
   hober: i'm happy with krit's proposal on this issue
   <sylvaing> it will be harder if we depend on the unprefixed version
              of the feature; also depends on other live content that
              may use this.
   fantasai: So do we really want to lock that in? or just consider it a bug ?
   <krit> A bug in browsers or implementation?
   sylvaing: It's hard for us because we use this in our app frameworks.
   fantasai: Usually the problem is switching behavior from a numeric
             interpolation case to a matrix decomposition one
   fantasai: Other way around I understood from last time was not so much
             of a problem
   TabAtkins: In first case, where everything's the same, would expect angle.
   TabAtkins: But where vectors are different, would be weird.
   TabAtkins: Even if we do numeric interpolation, interpolating the 3 args
              numerically is probably not what authors want.
   dbaron: I think we want numeric interpolation when the 3 components are
           the same
   TabAtkins: That would be minimally good
   TabAtkins: That would at least allow rotation along an axis that is not
              x/y/z
   dbaron: If authors want something more complicated to animate, then they
           have to explicitly split it up the way they want

   <krit> I am unsure if Safari can implement numerical interpolation for
          rotate3d in general
   fantasai: Seems better than matrix decomp
   TabAtkins: So question is, do we normalize the vector before comparison?
   Vincent: Don't think that'll work
   krit: Spec wants the vectors to be normalized
   krit: Safari doesn't, sticks on CoreAnimation
   krit: Can't do numeric interpolation
   sylvaing: That's their problem.
   krit: This will mean that you'll have different behavior on Safari than
         other browsers
   TabAtkins: Not strictly true. Safari just has to do some additional
              bookkeeping
   dbaron suggests doing this on a telecon

   Proposal A: rotate3d() always uses matrix decomposition
   Proposal B: rotate3d() uses numeric interpolation when the first 3 arguments
               (defining the axis) match
   Proposal C: roate3d() uses numeric interpolation when the first 3 arguments
               (defining the axis) match *after normalizing the vector*
   A is implemented right now, but what authors will want
   is B or C because otherwise can't rotate along axes other than xyz
   krit: There is no B, spec says they are normalized
   TabAtkins: At what stage? Does it say computed values are normalized?
   TabAtkins: If not, we can say that
   <dbaron> The spec says it's normalized, but doesn't say when, so it's
            basically meaningless.
   plinss: Only place that user would notice is when rotate takes you back
           where you came from?
   dbaron: No, lots of cases
   dbaron: If you decompose a 90deg rotation into 2 components, won't do
           exactly the same thing
   dbaron: The bigger the angular difference, the more noticeable it is
   dbaron: Past 180deg, will notice greatly because might get different
           direction of rotation
   dbaron: or different number of rotations.
   krit: Animating from negative vector to positive vector?
   dbaron: Just count as a mismatched vector.

   fantasai: So we're down to A or C.
   fantasai: I think we should go with C, since that's what authors will want.
   hober: Go with A, that's what's implemented
   TabAtkins: This isn't a compat issue, so we don't need to do bugwards compat
   plinss: My concern is that sometimes you get matrix decomposition behavior,
           and some cases you don't. Will authors be surprised about that?
   hober, TabAtkins: it's predictable
   TabAtkins: If the vector is the same, we interpolate otherwise not
   Vincent: We have two vectors, right, we could ... even if they don't match
   Vincent: Could do better behavior than decomposing
   plinss: That would be less surprising to the author, I think
   TabAtkins: So that would be option D, fully define interpolation
   dbaron: There are a bunch of places where you'll have to make a lot of
           arbitrary decisions
   dbaron: special behavior for antiparallel vectors?  If so, use that
           behavior for any >90deg angle?  What about 90deg angles?
   hober: Would be nice if Simon were here for this
   plinss: Anyone want to take an action to try to define D
   ACTION Vincent: Write a proposal for vector interpolation for rotate3d()
   <trackbot> Created ACTION-506

   plinss: anything else?
   krit: Can we publish after decision about rotate3d()?
   plinss: How far are we from LC?
   krit: Some minor issues, would also like to publish WD and ask for
         review before going to LC
   plinss: Asking if this is last WD before LC
   RESOLVED: Publish WD of Transforms after rotate3d() animation is resolved
   * Bert noticed that editor's draft has a rotate3d() with only 3 args
          in section 18. Typo?

   <dbaron> The other issue, by the way, is whether "falling back to matrix
            interpolation" means for the function or for the entire list.
   <dbaron> I think it should be just for the function.

Masking
-------

   <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
   krit: CSSWG decided to apply masking to HTML content, SVG WG wants to
         work together with CSSWG
   krit: So we made FXTF draft for masking
   krit: It's a proposal that just specifies ... for browsers
   krit: We have Firefox that .. and we have Webkit that does something
         with masking
   krit: Specification which tries to address both proposals

   krit: Two different sets of properties
   krit: One is mask-image, similar to bg image
   krit: idea is that authors don't need to learn new syntax for it
   krit: syntax is exactly the same
   krit: behavior is same, just with masking
   krit: masking process ... filter
   krit: There's also 2nd set of properties mask-box-image
   krit: similar to border-image
   <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#mask-box-image
   krit: Does CSSWG want to go with this approach?
   krit: any concerns about this?

   fantasai: Are there use cases for all these properties?
   krit: They are quite useful, easier/ more powerful than SVG masking
   krit: So think it's very useful
   krit: ...
   krit: mask-box-image, used quite a lot
   krit: still a feature that's heavily used on mobile devices today
   fantasai: My opinion is basically if roc thinks it's a good idea, it's good
   hober: harmonizing webkit-mask with SVG is a no-brainer, should continue
          to work on it
   dbaron: Would like a chance for other to people look at it
   krit: roc said same thing as you, fantasai
   Vincent: Goal was to see if group thinks its a good idea to work on this
   fantasai: Think it's good to work on this, think that idea of aligning
             with existing properties seems smart,
   fantasai: Think that in cases where the values match an existing property,
             should refer to the definitions in the existing property rather
             than repeating it
   fantasai: e.g. position should refer to definition of <position> in
             css3-background rather than duplicating it

   dbaron: I'm a little unsure how high priority this should be
   dbaron: There's been some stuff in webkit for awhile
   dbaron: we've had a huge a mount of pressure for transforms, transitions,
           and animations, but not so much for masking
   dbaron: That makes me think that there are a bunch of other things this
           group works on that are probably higher priority than this
   krit: I can't disagree with that of course
   krit: We want to address this in SVGWG, so don't see how it can harm the
         CSSWG
   hober: In the context of is it a priority, I've certainly had on my to-do
          item to spec -webkit-mask, so thankful to dirk for taking this on
   Bert: I have two questions
   Bert: Since 'clip' has never been used, why would 'mask' be used more?
   Bert: Second, isn't this a kind of filter?
   TabAtkins: We have lots of examples of -webkit-mask being used on the Web
   krit: Used a lot for images and videos
   krit: clip-mask can also be used similar to shapes in CSS exclusions
   krit: I'm fine to specify if CSSWG wants
   fantasai: Speccing something that replaces -webkit-mask with a standard
             feature seems like a good idea
   hober: And doing it in a way that harmonizing with SVG is good
   krit: Been in Webkit for 4 years

   Leif: Not handled by other spec?
   TabAtkins: Theoretically could be a filter, but like box-shadow, something
              that seems to benefit from having its own property. Also SVG
              has its own masking already anyway
   Mask the filters? :)
   <dbaron> krit, also http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
            should say who the Editors are
   krit: In SVG, masking, then filters, then clipping is separate step
   jdaggett: Should we move on?
   Topic deferred, giving dbaron &co to ask others for feedback

Received on Thursday, 30 August 2012 02:22:07 UTC