- 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