Minutes, FX telcon 11 March 2010

Hello public-fx,

Minutes are here

and below as text for bots

                   CSS-SVG Task Force Teleconference

11 Mar 2010


      [2] http://lists.w3.org/Archives/Public/www-svg/2010Mar/0007.html

   See also: [3]IRC log

      [3] http://www.w3.org/2010/03/11-fx-irc


          ed, Doug_Schepers, ChrisL, anthony, +1.858.655.aaaa, plinss_,
          +1.408.454.aabb, dino, smfr, fantasai




     * [4]Topics
         1. [5]Charter and so on
         2. [6]CSS 2d Transforms and SVG Transforms differences
     * [7]Summary of Action Items

   <trackbot> Date: 11 March 2010

   <ChrisL> trackbot, start telcon

   <trackbot> Meeting: CSS-SVG Task Force Teleconference

   <trackbot> Date: 11 March 2010

   <ChrisL> zakim - code?

   <shepazu> code is FXTF

   <ChrisL> hi dino

   <dino> hmm

   <shepazu> dino!

   <dino> duh - wrong number me!

   <anne> fwiw, regarding the suggestion about having some kind of auto

   <anne> I don't think that is needed at all

   <anne> see [8]http://krijnhoetmer.nl/irc-logs/css/20100311#l-61

      [8] http://krijnhoetmer.nl/irc-logs/css/20100311#l-61

   <shepazu> anne, will you join the call?

   <shepazu> [9]http://www.w3.org/Graphics/fx/charter/

      [9] http://www.w3.org/Graphics/fx/charter/

   <anne> shepazu, no sorry, don't really know much about transforms

   <shepazu> [10]http://www.w3.org/Graphics/fx/track/

     [10] http://www.w3.org/Graphics/fx/track/

   <anne> also, I should really fetch some dinner

   <ChrisL> Scribe: Chris

   <ChrisL> ScribeNick: ChrisL

