Minutes, Lyon F2F day 1 (November 4, 2010)

Afternoon session was a combined meeting with the CSS Group.




      [1] http://www.w3.org/

                               - DRAFT -

                   SVG Working Group Teleconference

04 Nov 2010

   See also: [2]IRC log

      [2] http://www.w3.org/2010/11/04-svg-irc






     * [3]Topics
         1. [4]High Level Scenarios
         2. [5]SVG Transforms
         3. [6]transforms across SVG and CSS
         4. [7]filters
         5. [8]MS Filters that aren't supported
         6. [9]Gradients
         7. [10]embed SVG in an HTML with CSS
     * [11]Summary of Action Items

   <trackbot> Date: 04 November 2010

   <scribe> scribe: anthony

   <scribe> scribeNick: anthony

   <scribe> chair: Erik

High Level Scenarios

   PD: I've been thinking about what we should be working on
   ... and my thinking is that we have two sets of work
   ... two chunks
   ... one is rationalizing all the technologies we have in front of us
   ... HTML, CSS, SVG and Webapps modules
   ... I don't think there is any mystery there
   ... Then there is what are the new things we can do
   ... and thing I would like to see us do
   ... is see us do a short release of the integration stuff
   ... where we say we stablise these technologies

   ED: I guess it depends on how many people we have working on it

   PD: You think it's a resource issue?

   ED: Yes to some degree
   ... you can have people working on advance gradients
   ... and it's just research and syntax
   ... if it's really separate then it can run in parallel
   ... When there is something that affects other parts of SVG
   ... the it becomes tricky

   PD: There is a finite set of technology
   ... that can bring it together
   ... I think it's animation

   AG: I think it's that and it's also the rendering model
   ... and how things interact with that

   PD: I think that my first slice with that paper is to say that
   perhaps solving both problems at once
   ... would take too long
   ... What I'm reading is tough luck we need to figure that out
   ... Let's just decide to do one all the other
   ... if we do the simpler one then we have something we can achieve

   ED: I think it's not a small problem
   ... there are a finite set of things that could easily be targetted

   PD: I'm watching the developers from RIM who played with it
   ... and Opera's played with it

   ED: I don't see any problem with applying transitions to SVG
   ... there are things where you can use them together

   PD: That's my question. Is it that if you're both
   ... If you're using both
   ... Opera, Mozilla and Webkit
   ... and I mixed them today
   ... would I get the same experience

   ED: I'm not sure
   ... they are on the same level
   ... but if they were
   ... then yes

   PD: So it's defined enough

   ED: Sure SMIL can listen for events
   ... and trigger the transitions

   PD: SMIL can listen for events
   ... and trigger it

   ED: You can listen for mouse click
   ... using SMIL and then animate the class name so you get a
   transition trigger using the class name

   PD: The thing that I was thinking that might cause collisions
   ... is first off when there are shared properties
   ... e.g. Transforms
   ... lets identify those attributes we want to make properties and
   resolve those conflicts
   ... I know we haven't done it across the board
   ... but we've decided it for Transforms at least
   ... Let's take opacity which is a property
   ... if CSS is animating and SMIL is animating them at the same time
   ... will I get a interoperable behaviour?

   ED: Why would you do that in the first place?

   PD: Only thing I can think of
   ... is it's accidentally done
   ... or I've lifted a style sheet

   ED: It's not defined
   ... you'd probably get some kind of behaviour

   PD: That was part of my paper that said
   ... lets leave that undefined
   ... unless we decide to work on that

   ED: I don't think the scenario of animating the same property at the
   same time with two different technologies is a likely case, and
   probably not something you'd want to be doing in the first place

   PD: The only thing I can think of here, and I'm going to contrive a
   ... If I have a banner add animation
   ... declarative animation
   ... and there is vector art moving it across the the screen
   ... using SMIL
   ... and there is CSS transition where every time I hover over the
   <g> element it changes the scale
   ... is that contrived?
   ... is that a real scenario?

   ED: Yeah...

   PD: Maybe we do need to figure this out

   ED: It's not more complicated than having hover figured out

   PD: I can use SMIL to change the transform attribute
   ... right?

   ED: Sure

   PD: I'm doing transform translate
   ... to translate the 'x'
   ... and then you're using a CSS transition to change the scale
   function on transform
   ... I have two things changing the transforms

   ED: If we have the transforms draft that Anthony is working on
   ... then you'd apply the SMIL animation then whatever the CSS
   transition is applied
   ... so it's being overridden by the transition

   PD: So now I have a defined behaviour
   ... CSS wins
   ... because that's the defined order of operation
   ... Lets say I had the <g> as the entire banner
   ... and I'm SMIL animating the translate transform
   ... and I use a class to change the inner vector art on the banner
   ... is that a problem?

   ED: I think that is ok
   ... most of these problems that you're trying to figure out
   ... can be worked around
   ... it is possible to get the behaviour you want

   PD: I'm trying to tease out if there are any areas that need to be
   defined still
   ... like did the DOM consistently change, I'm trying to think if
   there are any cases

   AG: I thought we discussed this at a telcon
   ... and Alex D said that transitions sits on top of the sandwich

   ED: I think the thing that needs to be defined
   ... is the base value
   ... I think that should be something that goes into the Transitions
   ... when do apply it to the SMIL model

   PD: Should we find a single area owner to define this
   ... or do we need to spread it out

   ED: I think this is a single thing
   ... that we can give someone an action to follow through on that

   PD: And you believe that belongs in the Transitions spec?

   ED: Right

   <scribe> ACTION: pdengler to Communicate base value issue between
   SMIL and Transitions with CSS Working Group [recorded in

   <trackbot> Created ACTION-2889 - Communicate base value issue
   between SMIL and Transitions with CSS Working Group [on Patrick
   Dengler - due 2010-11-11].

   PD: So the other thing I thought through
   ... was can or should SMIL work with HTML when it is a foreignObject
   in SVG?
   ... and does that start to go through...
   ... because those properties will keep cascading

   ED: The thing is you can do the same thing with transitions
   ... even if you didn't come close to touching it
   ... I think the same thing applies to SMIL

   PD: I think a key scenario for SMIL is advertisement

   AG: I agree

   PD: And in those I don't want to just animate SVG in an ad. Can SMIL
   animate HTML and SVG?
   ... we want it to

   ED: I guess you could

   PD: Why would I want stop at a vector graphic with SMIL

   DS: I think if we are going to have this conversation we should get
   dino on the call

   [break for 5 mins]

   <shepazu> dino: can you please call zakim, code 26634?

   PD: [Brings Dino up to speed]

   DJ: The combined in the agenda topic - what is that?

   ED: I haven't really seen a combined proposal so far

   PD: Are you asking if there is going to be a larger conversation?

   DJ: Interested in both

   DS: Since I.E. is examining the higher level of animation is that of
   interest to you?

   DJ: Yes

   PD: I have a third topic is overlapping technologies
   ... Today we can talk about Transitions
   ... I'm assuming that CSS Transitions is a baked spec upfront
   ... the thing I'm trying to get my head around is how they work
   together when they are on the same page
   ... and SVG has SMIL and we were walking through if and any
   collisions might happen
   ... I think the end outcome and in the Transforms spec that Anthony
   has been working on
   ... there has been discussion that when the transform or any
   property gets animated
   ... by transitions or animations
   ... there's a defined order
   ... in which they apply
   ... so SMIL animates first then Transitions are applied
   ... is that correct?
   ... There's an issue about how do Transitions affect the base value

   DS: As I understand it, SMIL says that it is a separate OM to the
   DOM and the CSS OM
   ... they are presentation a but they are higher?
   ... is that a fair characterization?

   ED: Not entirely correct
   ... the animVal (SMIL) is exposed to the DOM

   DJ: I think it is undefined at the moment
   ... The only thing that Transitions and Animations say that the
   style value on the element is not effect by CSS Animation
   ... but if you want computed value
   ... for an element

   DS: But for SMIL, it never defined it well?

   DJ: SMIL defined it's own DOM extension
   ... I have no idea if implementations do this
   ... so CSS Animations works at the same level that SMIL does
   ... if you have a transition running
   ... and a CSS Animation
   ... the Animation will always win

   DS: My suggestion in an earlier SVG telcon
   ... the SMIL OM is obscure and not very clear
   ... and we need to resolve the interactions
   ... between what happens when something is SVGA and Transitions
   ... SVGA should operate on the same level as a CSS Animation
   ... so they complement each other

   DJ: Good idea
   ... The problem is things like radius on a circle, something that
   SVGA can animate
   ... you need to be able to query the current animated state
   ... Maybe there is some other method to get the current animated

   DS: Even if we don't treat them as properties
   ... even those these are attributes
   ... we could expose them to the CSS OM
   ... because we are allowing them to be animated?

   DJ: So the CSS OM is a bit horrible, the discussion of combining
   CSSA and SVGA is we should just have a single model
   ... that would just make more sense
   ... it would nice
   ... if we can say windowGetAnimatedElement
   ... get the current animated state
   ... You're suggestion to expose SVG properties
   ... to CSS
   ... you'd have to come up with some extra mechanism to expose it
   ... e.g. prefix a name or something

   PD: I think the interesting thing is to have a consistent query
   ... to have a way to get what's happening
   ... which ever is animating

   DS: If we want to come up with a better way to do the animation
   ... I'm all for it
   ... a cleaner neater model
   ... that works better than the CSS OM, I'd be fine with

   DJ: We can start small
   ... It wouldn't be too much of a burden
   ... I don't know where we are in the discussion
   ... but CSS animation is about at the same level as SMIL
   ... and we have to define which overrides each other

   PD: I think I heard that SMIL and CSSA are at the same level
   ... but CSSA overrides SMIL

   DJ: I don't think anyones tried that, but we just have to decide
   ... my suggestion was have them be applied at the same level

   DS: I think we are all agreed that we want to get the animated value
   ... for attributes and properties
   ... and I think that we are agreed that it should be same object

   ED: Depends on what you mean exactly I guess

   DS: Computed style is part of the CSS OM and the animated value of
   attributes is different
   ... but don't we really want to expose both properties
   ... we want one mechanism to do that
   ... not two

   ED: We have the trait access stuff in Tiny 1.2
   ... that gives you the animated presentation value or the base value
   and it works on both
   ... properties and attributes
   ... but it wasn't meant for 1.1 (lacks some things that are defined
   in 1.1, only covers 1.2T stuff)

   DS: We're not talking about 1.1
   ... we are talking about SVGA

   PD: Here is where my mind is cloudy, the question is one animation
   model more powerful than an other
   ... SMIL is more powerful than CSSA

   DS: In some ways

   PD: But CSSA is more preferred by web develoeprs
   ... .because CSS is well known
   ... CSS doesn't apply to enough things (attributes) where as SMIL
   ... I'm caught between so many differences
   ... is there a single declarative animation system?
   ... or are we bring them forward together?

   DS: Core Animation it is very like SMIL with out time containers and
   other SMIL components

   DJ: The implementation in webkit uses both
   ... I wouldn't bring Core Animation into the mix
   ... I think it's worth nothing
   ... that when Core Animation was starting
   ... they found the SMIL animation model as a nice model to follow
   ... and CSS follows it as well
   ... forget about syntax and the more complex parts
   ... like syncing time bases
   ... and it was really easy to describe that model in CSS
   ... The reason we applied animations in CSS is it made sense at that
   ... it was more familiar to web authors
   ... and there wasn't a clear way to apply animation to HTML
   ... the problem is that CSS and SVG is that it's not clear what
   happens when you combine the two

   PD: The thing is you have a syntax that is popular

   DJ: we get way more compliments on CSSA than we do complaints
   ... it's rapidly gaining adoption so it is important to stabilize
   the specification
   ... so there are things we can fix easily
   ... and SMIL which is also an excellent model to apply to SVG
   ... it has this legacy where people don't like SMIL
   ... Patrick raised the issue about what direction we can go in

   DS: I think we agree that SVGA and CSSA should both use the same
   underlaying model
   ... if that means simplifying the SVGA model
   ... then so be it
   ... because you certainly don't want to implement two
   ... and we want to have a single API that can apply to both
   ... I think that is actually two fundamental points of agreement

   DJ: Yep I agree with that

   PD: I think you're right, give me some time

   <ed> [back from break]

   PD: I have the questions figure that I want
   ... but I'm going to have make them as statements
   ... SVG is an XML format and it's started that way
   ... and that's why it's attribute based
   ... correct?

   DS: Yes

   PD: And HTML is not? It's a derivative?

   DS: HTML is a text document language
   ... SVG is a language to describe shapes
   ... it makes more sense for attributes to be attributes
   ... if SVG wasn't XML
   ... it would've been similar model
   ... look at VML

   PD: One of the things we talked about was, maybe alot of SVG
   attributes and are presentation
   ... and should be in CSS and that is not going to happen
   ... and that is that
   ... I believe that the biggest use case for SVG going forward
   ... is in an HTML document

   DS: I think that is arguably correct

   PD: Then it falls in to web developers hands
   ... and we want them to adopt it

   DS: Of course we want them to adopt it

   PD: They are experienced with document content, CSS and script

   DS: I want to illustrate some differences
   ... between HTML and SVG
   ... if you look at those elements in SVG that are not for marking up
   ... such as form
   ... stuff
   ... they are heavily attribute beased
   ... I think similar design choices were made for SVG
   ... the radius of a circle is presentation
   ... it's the actually circle
   ... Path
   ... .the geometry of the path is the path
   ... it's not a presentation of the path
   ... CSS makes more sense for HTML than it does in SVG
   ... Let me rephrase that SMIL makes less sense for HTML than it does
   for SVG
   ... where as CSS animation makes sense for both

   PD: Are we saying there is a presentation technology for
   non-presentation and for presentation technology

   DS: Almost. Having one animation technology that works for both
   ... makes perfect sense
   ... but that metric may not make sense for HTML

   PD: So you don't want to have multiple animation models
   ... but you are ok with multiple animation syntaxes

   DS: I'm ok with CSSA being able to animate the radius of a circle

   PD: In an ideal world we'd have model and one syntax

   DS: I'm not yet convinced

   AG: I think you'd what both

   DS: For chaining animations, you'd want both
   ... the element syntax is element is better for CSS syntax for

   DJ: SVGA is an element in the DOM and CSSA is not
   ... there is no way to get a reference to the CSS object

   <TabAtkinsTPAC> Yet.

   AG: I have written SVG script that modifies the animation in the DOM

   DJ: T\his is something in SVGA that is currently supported in CSSA
   ... in an ideal world it would be great to have one syntax
   ... but I don't think two is necessarily bad
   ... CSSA may fit better when creating a document
   ... but SVGA may be good for generated content

   <glazou> +1 TabAtkinsTPAC

   <TabAtkinsTPAC> That... is all of it? I'm not in the room.

   <TabAtkinsTPAC> Oh!

   <TabAtkinsTPAC> TabAtkinsTPAC: believes a third syntax, specialized
   for creating and running animations purely in JS, is desirable as

   <TabAtkinsTPAC> TabAtkinsTPAC: It should be close to the existing
   syntaxes, but something like "x = new Animation({0:{top:100},
   100:{top:200}}); x.animateElement(elem);"

   PD: Elements and attributes aside is it reasonable to predict that
   CSSA features will be on par with what SMIL does in SVG?

   DS: Dino?

   DJ: It is definitely realistic
   ... It would be possible to get to same level of functionality
   ... it's just not wanting to keep adding to a spec that's in
   ... it's a point where it's almost getting out of control of what
   the working group wants to do with it
   ... Adobe are now demonstrating tools that convert Flash to CSSA
   ... I see comments that ability to chain animations
   ... have one animation start at the end of another one
   ... which would be easy to add and implement
   ... I dunno how much we want to change CSSA until we get some base

   DS: High level comment - I really want Adobe to start attending
   these telcons. From Dreamweaver or Flash
   ... it's hard to guess what they're intentions are

   DB: There has been some discussion if you have the same feature sets
   ... and the same model

   PD: I would love for Apple to attend these telcons more frequently

   DB: and my understanding is that some of the model is substantially
   ... I don't know how unified you want the model to be

   DS: Dino is saying that the models can be completely unified

   DJ: I'm not a CSS expert
   ... but as far as animations go

   <Hyeonsoo> y

   DJ: then yes

   DB: I thought mostly about transitions and how they interact with

   DS: I have to confess that I have not looked much at transitions
   ... as I understood it they were CSSA country cousin

   DB: Because of their model they have to fit in a specific place
   ... and animations to a degree is built on top of transitions

   DJ: That might be just a fall over
   ... that as a implementer that they are really the same
   ... but I think they are fairly separate

   DB: The way I read it was you declare points and force how to
   transition between the points

   DJ: I would say that animations would apply on what the current
   style is
   ... at the code level it's the other way around
   ... Transitions happen when the current style changes
   ... Animations trump that
   ... and will always compute the final style

   DS: Patrick you started this session by saying you know the
   questions you wanted to ask

   PD: If the use cases and scenarios are the same for HTML and SVG and
   I'll give one particular scenario which started before
   ... which is an advertisement
   ... if the scenario is the same and the developer is the same
   ... why shouldn't the syntax and the underlying model should be same

   DS: I think that if the same functionality is going to be same; if
   they cover the same things
   ... I think it makes sense for the same developer use the same
   ... and that syntax is the CSS syntax

   PD: How do you make the syntax the same when SVG is attribute based

   DS: I perfectly ok with CSS animating SVG attributes in some way
   ... even though they are attributes they can still be animated
   ... and this new API (similar to traits maybe) the way of getting
   the animated value
   ... access is both equally

   <TabAtkinsTPAC> TabAtkinsTPAC is also fine with CSS animating
   attributes. I'd prefer it, actually, to be available more widely
   than SVG.

   SG: In orders to use animations those attributes become properties
   in the style sheet

   PD: Isnt' there is alternative way?

   SG: No

   PD: Lets't take the case where there is an attribute that has a
   corresponding property
   ... and if you set a style sheet with rect and a width=100 and the
   style sheet has a width=50
   ... how do you solve that case
   ... how do you solve the 'd' case

   <dino> it's ugly, but you could do something like -svg-rx: 10px;

   DJ: One suggestion is you put some kind of namespace on properties
   that come from SVG
   ... maybe you don't allow them as property names
   ... in that they can't be set in CSS

   <pdengler> pdengler: would you consider attrib-rx: 10px

   DJ: but are able to be animated

   DB: From a CSS perspective you'll pay most of the cost of making
   them properties

   DS: I have no problems with making them properties
   ... we need to check to see if it makes sense to make them in to CSS

   <TabAtkinsTPAC> TabAtkinsTPAC reiterates that he's in favor of
   animating arbitrary DOM properties.

   AG: I don't care what model we use, but as long as the animation
   lives in the DOM
   ... so agree with Tab

   PD: When we animate opacity with CSSA it affects the DOM

   <sylvaing> but what's a 'dom property' ? do you want to animate
   offsetWidth or the type attribute ? animating style properties is
   the primary scenario imo

   <TabAtkinsTPAC> TabAtkinsTPAC: Yes, animating offsetWidth is what
   I'm talking about. And arbitrary attributes on elements.

   DS: It is likely that people will use both

   PD: I don't think they'll use both

   <dbaron> I'm curious what "affects the DOM" means above

   <sylvaing> except offsetWidth is read-only so it makes no sense

   DS: I'm saying that in my idea of the unified model, that SVGA can
   be done with element syntax

   PD: I'm not saying kill that off
   ... but I don't know what the issue is

   DS: Chris has claimed that the CSS WG is against taking on a bunch
   of properties

   DB: Some people don't want more and more properties

   SG: But it still happens anyway

   PD: If you want more functionality...

   <TabAtkinsTPAC> TabAtkinsTPAC: sylvain, argh, you're right. Sorry.
   Properties that are writeable.

   DB: Would want to Håkon in on this discussion

   <sylvaing> tab, sure but aren't the ones of most interest to authors
   style properties

   PD: There is at least an underlying model for SVGA and CSSA
   ... and there are developers who will not deprecate SVGA
   ... and if we can allow CSSA to do more with SVG

   ED: What do you include in the underlying model?

   DS: same underlaying data model
   ... same functionality'
   ... share data model
   ... when you change it in SVGA it is exactly the same if you changed
   it with CSSA
   ... they have the same effect
   ... accessed through the same API
   ... and they have the same value
   ... however that proposal is managed

   DB: What's separate from computed style?

   DS: I think we can agree we want the same underlying feature set
   ... and data model

   SG: We can resolve to have a proposal based on that

   <TabAtkinsTPAC> TabAtkinsTPAC: sylvaing, yeah, style properties are
   the most common now. But we're, for example, experimenting with
   hooking up js-based models with elements directly, so you can
   auto-monitor/respond to attribute changes. So I'd like to keep it
   open to animate arbitrary attributes at least, even if we don't
   directly address it yet.

   <TabAtkinsTPAC> TabAtkinsTPAC: It's probably okay if that's only
   possible via the js api.

   RESOLUTION: To have a proposal to have the same shared data model
   and functionality across SVGA and CSSA

   <scribe> ACTION: Dino to Work with PatrickD on drafting up a
   proposal for the same shared data model and functionality across
   SVGA and CSSA [recorded in

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

   <scribe> ACTION: Dean to Work with PatrickD on drafting up a
   proposal for the same shared data model and functionality across
   SVGA and CSSA [recorded in

   <trackbot> Created ACTION-2890 - Work with PatrickD on drafting up a
   proposal for the same shared data model and functionality across
   SVGA and CSSA [on Dean Jackson - due 2010-11-11].

   DS: My suggestion is that based on conversations with Dean is that
   the CSS OM is not necessarily the most efficient way of handling the
   ... and we would want an API to inspect the data model

   ED: Inspecting the data model and not just the animated
   (presentational) values would be useful

   <TabAtkinsTPAC> TabAtkinsTPAC: CSSOM, as currently exists, is the
   suckiest way to handle the data model. Its only virtue is that it

   <dino> Dean: I agree with Tab.

   AG: +1 with what Tab said

   DS: As part of the effort going forward we would like to define this

   PD: In terms of what Dino is going to write up
   ... one of the things I want to stress
   ... we need to keep this channel open with the CSS Working Group

   <dino> DJ: Another positive outcome of such API investigation is
   that it *might* open the door to simplification of the SVG DOM - we
   might not need the whole .baseVal thing any more.

   DS: It's a separate discussion, but it's my hope as well

   ED: It is a separate discussion

   JF: I think we should have someone from Adobe to discuss the

   DS: I think you're absolutely right

   DB: You're talking about an API to trigger one animation to the

   DS: A way to access the current state of animations

   DB: So one way was to animate from one value to another, and the
   ... is an API to give the page a notifications a time that it should
   update stuff
   ... to give pages the ability to animate that can't be done
   ... Just giving the browser the ability to update the frame rate
   ... it's just exposing a small part of the animation model

   DS: I think that every body agrees here authors would love to have a
   better animation model


     [15] http://hacks.mozilla.org/2010/08/more-efficient-javascript-animations-with-mozrequestanimationframe/

   DS: If you want to bring the experiment to the group that would be

   DJ: When we start writing up the model, we can propose the API

   <ed> <set attributeName="lunch" to="break" dur="1.5h" begin="0s"/>

   <pdengler> scribeNick: pdengler

   <smfr> RRSAgent: pointer

   <ed> [back from lunchbreak]

SVG Transforms


     [16] http://dev.w3.org/Graphics-FX/modules/2D-transforms/spec/2DTransforms.html

   <smfr> what's the call-in number?

   summary of previous discussion on animations

   resolved that we want to use the same model for data, API and
   feature set across CSSA and SVGA

   shepazu: This is to make sure we are only implementing 1 animation


     [17] http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0043.html

   return to topic on transforms

transforms across SVG and CSS

   anthony: I've been working on the CSS 2d Trasnforms and SVG
   transforms that are relevant have been merged into 1 spec


     [18] http://dev.w3.org/Graphics-FX/modules/2D-transforms/spec/2DTransforms.html

   anthony: There are still some areas to finish off. It is not as
   complete as the draft in CSS trasnforms as it is missing the DOM
   interface; but the rest is well spec'd

   <smfr> yep

   smfr: On Monday the CSS Working group resolved to move 2d Transforms
   forward, and the section on animation moved to the transitions spec

   anthony: I'd like to work on a single spec that both groups can use

   chrisl: Sounds like you've done a lot of work; we thought we had
   agreed to move it to FX for that purpose

   anthony: The idea was to use this spec for SVG 2.0 for the
   transforms chapter
   ... I'm also happy to commit to helping with tests for that as well

   smfr: We have to figure out how the spec gets published

   chrisl: what I have seen inthe past, is that once a taskforce is
   ready to publish, then it is taken back to both working groups
   ... Since they are done in parallel, it usually only takes a week

   anthony: We don't want to hold up the CSS group, so I can put in the
   extra hours to bring it up to the same speed as the current CSS 2d
   Transforms spec

   smfr: With a combined specification, the two languages means that
   there is additional complexites as certain functions only apply to
   certain languages

   anthony: There are areas in the spec where I had to change some
   wording that does have to take into account CSS and SVG.

   ed: We should make sure that the transform for SVG becomes a
   presentation property thus little (or maybe no) specifics around SVG
   have to be mentioned in the CSS specification

   <scribe> ACTION: anthony to spec the SVG Attribute as a presentation
   property removing the need to keep same behavior as in other
   presentation properties in SVG [recorded in

   <trackbot> Created ACTION-2891 - Spec the SVG Attribute as a
   presentation property removing the need to keep same behavior as in
   other presentation properties in SVG [on Anthony Grasso - due

   pdengler: corretino :SVG Transform Attribute

   <anthony> s/correctino :/correction: /

   <smfr> could dbaron approach the phone?

   dbaron: What we decided to move the section on animations from the
   transforms into the transition spec

   <ed> s/We should make sure that the transform for SVG becomes a
   presentation property thus little (or maybe no) specifics around SVG
   have to be mentioned in the CSS specification/'transform' is defined
   as a property in the fx-CSS2d spec, but it should probably be
   explicitly stated how it the integrates into the svg model as a new
   presentation attribute/

   anthony: One of the issues that olaf pointed out on the mailing
   list, was how to determine the difference between an SVG Trasnform
   and SVG Transform property

   <dbaron> Also there are two references to FX that say XF by mistake.

   <ChrisL> pdengler: if the svg already says a property in css
   overrides a res artr, the old content still renders and the
   difference between defaults is only apparent when someone applies

   <ChrisL> ... so if i put a transform without a default origin, in
   svg it rotates about 0,0. If I put a transform in CSS is would use
   the CSS defsult for origin

   <ChrisL> ... so existing content does not break

   shepazu: We talked before about having different defaults for CSS
   and SVG with regards to transform orgin

   <johnjan> s/ defsult/ default

   shepazu: It should have the same default when styled with CSS

   pdengler: Then we should only have to worry abou the unit type (def)
   and then support the more granular API's

   shepazu: There is an issue of being able to get any particular point
   of a transformed element and the reverse

   smfr: The CSS workking group at this point doesn't want any script
   API in the spec

   dbaron: I don't think there is an objection there.
   ... We have four browser implementation of the transforms spec, and
   not hold it up for additions

   shepazu: My concern is that there is a known solution that is
   relatively simple to implement. If we don't solve it, they will be
   scripting around this problem for a long time

   dbaron: What's the signature of the method?

   smfr: In webkit we have a method on the Window object
   convertPointFromNode and convertPointToNode
   ... Folks were resistant to putting new methods on elements, but on
   the window it wasn't as much of an issue

   dbaron: You could also have an API that converted from one node to

   smfr: In the CSS working group, was there an objection to having the
   jscript API .....

   <smfr> dbaron: was the objection to dependencies on CSSValues

   dbaron: There were two objects. There was only one impelmentation of
   the API, and that we didn't want a new API on CSSValues

   smfr: The other issue is that in the CSS spec we have the Matrix API
   and 2d vs 3d

   anthony: I did see that there may be a need to resolve CSS vs SVG
   Matrix. Would it make sense to have both names as an alias

   smfr: Trying to remember if the multiply is backward on one of them

   <smfr> multLeft vs multRight

   anthony: We should examine this very soon and sort them out

   shepazu: I think we would be doing a disservice by not putting this

   smfr: how do we get a spec that we can move forward on

   anthony: Resolving the issues with the API is necessary

   shepazu: Who had concerns about the script aspects of the API

   dbaron: That part of the CSS object model in genereal didn't want

   sylvaing: For authors to manipulate portions of the transform
   without having to parse strings

   smfr: we need to make sure that the matrix is the same, row major
   vs. column major

   shepazu: Why would there have been an incompatability in the first

   anthony: SVG did it one way, CSS did it another.

   shepazu: Could we change the way that CSS is done?

   dbaron: It doesn't get exprssed in an API

   shepazu: Is it too late to change it?

   smfr: We should hold off on deciding on anything until I look into

   shepazu: We should also include the point transformation in the spec
   regardless of the matrix

   dbaron: Coordinate system transforms is important across the board

   <dbaron> (not just for transforms)

   <dbaron> (I guess I don't have strong feelings about one spec or

   RESOLUTION: Include the transform to point API in the Transform spec

   <smfr> go Zakim

   anthony: We need to have simon finish his action item for the API's.
   I just need to finish the introduction, and add the SVG examples

   ed: Will it supercede the CSS spec, or just become one

   ChrisL: If the later edits are in both specs, we should just merge
   into one

   anthony: We need the CSS working group to accept this

   <smfr> now i can

   fantasai: Each time the FX has a resolution it should be added as an
   agenda item for each WG

   shepazu: This is a separate topic
   ... It is our understanding that these are joint deliverables. The
   SVG WG doesn' t need a separate reslution as we all attend
   ... We didn't take into account the size or the way the CSS working
   group exeucutes. Does CSS needs a seperate CSS resolution?

   <smfr> pdengler: can you minute?

   plinss_lyon: Yes, we should make sure we are clear about ownership
   and terms to avoid confusion about procedure

   anthony: I wasn't implying anything

   plinss_lyon: I was just relaying back that it added confusion to how
   the task force works. There aren't really objections, just people
   looking for more clarity

   shepazu: Logistically speaking it would be useful to have our FX
   taskforce earlier in the week, such that we can communicate these to
   the CSS working group

   <smfr> dbaron: thanks

   chrisl: That could happen on Wendesday

   chirsl: FX taskfoce on Monday; if we decide to request publication
   assuming a Thursday date. On Wednesday it can get approvel by the
   CSS working group

   anthony: I have enough work to do to finish this off and work with
   simon to do so

   shepazu: This general process applies across the FX task force so we
   don't have to resolve this again for filters, trasnforms,
   animations, etc


   <ed> [20]http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html

     [20] http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html

   ed: Above is the proposal for filters, mask and clip path from
   ... This is a proposal at this point. I have an action item to move
   it into the FX spec

   <anthony> pdengler: I was just impressed by what was done here

   <anthony> ... and I want to move it quicker

   <anthony> ... want to get it to the same spot as transforms

   <anthony> ... I had seen the implementation but hadn't read this

   <anthony> ... The only thing that has potential to make improvements
   to the model

   <anthony> ... does it make sense to have things cascade

   <anthony> ... what I saw the implementation doing

   <anthony> ... was using the defs

   <anthony> .. and using it as a style

   <anthony> ... was that an issue with doing that in HTML?

   <anthony> ... All in one file

   <anthony> chrisL: In that case you'll get the cascading

   <anthony> ... if you apply something in HTML

   <anthony> ... it will inhert to SVG

   <anthony> pdengler: If I want a filter to just apply to HTML

   <anthony> shepazu: use name spaces

   <anthony> pdengler: If I want to apply a filter just to HTML

   <anthony> ... I can't do that with just the SVG filters today

   <anthony> chrisL: You mean that I have just a HTML document I want
   to apply SVG filters?

   <anthony> ... In HTML you can have another file in the side and it
   can be referenced

   <anthony> shepazu: I think he's asking where it is defined

   <anthony> ... Yes you can

   <anthony> ... there is another thing called Canned Effects

   <anthony> pdengler: There is a Canned Effects

   <anthony> ... and do they apply to SVG

   <anthony> chrisL: Don't need to put it in <defs>

   <ed> you can also use datauri:s for putting the filter into the

   <anthony> pdengler: Need to have the SVG in there

   <anthony> ... in order to apply the filter to HTML

   <anthony> shepazu: Hang on

   <anthony> ... [draws example on the board]

   <smfr> you could also invent a syntax to refer to a filter in an
   external file: filter: url(foo.svg#bar)

   <ed> smfr: that's already possible

   <smfr> s/invent a/use the :)

   <dbaron> smfr, it's the normal way, even...

   <anthony> pdengler: They continue to be and are SVG filters?

   <anthony> shepazu: Yes

   <anthony> pdengler: So they are SVG

   <anthony> dbaron: I think at one point we'd want an alternative

   <anthony> ... for CSS

   <smfr> i heard *other than canned effects*, right?

   <anthony> dbaron: One thing we'll want is more input primitives

   <anthony> ... e.g. other sources

   <anthony> ... in addition to sourceBackground, sourceGraphics

   shepazu: There shouldn't be any 'canned effect' that could not be

   <ed> s/composed/decomposed/

   dbaron: For CSS you might be able to seperately apply filters to
   border, background and different portions of the box model

   <dbaron> and the contents

   shepazu: We are all interested in expanding filters in intereting
   new ways

   fantasai: We made a list of interesting things to filter:
   background, border, contents and the composites

   dbaron: You can achieve the composites with SVG Filters

   fantasai: We coudl just start with background


   <smfr> +q

   ed: Should they go into the same specification?

   smfr: Can we agree that we are going to use the filter property in
   CSS. The problem being microsoft using <filter>

   <smfr> example of filter:

   <smfr> filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(

   <smfr> src='images/transparent-border.png',

   <smfr> sizingMethod='scale');

   chrisl: There is a problem with sites using <filter> is using to
   detect IE

   sylvaing: We don't support this long term, but people use these
   ... We can allow for the use of the standards <filter> in standards
   mode support

   <smfr> do the MS filters always start with "progid"?

   ChrisL: The standard filter property is quite distinct and easy to

   shepazu: We should an informative note in filters specification

   <smfr> can we resolve to use the "filter" CSS property?

   <scribe> ACTION: ed to add informative note about how to handle MS
   <filter> from before [recorded in

   <trackbot> Created ACTION-2892 - Add informative note about how to
   handle MS <filter> from before [on Erik Dahlström - due 2010-11-11].

MS Filters that aren't supported

   ChrisL: There is opacity

   sylvaing: MSFT already has opacity always wins

   <scribe> ACTION: pdengler to submit new filter effects proposals
   [recorded in

   <trackbot> Created ACTION-2893 - Submit new filter effects proposals
   [on Patrick Dengler - due 2010-11-11].

   pdengler: There were two models we were thinking of. Introducing new
   primitives, or opening an extensibility model

   shepazu: Are they relatively expensive to implement?
   ... It could also take a while to get them right, which makes it
   useful to have an extensibility model

   ChrisL: This is where you need a good authoring tool

   <smfr> someone could write a webapp for this

   <ChrisL> someone could indeed

   TabAtkinsTPAC: In terms of CSS, gradients are going to change from
   the current draft


   TabAtkinsTPAC: For linears, we will move to a scheme that are easier
   to interpolate
   ... There are currently two different modes for interopolating that
   rely on two different sources
   ... SVG Radial gradients are completely different

   anthony: You cannot do conical graidents in SVG

   TabAtkinsTPAC: You cannot do conical in CSS either
   ... A proposal was made to do linears the same as SVG. It seems sort
   of confusing.
   ... I have another proposal to solve the interopolation issues. I
   need to sit down with simon

   anthony: You are not happy then with boundingBox proposal

   TabAtkinsTPAC: I think that's wierd and unexpected

   anthony: (drawing)

   gradients in CSS are not skewed

   shepazu: Adopting CSS gradients is fine with me
   ... I would like a way to specificy SVG Gradients...I would just
   like there to be more similarities
   ... Starting from different points seems wrong

   TabAtkinsTPAC: Adopting the SVG model doesn't solve the
   interpolation; you cannot support intermediate forms.

   ChrisL: Sounds like you have only looked at bbox and not

   TabAtkinsTPAC: The problem is transitioning from one to the other.
   I'm trying to find ways to do it. I might have to give up on
   radials. It may end up being that if we cannot find out how to solve
   it in radials, we might not solve it in linears.

   anthony: Are you talking about transitions?

   TabAtkinsTPAC: Yes, I should be able to transition from one to the

   dbaron: There is sitll mutiple possibilities. Its still not clear if
   you are transitioning the entire gradient line or stops

   anthony: The stops need to be realigned according to the vector you
   are transforming

   dbaron: It seems that is what most people want. The oringinal model
   for animate gradients is that they would only animate with the same
   number of stops
   ... One alternative is to animate the end points, and then the color
   irrespective of where the stops happen to be
   ... Or you could animate the color to the new color. They are
   different effects.

   anthony: Would it make it sense then to only animate graidents with
   the same amount of stops

   TabAtkinsTPAC: how does SVG animate gradients

   chrisl: you animate at a more granular level. The developer puts
   together the transition themselves.

   TabAtkinsTPAC: You want to avoid step transitions. It's not obvious
   that they bbox and userspace are different things

   anthony: Is there any reason why CSS gradients are going down this
   path as opposed to the SVG model.

   TabAtkinsTPAC: The most natural way to use it is like an image
   value, an URL. The SVG model is not natrual to the CSS model.

   plinss_lyon: This seems to be a problem with borders

   2 minute break

   <ed> ACTION: ed to move
   [23]http://www.w3.org/Graphics/SVG/WG/wiki/User_talk:Pdengler to the
   main wikipage and break it into subpages [recorded in

     [23] http://www.w3.org/Graphics/SVG/WG/wiki/User_talk:Pdengler

   <trackbot> Created ACTION-2894 - Move
   [25]http://www.w3.org/Graphics/SVG/WG/wiki/User_talk:Pdengler to the
   main wikipage and break it into subpages [on Erik Dahlström - due

     [25] http://www.w3.org/Graphics/SVG/WG/wiki/User_talk:Pdengler

   shepazu: Is gradients a deliverable of FX or CSS?

   TabAtkinsTPAC: It's CSS
   ... I'm afraid that gradients are complex enough that the language
   you express them in makes a difference

   pdengler: Does this mean that if they are fundamentally different
   the CSS should still apply to SVG


   tabAtkinsTPAC: Things that can be expressed in CSS cannot be
   expressed in SVG, because for example, applying a gradient to
   unknown dimension
   ... CSS is a superset of SVG Gradients

   ed: If we have CSS gradients, I would expect to be able to use them
   in SVG as well

   chrisl: Then its the case of managing conflicts

   tabAtkinsTPAC: A CSS Gradient should act like a paint server

   anthony: We've consider coons patches gradients, mesh gradients

   chrisl: (describes these gradients)
   ... These create texture or 3d like effects

   tabAtkinsTPAC: Property need only take an URL from SVG and apply as
   CSS gradient

   fantasai: Can this be done today?

   chrisl: There should be no reason why it shouldn't. Browsers just
   need to support it

   maintin CSS gradients for simple cases, and then be able to refer to
   SVG model for more complex gradients

   fantasai: Just have a separate file then for gradients. I don't see
   the reason for using @ rules on SVG gradients

   <fantasai> s/on SVG/in CSS/

   <fantasai> s/gradients/for complex SVG gradients/

   <scribe> ACTION: tAtkinsJ to write requirements document on
   gradients and how they work in HTML as related to SVG [recorded in

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

   <scribe> ACTION: pdengler follow up on tabAtkins gradient
   requirement document [recorded in

   <trackbot> Created ACTION-2895 - Follow up on tabAtkins gradient
   requirement document [on Patrick Dengler - due 2010-11-11].

embed SVG in an HTML with CSS

   fantasai: Issue is with replace element. If I am writing a document
   on vertical text, and I want to put a diagram in this document.


     [28] http://fantasai.inkedblade.net/style/discuss/vertical-text/paper

   fantasai: The problem is SVG says height and width is 100%.

   chrisl: The spec says, that SVG drawns 100% inside the container

   dsinger: But the problem happened earlier when you follow the rules
   for replaced elements in CSS

   fantasai: Which says look at the width and height of the element
   ... in CSS there are two widths/heights. One is the actualy
   width/height vs width/heigh attributes.

   chrisl: SVG should give you back the viewbox

   fantasai: When SVG is asked for its intrinisc size, if it is a fixed
   width it give you that back, if it does not, then it does not have
   an intrinsic width/height, but it has an intrinsic aspect ratio

   <anthony> DB: If you say have a viewBox of 100 100

   <anthony> ... and width = 4in

   <anthony> ... and height = 100%

   <anthony> ... so based on what you said earlier

   <anthony> ... is a 4 inch by 8 inch box

   <anthony> s/100%/50%/

   <anthony> CL: If you do put in a 50% it says

   <anthony> ... give the size you want to draw in

   <anthony> ... and I'll use half of that

   <anthony> DB: I still think you should end up with 4 x 8 in that

   <anthony> CL: I guess it depends on which order you consider the
   arguments here

   <anthony> ... with that you have an aspect ratio

   <anthony> TA: That's what I've specified

   <anthony> ... CSS asks do you have the definite width and height

   <anthony> DS: I think there are some pros in the spec about
   intrinsic dimensions which should be taken out


     [29] http://www.w3.org/TR/SVGTiny12/coords.html#IntrinsicSizing

   <anthony> EE: I think there is some stuff in SVG Tiny 1.2

   <anthony> ... that is non normative

   <anthony> .... about htis

   <anthony> s/htis/this/

   <anthony> DS: What authoring tools do now, Illustrator and Inkscape

   <anthony> ... they give an intrinsic size for the image

   <ed> [30]http://www.w3.org/TR/SVGTiny12/coords.html#IntrinsicSizing

     [30] http://www.w3.org/TR/SVGTiny12/coords.html#IntrinsicSizing

   <anthony> DS: You tell people to make a scalable image you put in a

   <anthony> ... and make width and height 100%

   <anthony> ... people I've talking to say this is conceptually

   <fantasai> "The intrinsic width and height of the viewport of SVG
   content must be determined from the 'width' and 'height' attributes.
   If either of these are not specified, the lacuna value of '100%'
   must be used. Note: the 'width' and 'height' attributes are not the
   same as the CSS width and height properties. Specifically,
   percentage values do not provide an intrinsic width or height, and
   do not indicate a percentage of the containing block."

   <fantasai> Note the "Note:"

   <anthony> DS: So I've talked to a lot of people about this and I can
   help them change the doc

   <anthony> ... and you start talking about coordinate spaces and they
   don't understand

   <anthony> CL: I've spoken to people who've come across this as well

   <anthony> ... and explained this to them

   <anthony> HL: Is there a document which has best practices for this?

   <anthony> CL: I agree that this is a good thing to thing to have

   <anthony> ... but we don't have one

   <anthony> DS: I don't think there is any harm in providing short
   hand way

   <anthony> ... to do something

   <anthony> ... here is the particular short hand I think we should

   <anthony> ... we add an attribute that says you can have width and
   height, scaling

   <anthony> s/scaling/and you have a property scaling/

   <anthony> ... that why they don't have to worry about what they've

   <anthony> PD: Would that override?

   <anthony> DS: Yes

   <anthony> ... I think people have a really hard time understanding
   the width and height issue

   <anthony> s/width and height issue/difference between ratio and
   width and height/

   <anthony> ... but the default would be take into account the width
   and height

   <anthony> ... and the viewBox


     [31] http://dev.w3.org/cvsweb/~checkout~/SVG/profiles/1.1F2/master/coords.html?rev=1.16&content-type=text/html;%20charset=iso-8859-1

   <anthony> or


     [32] http://dev.w3.org/SVG/profiles/1.1F2/master/coords.html

   <anthony> ACTION: Chris to Copy the Intrinsic sizing wording in Tiny
   1.2 to Full 1.1 2nd Edition [recorded in

   <trackbot> Created ACTION-2896 - Copy the Intrinsic sizing wording
   in Tiny 1.2 to Full 1.1 2nd Edition [on Chris Lilley - due


     [34] http://test.csswg.org/source/contributors/fantasai/submitted/css2.1/replaced-intrinsic-ratio-001.xht

   <anthony> trackbot end telcon

   <anthony> trackbot, end telcon

Summary of Action Items

   [NEW] ACTION: anthony to spec the SVG Attribute as a presentation
   property removing the need to keep same behavior as in other
   presentation properties in SVG [recorded in
   [NEW] ACTION: Chris to Copy the Intrinsic sizing wording in Tiny 1.2
   to Full 1.1 2nd Edition [recorded in
   [NEW] ACTION: Dean to Work with PatrickD on drafting up a proposal
   for the same shared data model and functionality across SVGA and
   CSSA [recorded in
   [NEW] ACTION: Dino to Work with PatrickD on drafting up a proposal
   for the same shared data model and functionality across SVGA and
   CSSA [recorded in
   [NEW] ACTION: ed to add informative note about how to handle MS
   <filter> from before [recorded in
   [NEW] ACTION: ed to move
   [40]http://www.w3.org/Graphics/SVG/WG/wiki/User_talk:Pdengler to the
   main wikipage and break it into subpages [recorded in
   [NEW] ACTION: pdengler follow up on tabAtkins gradient requirement
   document [recorded in
   [NEW] ACTION: pdengler to Communicate base value issue between SMIL
   and Transitions with CSS Working Group [recorded in
   [NEW] ACTION: pdengler to submit new filter effects proposals
   [recorded in
   [NEW] ACTION: tAtkinsJ to write requirements document on gradients
   and how they work in HTML as related to SVG [recorded in

     [40] http://www.w3.org/Graphics/SVG/WG/wiki/User_talk:Pdengler

   [End of minutes]

    Minutes formatted by David Booth's [46]scribe.perl version 1.135
    ([47]CVS log)
    $Date: 2010/11/04 16:05:16 $

     [46] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [47] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20
Check for newer version at [48]http://dev.w3.org/cvsweb/~checkout~/2002

     [48] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/... depends on how many people we have working on it//
Succeeded: s/there is contrive/here, and I'm going to contrive/
Succeeded: s/scenario of animating the same element with two different
technologies is a likely case/scenario of animating the same property a
t the same time with two different technologies is a likely case, and p
robably not something you'd want to be doing in the first place/
Succeeded: s/valuye/value/
Succeeded: s/SMIL/the animVal (SMIL)/
Succeeded: s/we are exposing them to the CSS OM/we could expose them to
 the CSS OM/
Succeeded: s/but it wasn't meant for 1.1/but it wasn't meant for 1.1 (l
acks some things that are defined in 1.1, only covers 1.2T stuff)/
Succeeded: s/... we get way more compliments on CSSA/DJ: we get way mor
e compliments on CSSA/
Succeeded: s/... and I don't want to keep adding to CSSA where it's gai
ning massive adoption/... it's rapidly gaining adoption so it is import
ant to stabilize the specification/
Succeeded: s/VMLL/VML/
Succeeded: s/sped/spec/
Succeeded: s/aroud/around/
Succeeded: s/sytle/style/
Succeeded: s/set in animations/set in CSS/
Succeeded: s/Homecome/Håkon/
Succeeded: s/Dion/Dean/
Succeeded: s/model and not just the values would be useful/model and no
t just the animated (presentational) values would be useful/
FAILED: s/correctino :/correction: /
FAILED: s/We should make sure that the transform for SVG becomes a pres
entation property thus little (or maybe no) specifics around SVG have t
o be mentioned in the CSS specification/'transform' is defined as a pro
perty in the fx-CSS2d spec, but it should probably be explicitly stated
 how it the integrates into the svg model as a new presentation attribu
FAILED: s/ defsult/ default/
FAILED: s/invent a/use the :)/
FAILED: s/composed/decomposed/
FAILED: s/coudl/could/
FAILED: s/on SVG/in CSS/
FAILED: s/gradients/for complex SVG gradients/
FAILED: s/100%/50%/
FAILED: s/htis/this/
FAILED: s/scaling/and you have  a property scaling/
FAILED: s/width and height issue/difference between ratio and width and
Found Scribe: anthony
Inferring ScribeNick: anthony
Found ScribeNick: anthony
Found ScribeNick: pdengler
ScribeNicks: anthony, pdengler
Default Present: (none)
Present: (none)

WARNING: Fewer than 3 people found for Present list!

Found Date: 04 Nov 2010
Guessing minutes URL: [49]http://www.w3.org/2010/11/04-svg-minutes.html
People with action items: anthony chris dean dino ed pdengler tatkinsj

     [49] http://www.w3.org/2010/11/04-svg-minutes.html

   End of [50]scribe.perl diagnostic output]

     [50] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.

Received on Thursday, 4 November 2010 18:07:57 UTC