See also: IRC log
<trackbot> Date: 04 April 2011
<scribe> scribeNick: shepazu
<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
<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].
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
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]