Charter and so on

   Erik: Any change requests for the charter?

   Doug: Clarify what font/textwrap means

   Chris: Optical alignment
   ... no longer there, corrected to "Wrapping text to a shape"

   Doug: Need to update the participant list

   Erik: UTF-8 issues, d'oh!

   Simon: Dean is my hero

   <shepazu> [11]http://www.w3.org/Graphics/fx/track/

     [11] http://www.w3.org/Graphics/fx/track/

   Doug: Other issue is whether we have a lot of small specs or a
   smaller number that cover both SVG and CSS
   ... most seem in favour of specs that cover both

   Erik: fine by me

   Simon: Would joint deliverables approve all publications?

   Doug: Yes

   Simon: concerned over publication delays
   ... would this replace or be in addition to the CSS transforms spec?

   Doug: Replace

   Simon: Agree in principle

   Chris: Harmonisation takes longer than agreeing on joint publication

   Doug: Reasonable concern but manageable, deal with it if it arises
   ... we like putting trasform-x, transform-y on their own attrs.
   Don't recall any blocking iissues in the spec
   ... want to make sure it applies equally to CSS/HTML and SVG

   Simon: OK sounds good, enough representation from both groups

   Dino: Point is to take it out of scope of one group?

   Chris: no, TF work has to be in scope for all WGs that contribute

   Dino: So issue is really just about status, naming and so on

   Erik: So keep it in CSS cvs space?

   Dino: Don't care where it lives

   Doug: Maybe easier to re-use, or to make a new one. WebApps reuses a
   repository from 2 groups, not a problem in practice as longas its

   Anthony: Don't care as long as its consistent.
   ... prefer all TF docs in one place

   <scribe> ACTION: Doug to create an FX repository [recorded in

   <trackbot> Created ACTION-1 - Create an FX repository [on Doug
   Schepers - due 2010-03-18].

   Resolved: We will have one FX TF repository

   Doug: Editors - Dino and Anthony?

   Anthony: Love to

   Dino: Yippeee
   ... Current spec has multiple editors, Simon isn't but should be,
   Hyatt is but should not, DBaron is an active editor too

   Doug: Suggest folding in all editors

   Dino; Actually not sure on Dbaron, in terms of editong, but he is
   certainly implementing

   Resolved: Editors for Transforms will be Dino, Simon, Anthony, and
   DBaron welcome too if he edits

CSS 2d Transforms and SVG Transforms differences

   Erik: sent an email about how to implement CSS transforms in SVG


     [13] http://lists.w3.org/Archives/Public/www-svg/2010Mar/0013.html

   <ed> annevk had some comments on the auto-suggestion,

     [14] http://krijnhoetmer.nl/irc-logs/css/20100311#l-61

   Erik: need to maintain backwards compat, and properties et in style
   sheets have higher specificity than any value set in a attribute
   ... Most comments seem to agree with the option 1 in my mail

   Dino: Trying to understand what point Anne makes, the initial value
   should use the attribute
   ... doesn't quite work because transitions or animations that go
   through 'none' should go to the null transform

   Chris; So we need separate values for identity transform and "use
   the attribute"

   Dino: Yes

   Simon: Exactly. Any transform creates a CSS stacking context and a
   positioning container

   Doug: Also times when ther e is a transform that you want to blow
   away using CSS so we need that capability

   Dino: Keyword "identity"?
   ... especially for animations, using lists. Transforms in a list
   animated separately, to avoid flattening rotations > 360 degrees.
   Should add an identity keyword. Still need an auto as an initial
   value, like none in CSS and does nothing in SVG
   ... identity is still a transform

   Anthony; Can none be replaced by identity there

   Dino: yes

   Chris: So identity would deal with the 'blow off transform' case?

   Dino: Yes
   ... Rotate 720 when flattened gives rotate 0 so no movement instead
   of spinning twice

   Anthony: Makes sense. Carry across to SVG as well

   Dino: SVG does not cover this and it should
   ... CSS3 units spec requires normalisation to 0..360 and that has to
   be removed


     [15] http://www.w3.org/TR/2009/WD-css3-2d-transforms-20090320/#animation

   Chris: Normalisation came from spatialised audio (where it made
   sense) but fpr geometric transformation, especially when animated,
   notrmalisation should be avoided

   Simon: CSS transitions applying to SVG, intent to have these work
   also on transforms in SVG?

   Doug: Authors would expect that

   Simon: aaargh (scribe missed complication)

   Dino: Style sheet trumps attribute, transform as a property also
   trumps it. But SMIL trumps the attributes

   <smfr> css transitions/animations are animating css transforms in
   svg, while at the same time svg animations may be animating the
   transform attributes

   Erik: Use end events for transitions. Complex when they are both
   animating the same property

   Chris: Animation sandwich should define that

   Dino: Yes but if there is an animation, to or by so going from
   current value, and a transition fires ....

   Chris: Current means current animated value. need to say whether a
   transition is an animation in that sense

   Doug: Jack Jansen interested to simplify SMIL animation to better
   fit CSS

   Dino: Suggest we leave that for now as its more about trnsitions
   than transforms
   ... Transitions work really well with style changes, so making
   transforms as style helps there

   Simon: Specifying behavior is tricky to work between smil animation
   and css animation. One solution is to map all css transforms down to
   transforms in attributes for example. So its all mapped to one value

   Anthony: Agree this needs to be considered, for implementors and
   authors, ease of authoring and also performance

   <fantasai> RRSAgent: pointer

   Simon: Way we treat historical html attrs like bold etc


     [16] http://dev.w3.org/SVG/profiles/1.1F2/publish/styling.html#UsingPresentationAttributes

   For user agents that support CSS, the presentation attributes must
   be translated to corresponding CSS style rules according to rules
   described in Precedence of non-CSS presentational hints ([CSS2],
   section 6.4.4), with the additional clarification that the
   presentation attributes are conceptually inserted into a new author
   style sheet which is the first in the author style sheet collection.
   The presentation attributes thus will participate in the CSS2
   cascade as

   <fantasai> um

   <fantasai> that got cut off

   <fantasai> also

   Erik: So we would need to move the SVG transform attribute to the
   CSS transform property. Mostly this works but in some cases not

   <fantasai> the rule *is* that the attributes are inserted into a new
   author style sheet that is the first in the author style sheet

   Erik: ref transform in SVG 1.2 is an example'Simon: right

   <fantasai> and that they have zero specificity

   <fantasai> so that all subsequent rules override the attributes

   <fantasai> that doesn't require any "additional" clarification, it's
   in the spec

   Simon: So that aligns with Erik's option 1 in his email

   Erik: yes

   <fantasai> SVG just needs to say that its attribues are handled as
   non-CSS presentational hints like <font face>

   <fantasai> also, wrt 360 normalization, I think we already decided
   to fix that. You just need to pester howcome about editing it into
   the draft

   <fantasai> or get someone else to edit it

   <shepazu> fantasai, can you join the call?

   <fantasai> passcode?

   <smfr> FXTF (3983)

   ok so 858 is Peter and 408 is Anthony. Moving on .....

   Doug: (explains recap on hints)

   Chris (explains re legacy, hints, 1:1 mapping)

   Elika: CSS 2.1 or CSS3 cascading can be tweaked if needed. no
   aditional clarification in SVG is needed

   <fantasai> "For other languages, all document language-based styling
   should be handled in the user agent style sheet. "

   Elika: which is wrong
   ... That spec should be made more SVG freindly

   Chris: I agree and think the wording in SVG is a condensation of my
   various explanations of how CSS works

   Erik: So we agree on mapping SVG transform attr into the
   corresponding CSS property. So we need an explicit mapping -
   ... rotate function with three params in svg, one in CSS because of
   transform-origin property

   Dino: Or we could add rotate with three params. Try to avoid
   argument overloading

   Anthony: By default rotates happen around centre of object, so does
   two extra values give you an offset?

   Dino: Form the current transform origin

   Chris (problems with current point in PostScript)

   Simon: transform is a pre-shift and a post shift

   Dino: Easty to add it
   ... temporary translate

   Erik: Commas, units (not allowed in SVG). Are units mandatory?

   Dino: Yes, except scale obviously. But yes for lengths and angles
   ... degrees default for angles
   ... So want to not require commas?

   Erik: Yes, not an issue really

   Simon: Happy to drop requirement for commas in CSS

   Dino: Skew?
   ... We hate skew!


     [17] http://dev.w3.org/SVG/profiles/1.1F2/publish/coords.html#TransformAttribute

   Simon: CSS happy to drop skew , or skew-x, skew-y
   ... skew with 2 params. Happy to move to what SVG does there with
   separate skew-x, skew-y

   Dino: Animating skew tends to look wierd if it uses matrix

   Resolved: Remove skew, add skew-x and skew-y

   Erik: ref transform

   <ed> [18]http://www.w3.org/TR/SVGTiny12/coords.html#transform-ref

     [18] http://www.w3.org/TR/SVGTiny12/coords.html#transform-ref

   Chris: Ref lets you unwind the CTM to a different element

   Simon: Inverse transform may be awkward on 3D if they dont share a
   common 3d space

   Chris: Same if you have HTML with two SVG subtrees with different
   viewboxes. no common world coordinate system

   Erik; Can only specigy svg in the syntax for the CTM

   <shepazu> scribeNick: shepazu

   dino: I don't see why you need transformRef in the first 2

   ed: it's for moving back to something you can control, as opposed to
   zooming and panning

   simon: position fixed

   dino: we could put it in, but have it not apply, or have it as a

   ed: not sure it makes sense in CSS
   ... it would have to take precedence in some way

   dino: is this used and useful?

   ed: our implementation is slightly different than the spec

   <ChrisL> ScribeNick: ChrisL

   <shepazu> Issue: consider not adding transformRef to Transforms spec

   <trackbot> Created ISSUE-1 - Consider not adding transformRef to
   Transforms spec ; please complete additional details at
   [19]http://www.w3.org/Graphics/fx/track/issues/1/edit .

     [19] http://www.w3.org/Graphics/fx/track/issues/1/edit

   <scribe> ACTION: Simon to remove skew and add skew-x and skew-y to
   consolidated transform spec [recorded in

   <trackbot> Sorry, couldn't find user - Simon

   trackbot, status?

   <smfr> darn :)

   <scribe> ACTION: Chris to Simon to remove skew and add skew-x and
   skew-y to consolidated transform spec [recorded in

   <trackbot> Created ACTION-2 - Simon to remove skew and add skew-x
   and skew-y to consolidated transform spec [on Chris Lilley - due

   <dino> my suggestion was that transform-ref should have been a
   separate property/attribute, rather than part of the transform

   Chris: in retrospect I agree

   Doug: Some parts of SVG Tiny 1.2 could be rethought in SVG 2.0

   <dino> for example, what does transform="ref(svg, 100, 100) ....
   ref(svg, 200, 200) ... " mean?

   <dino> anyway.

   Erik; Although its useful, and making it available through CSS
   transforms would be fine

   Chris: Do we have merged specs or do we need to check in both and
   then work on a third?

   Anthony; Have started a merge for transforms, but its harder than it

   Chris: Best to have archival copies to refer to during the merge?

   Dino: We currently use Bert's script to take HTML and make it
   pubrules compliant. Also need to redirect shortnames. Publish with
   new refs as soon as possible

   Simon: And uodate CSS current work

   Doug: And SVG wiki likewise

   Simon: Need to know when the public FX one is the master so we can
   get edits done

   <shepazu> ACTION: Simon to remove skew and add skew-x and skew-y to
   consolidated transform spec [recorded in

   <trackbot> Sorry, couldn't find user - Simon

   ACTION; Doug set up an FX wiki

   <shepazu> ACTION: smfr to remove skew and add skew-x and skew-y to
   consolidated transform spec [recorded in

   <trackbot> Sorry, couldn't find user - smfr

   trackbot, self.reboot()

   <trackbot> Sorry, ChrisL, I don't understand 'trackbot,
   self.reboot()'. Please refer to
   [24]http://www.w3.org/2005/06/tracker/irc for help

     [24] http://www.w3.org/2005/06/tracker/irc

   <smfr> trackbot, reload

   <dino> i thought there was a reload command

   Resolution: Freeze the separate CSS and SVG specs, copy to new FX


   <shepazu> ChrisL: couldn't hear you

   <shepazu> try again?

   <anthony> Issue: Need to figure out how transitions affect a
   transform on an element that has an animation running on it

   <trackbot> Created ISSUE-2 - Need to figure out how transitions
   affect a transform on an element that has an animation running on it
   ; please complete additional details at
   [25]http://www.w3.org/Graphics/fx/track/issues/2/edit .

     [25] http://www.w3.org/Graphics/fx/track/issues/2/edit

Summary of Action Items

   [NEW] ACTION: Chris to Simon to remove skew and add skew-x and
   skew-y to consolidated transform spec [recorded in
   [26] http://www.w3.org/2010/03/11-fx-minutes.html#action03 ]
   [NEW] ACTION: Doug to create an FX repository [recorded in
   [27] http://www.w3.org/2010/03/11-fx-minutes.html#action01 ]
   [NEW] ACTION: Simon to remove skew and add skew-x and skew-y to
   consolidated transform spec [recorded in
   [28] http://www.w3.org/2010/03/11-fx-minutes.html#action02 ]
   [NEW] ACTION: Simon to remove skew and add skew-x and skew-y to
   consolidated transform spec [recorded in
   [29] http://www.w3.org/2010/03/11-fx-minutes.html#action04 ]
   [NEW] ACTION: smfr to remove skew and add skew-x and skew-y to
   consolidated transform spec [recorded in
   [30] http://www.w3.org/2010/03/11-fx-minutes.html#action05 ]

   [End of minutes]

 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Thursday, 11 March 2010 22:29:17 UTC