- From: Chris Lilley <chris@w3.org>
- Date: Thu, 11 Mar 2010 23:28:42 +0100
- To: public-fx@w3.org
Hello public-fx,
Minutes are here
http://www.w3.org/2010/03/11-fx-minutes.html
and below as text for bots
CSS-SVG Task Force Teleconference
11 Mar 2010
[2]Agenda
[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
Attendees
Present
ed, Doug_Schepers, ChrisL, anthony, +1.858.655.aaaa, plinss_,
+1.408.454.aabb, dino, smfr, fantasai
Regrets
Chair
Erik
Scribe
Chris
Contents
* [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
value
<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
documented
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
[12]http://www.w3.org/2010/03/11-fx-minutes.html#action01]
<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
<ed>
[13]http://lists.w3.org/Archives/Public/www-svg/2010Mar/0013.html
[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
[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
<smfr>
[15]http://www.w3.org/TR/2009/WD-css3-2d-transforms-20090320/#animat
ion
[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
space
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#UsingP
resentationAttributes
[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
collection
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 -
volunteers?
... 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!
<ed>
[17]http://dev.w3.org/SVG/profiles/1.1F2/publish/coords.html#Transfo
rmAttribute
[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
examples...
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
translate...
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
[20]http://www.w3.org/2010/03/11-fx-minutes.html#action02]
<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
[21]http://www.w3.org/2010/03/11-fx-minutes.html#action03]
<trackbot> Created ACTION-2 - Simon to remove skew and add skew-x
and skew-y to consolidated transform spec [on Chris Lilley - due
2010-03-18].
<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
looks
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
[22]http://www.w3.org/2010/03/11-fx-minutes.html#action04]
<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
[23]http://www.w3.org/2010/03/11-fx-minutes.html#action05]
<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
repository
adjourned
<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