CSS-SVG Task Force Teleconference

05 Mar 2012


See also: IRC log


ed, Doug_Schepers, smfr, krit, Tav, cabanier, ChrisL, +1.415.832.aaaa, dino
krit, smfr


<trackbot> Date: 05 March 2012

<shepazu> scribenick: krit

css transforms open issues

<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?


<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

open CSS transforms issues

<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


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

linearRGB vs sRGB for filter effects


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

Summary of Action Items

[NEW] 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]
[NEW] 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]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/03/05 22:00:34 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]