- From: Brendan Kenny <bckenny@gmail.com>
- Date: Thu, 11 Mar 2010 16:46:01 -0600
- To: Chris Lilley <chris@w3.org>
- Cc: public-fx@w3.org
On Thu, Mar 11, 2010 at 4:28 PM, Chris Lilley <chris@w3.org> wrote: > 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 I hate skew too! Now that a change wouldn't cause a split between the SVG and CSS drafts, it would be great to take a second look at replacing skew() with shear(), which is more idiomatic and a bit more sane wrt animation without that hidden tan function. DBaron originally brought it up last December: http://lists.w3.org/Archives/Public/www-style/2009Dec/0059.html
Received on Thursday, 11 March 2010 22:46:37 UTC