W3C

- DRAFT -

CSS-SVG Task Force Teleconference

04 Apr 2011

Agenda

See also: IRC log

Attendees

Present
smfr, +1.206.675.aaaa, Doug_Schepers, ed, +1.650.253.aabb, TabAtkins, ChrisL, anthony, hober
Regrets
Chair
erik
Scribe
shepazu

Contents


<trackbot> Date: 04 April 2011

<scribe> scribeNick: shepazu

CSS Animation synchronization

<ed> http://lists.w3.org/Archives/Public/public-fx/2011JanMar/0168.html

ed: long thread, wondered what the status of the animation work is?

smfr: Dean promised to publish a draft this week
... has an API for WebKit

ed: does it do sync?

smfr: I don't think so
... it's hard to do smooth frame synchronization starting one animation at the end of another
... hard to get seamless joins based on 'animationEnd' event

ChrisL: so, you want a negative offset?

smfr: I think it's better to use JS APIs, per Dean's spec

cabanier: on mobile devices, JS overhead becomes tens of seconds

TabAtkins: that's based on the traditional approach, not Dean's approach

smfr: you would set it up using keyframes or such, not execute it directly (?)

cabanier: on iPad, we have to skip frames on animations, how would you set this up?

TabAtkins: [missed]

cabanier: ok, I'll have to see it working

TabAtkins: it's simple at the moment, but has clear directions for expansion

ed: does this solve Paul's concerns?

cabanier: paul was asking about pausing and rewinding animations, or replacing them midway through
... we were more concerned about synchronization in a simple manner
... without setting it up in advance or keying off an animation event handler

ed: ok, we will wait for Dean's spec before going further

SVG/CSS 2d transforms - 'transform-origin'

<ed> http://lists.w3.org/Archives/Public/public-fx/2011JanMar/0158.html

anthony: been discussion on the list about how the transform attribute is going to be used in relation to CSS
... I thought we were going for an override, but the list discussion doesn't seem to agree
... ROC put up some options... I don't have personal preferences, I am just curious what others think we should do?

<ed> http://dev.w3.org/Graphics-FX/modules/2D-transforms/spec/2DTransforms.html

anthony: the most pertinent point for this discussion is point 1: "Elements with SVG transform attributes must default to top-left as their

transform origin, but CSS transforms default to the center."

anthony: not sure the spec reflects the group decision at this point

ed: I think it does reflect this first point
... for backwards compatibility

<smfr> http://dev.w3.org/Graphics-FX/modules/2D-transforms/spec/2DTransforms.html#transform-origin

ed: 'transform-origin' property has an initial value of center (50%,50%) for CSS, and origin (0,0) for SVG

<ed> initial value is auto

<ed> but it maps to those

anthony: seems like people are leaning toward roc's option 1a: "1a) Introduce a UA style rule that sets transform-origin to "top left" for all SVG elements."
... would this apply before or after the transform is applied?

smfr: SVG or CSS transform?

anthony: I thought we were doing a 1-1 mapping?

smfr: not sure how they interact

shepazu: do CSS transforms override or supplement SVG transforms?

ChrisL: depends on if @transform is promoted to a CSS property

<ChrisL> if its promoted toa property then a style rule overrides. if not,then they could be defined to combine. Depends what we want

ed: I did an experimental implementation that did a post-multiply, and it seemed easy enough to use, but felt a bit strange not to have @transform as a presentation attribute

<ChrisL> Not promoting transform to a property minimises the backwards compatibility issues and means the dom still works as it did before

ed: didn't experiment much, but that was the easiest way

anthony: what about animation?

shepazu: still works for animating with CSS animations

ChrisL: I think the simpler path is not promoting @transform to a property, and just define how they combine

shepazu: I tend to agree, though ed's point is taken

ed: yeah, that solves the DOM issues as well

shepazu: my only concern would be for SVG UAs that don't support CSS, but I think those are dwindling

anthony: would CSS transforms still apply to SVG

ChrisL: yes, they would be separate sources of transformation, and you would simply post-multiply them

Resolution: pending further discussion with other stakeholders, we will not define @transform as a presentation attribute

<scribe> ACTION: anthony to reply to Roc's email with our suggested resolution [recorded in http://www.w3.org/2011/04/04-fx-minutes.html#action01]

<trackbot> Created ACTION-28 - Reply to Roc's email with our suggested resolution [on Anthony Grasso - due 2011-04-11].

Filter Effects status update

<ed> http://www.w3.org/mid/4A2DB3AE4504E944AF122BBFBA7FBA1F582D2DC1@TK5EX14MBXC114.redmond.corp.microsoft.com

ChrisL: my impression is that CSS people want it to be very simple, and that adding borders, backgrounds, etc complicates it, so a better would be to add new 'in's to the SVG filter primitives
... simon had a counterproposal with separate names, but that raised the question of how they combined

ed: I think I'm in favor of having additional filter input image keywords, and we could define them for the SVG case

ChrisL: for instance, for things that don't use the CSS box model, you would just use transparent black for the border image (for example)

ed: we already have 'backgroundImage', but could do it differently for HTML

<scribe> ACTION: ed to add filter input image keywords for CSS and HTML [recorded in http://www.w3.org/2011/04/04-fx-minutes.html#action02]

<trackbot> Created ACTION-29 - Add filter input image keywords for CSS and HTML [on Erik Dahlström - due 2011-04-11].

ed: would like to have a list... background of element, border, content box...

ChrisL: padding is always transparent...
... so, that's a good list
... start with simple ones, like solid and dotted border, and give it a dropshadow
... then experiment with 9-box, apply effects... string of pearls, celtic knot...
... take the alpha channel of the border image to produce a dropshadow, I think that would be compelling

ed: I'll also try to combine SVG Compositing to filters.... haven't looked at it yet...

<scribe> ACTION: ed to add normative reference to SVG Compositing in Filters, and merge them where it applies [recorded in http://www.w3.org/2011/04/04-fx-minutes.html#action03]

<trackbot> Created ACTION-30 - Add normative reference to SVG Compositing in Filters, and merge them where it applies [on Erik Dahlström - due 2011-04-11].

trackbot: end telcon

Summary of Action Items

[NEW] ACTION: anthony to reply to Roc's email with our suggested resolution [recorded in http://www.w3.org/2011/04/04-fx-minutes.html#action01]
[NEW] ACTION: ed to add filter input image keywords for CSS and HTML [recorded in http://www.w3.org/2011/04/04-fx-minutes.html#action02]
[NEW] ACTION: ed to add normative reference to SVG Compositing in Filters, and merge them where it applies [recorded in http://www.w3.org/2011/04/04-fx-minutes.html#action03]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2011/04/04 21:03:48 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/to have @transform as a property/to have @transform as a presentation attribute/
Succeeded: s/having different inputs,/having additional filter input image keywords,/
Found ScribeNick: shepazu
Inferring Scribes: shepazu
Default Present: smfr, +1.206.675.aaaa, Doug_Schepers, ed, +1.650.253.aabb, TabAtkins, ChrisL, anthony, hober
Present: smfr +1.206.675.aaaa Doug_Schepers ed +1.650.253.aabb TabAtkins ChrisL anthony hober
Agenda: http://lists.w3.org/Archives/Public/public-fx/2011JanMar/0170.html
Found Date: 04 Apr 2011
Guessing minutes URL: http://www.w3.org/2011/04/04-fx-minutes.html
People with action items: anthony ed

[End of scribe.perl diagnostic output]