CSS-SVG Task Force Teleconference -- 11 Mar 2010

<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 http://krijnhoetmer.nl/irc-logs/css/20100311#l-61

<shepazu> anne, will you join the call?

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

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

<shepazu> 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> 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 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> http://lists.w3.org/Archives/Public/www-svg/2010Mar/0013.html

<ed> annevk had some comments on the auto-suggestion, 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> 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

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> 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> 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 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 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 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 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 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 http://www.w3.org/2005/06/tracker/irc for help

<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 http://www.w3.org/Graphics/fx/track/issues/2/edit .

<fantasai> q

<TabAtkins> Too late for a q, fantasai; Zakim has already ended the conf.

<fantasai> heh, sorry, wrong window

- DRAFT -

CSS-SVG Task Force Teleconference

11 Mar 2010

Attendees

Contents

Charter and so on

CSS 2d Transforms and SVG Transforms differences

Summary of Action Items

Scribe.perl diagnostic output