See also: IRC log
<trackbot> Date: 05 March 2012
<shepazu> scribenick: krit
<ed> https://www.w3.org/Bugs/Public/buglist.cgi?product=CSS&component=Transforms&resolution
<smfr> https://www.w3.org/Bugs/Public/buglist.cgi?product=CSS&component=Transforms&resolution=---
<ChrisL> if we resolve it, i can take the action to publish it, likely on thursday
<smfr> scribenick: smfr
krit: question is what we do with the test suite
particularly with SVG
<krit> smfr: are you scribing now?
yes
<krit> smfr: thanks. I'll do it next time
ChrisL: SVG is using the CSS model now, so the tests will just get picked up
tests will get put in separate directories to people can just run some of them, but all the tests will get picked up
krit: should we have SVG-only tests?
ChrisL: CSS says they have to be XHTML1, and it generates XHTML1, HMTL4 and HTML print
not sure if we can submit HTML5 tests now
don't know how HTML5 has been integrated in (generated, or as the submission format)
ChrisL: we can have both svg-only and not
krit: does CSS transforms say anything about what kinds of tests we need
ChrisL: we need to tests HTML with CSS transforms applied, and SVG with CSS transforms applied
others would be good too
Tav: we talked about testing at the last SVG meeting
will be awhile before we get our new system set up
ChrisL: at last meeting resolved to change how SVG tests are structured, so they have an <html> <head>; easier for Shepherd system
krit: does the WG want SVG-only tests as well?
ChrisL: yes, there's value in that e.g. for testing SVG inside CSS-transformed HTML
krit: what would SVG-only tests look like?
ChrisL: it's pretty easy
... we can compare with SVG tests using attributes, for ref
testing
<ChrisL> see here http://www.w3.org/Graphics/SVG/WG/wiki/SVG2/Testing_Requirements
smfr: Dirk is asking about the format for an SVG-only test
Tav: if this is OK I can go ahead and start making some tests
<ChrisL> https://www.w3.org/Bugs/Public/buglist.cgi?product=CSS&component=Transforms&resolution
https://www.w3.org/Bugs/Public/buglist.cgi?product=CSS&component=Transforms&resolution=--- (note the ---)
krit: issue with SVG transforms and computed style
across HTML and SVG
<krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15431
issues with getComputedStyle and transform, transform origin etc
smfr: we decided that for transform we'd return a list of functions
krit: what about transform-origin etc?
smfr: for most (e.g. backface-visibility) it's easy
transform-origin depends on the resolution of the issue to match background-position
we'll get on the CSS agenda for this week
krit: issue with animations of translateX() vs. translate()
<ed> link?
<krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14715
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15758
ah, not mine
dino: you can go from translateX to translateY just fine
krit: what is the computed style during such an animation?
dino: it could be translate(x, y)
krit: if the functions don't match, computed style would be magic (matrix)
dino: what's best for developers? it's best if we can match functions
krit: computed style would have to be not just translateX and translateY
dino: if we can avoid falling back to matrix more often, it's better for authors
krit: same for skewX, skewY, scaleX, scaleY
dino: rotate is hard
rotateX -> rotate3d(….)
dino: just handle the common ones
<ChrisL> there was a complaint about dropping skew ...
dino: this is different from what
webkit implements
... yes
krit: also other browsers
... in SVG you match the transform functions exactly
... can we say that translateX, translateY and translate(x, y)
are different types
smfr: conflict between what browsers implement and what's best for authors
ed: what content would break?
dino: that would be content that is relying on weird behavior
schepers: would the content be using prefixes anyway?
dino: yes
schepers: is webkit willing to change
dino: yes
<dino> to clarify, the content that would change with these improved rules would be transform lists that mix scale and rotation. An animation from just translateX to just translateY would be identical with the fallback interpolation via matrix.
smfr: spec should have "canonical" transform functions, like translate3d() and describe translateX as a shorthand
<dino> dirk: what about translateX translateX translateX -> translateX
<dino> smfr: I don't think we should support lists with different lengths
<ed> translateZ -> translateY animations also fine?
krit: we should match one by one
<scribe> ACTION: dino to look at current rules and make a proposal for transform animations [recorded in http://www.w3.org/2012/03/05-fx-minutes.html#action01]
<trackbot> Created ACTION-72 - Look at current rules and make a proposal for transform animations [on Dean Jackson - due 2012-03-12].
schepers: are we going to publish a new WG?
ed: not enough CSSWG people here. we can resolve for SVG here
RESOLUTION: SVG working group agrees to publish a new version of the CSS transforms spec with recent edits
http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0078.html
ChrisL: it's not about color interpolation, it's how you'd specify that for a filter shorthand
Zakim: shut up
ChrisL: it's well defined what the default is
Tav: no it's not
ChrisL: assumed that it should match SVG
Tav: WebKit implements sRGB
we need a way to change the default
<ed> could we reuse the color-interpolation-filters property?
ChrisL: you said you wanted opacity to not be in linear space(?)
Tav: want consistency; what should be the default
ChrisL: either we have the default be linear the same as longhand filters, or we have a keyword to allow authors to have control
Tav: the Adobe apps do it the wrong way, and Flash player
<dino> I thought that was Rik?
<ChrisL> not all of them do in fact
smfr: WebKit hasn't picked a way; it hasn't really be looked at carefully
dino: what's the right thing to
do here?
... CSS doesn't specify what the colors are in
ChrisL: the colors are specified
to be sRGB
... but which case do you do math in for filters?
... linear interpolation in filters needs to happen in a linear
colorspace
Rik: but you can use another colorspace
ChrisL: but that isn't necessarily correct. Linear is correct
dino: for every filter op, you'd convert sRGB into linear, run the filters, then convert back, then composite
ChrisL: correct
... longhand filters spec says it's linear, and shorthand
filters should match
dino: do you only have to worry about the colorspace going into and coming out of the filter?
<dino> we don't necessarily need to scribe my education of color spaces :)
<more education of dino>
<krit> :D
dino: what about a no-op filter like an feMerge?
ChrisL: it would look different
colorspace would affect the darkness of the antialiasing between the colors
dino: now, with no-op shorthands, e.g. grayscale(0)
ChrisL: that would not change
<discussion of various examples>
Rik: simple linear blending is not liberalized. there's an inconsistency in the spec
<discussion of adobe tools behavior>
Rik: real question is what the shorthands should o
ChrisL: they should do it the
proper way (linear), and we should give them a keyword if
authors want other behaivor
... would need a new keyword on the shorthand filter
... what we really want is a single value for the whole
filter
smfr: or maybe another CSS property
<ed> http://www.w3.org/TR/SVG11/painting.html#ColorInterpolationFiltersProperty
smfr: is this different from SVG's color-interpolation property?
ChrisL: no
so this is just color-interpolation-filters
ed: we have this in the filters
spec
... or maybe not
ChrisL: so that property needs to be in the filters spec
<scribe> ACTION: ed add color-interpolation-filters property to the filters spec, say that it applies to shorthand filters in HTML [recorded in http://www.w3.org/2012/03/05-fx-minutes.html#action02]
<trackbot> Created ACTION-73 - Add color-interpolation-filters property to the filters spec, say that it applies to shorthand filters in HTML [on Erik Dahlström - due 2012-03-12].
ed: are we happy with the defaults?
ChrisL: yes
Rik: ok as long as there's a way to turn it off
ed: good to start with what we have for SVG
? problem with clamping for the compositing spec
talk about next time
ed: you'll take care of the minutes?
i have to run
<ed> trackbot, end telcon
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/test/tests/ Succeeded: s/exactliy/exactly/ Succeeded: s/ enough people / enough CSSWG people / Succeeded: s/CSS doesn't what/CSS doesn't specify what/ Succeeded: s/cahnge/change/ Succeeded: s/Tav/Rik/ Found ScribeNick: krit WARNING: No scribe lines found matching ScribeNick pattern: <krit> ... Found ScribeNick: smfr Inferring Scribes: krit, smfr Scribes: krit, smfr ScribeNicks: krit, smfr Default Present: ed, Doug_Schepers, smfr, krit, Tav, cabanier, ChrisL, +1.415.832.aaaa, dino Present: ed Doug_Schepers smfr krit Tav cabanier ChrisL +1.415.832.aaaa dino Agenda: http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0146.html Found Date: 05 Mar 2012 Guessing minutes URL: http://www.w3.org/2012/03/05-fx-minutes.html People with action items: add color-interpolation-filters dino ed property WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]