- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 29 Aug 2012 19:21:38 -0700
- To: "www-style@w3.org" <www-style@w3.org>, "public-fx@w3.org" <public-fx@w3.org>
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:06 UTC