- From: Anthony Grasso <Anthony.Grasso@cisra.canon.com.au>
- Date: Thu, 4 Nov 2010 18:07:00 +0000
- To: W3C SVG Comments List <www-svg@w3.org>
- CC: W3C FX Taskforce Public List <public-fx@w3.org>
Afternoon session was a combined meeting with the CSS Group.
http://www.w3.org/2010/11/04-svg-minutes.html
---
[1]W3C
[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
Attendees
Present
(none)
Regrets
Chair
ed
Scribe
anthony
Contents
* [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
scenario
... 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
model
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
spec
... 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
[12]http://www.w3.org/2010/11/04-svg-minutes.html#action01]
<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
value
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
model?
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
does
... 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
level
... 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
text
... 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
somethings
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
well.
<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
development
... 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
level
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
different
... 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
SMIL
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
implementation
... 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
syntax
... 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
really
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
[13]http://www.w3.org/2010/11/04-svg-minutes.html#action02]
<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
[14]http://www.w3.org/2010/11/04-svg-minutes.html#action03]
<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
animations
... 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
exists.
<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
API
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
interface
DS: I think you're absolutely right
DB: You're talking about an API to trigger one animation to the
other
DS: A way to access the current state of animations
DB: So one way was to animate from one value to another, and the
other
... 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
declaratively
... 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
<dbaron>
[15]http://hacks.mozilla.org/2010/08/more-efficient-javascript-anima
tions-with-mozrequestanimationframe/
[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
great
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
<anthony>
[16]http://dev.w3.org/Graphics-FX/modules/2D-transforms/spec/2DTrans
forms.html
[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
model.
<ed>
[17]http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0043.ht
ml
[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
<anthony>
[18]http://dev.w3.org/Graphics-FX/modules/2D-transforms/spec/2DTrans
forms.html
[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
[19]http://www.w3.org/2010/11/04-svg-minutes.html#action04]
<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
2010-11-11].
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
styling
<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
another
smfr: In the CSS working group, was there an objection to having the
jscript API .....
<smfr> dbaron: was the objection to dependencies on CSSValues
primarily?
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
in
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
additions
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
place
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
it
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
two.)
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
filters
<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
Mozilla
... 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
stylesheet
<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
syntax
<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
composed
<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
s/coudl/could/
<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
today
... 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
recognize.
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
[21]http://www.w3.org/2010/11/04-svg-minutes.html#action05]
<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
[22]http://www.w3.org/2010/11/04-svg-minutes.html#action06]
<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
Gradients
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
userspaceonuse
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
other
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
[24]http://www.w3.org/2010/11/04-svg-minutes.html#action07]
[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
2010-11-11].
[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
yes
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
[26]http://www.w3.org/2010/11/04-svg-minutes.html#action08]
<trackbot> Sorry, couldn't find user - tAtkinsJ
<scribe> ACTION: pdengler follow up on tabAtkins gradient
requirement document [recorded in
[27]http://www.w3.org/2010/11/04-svg-minutes.html#action09]
<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.
<fantasai>
[28]http://fantasai.inkedblade.net/style/discuss/vertical-text/paper
[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
case
<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
<fantasai>
[29]http://www.w3.org/TR/SVGTiny12/coords.html#IntrinsicSizing
[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
viewBox
<anthony> ... and make width and height 100%
<anthony> ... people I've talking to say this is conceptually
difficult
<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
add
<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
specifiefd
<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
<anthony>
[31]http://dev.w3.org/cvsweb/~checkout~/SVG/profiles/1.1F2/master/co
ords.html?rev=1.16&content-type=text/html;%20charset=iso-8859-1
[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
<anthony>
[32]http://dev.w3.org/SVG/profiles/1.1F2/master/coords.html
[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
[33]http://www.w3.org/2010/11/04-svg-minutes.html#action10]
<trackbot> Created ACTION-2896 - Copy the Intrinsic sizing wording
in Tiny 1.2 to Full 1.1 2nd Edition [on Chris Lilley - due
2010-11-11].
<fantasai>
[34]http://test.csswg.org/source/contributors/fantasai/submitted/css
2.1/replaced-intrinsic-ratio-001.xht
[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
[35]http://www.w3.org/2010/11/04-svg-minutes.html#action04]
[NEW] ACTION: Chris to Copy the Intrinsic sizing wording in Tiny 1.2
to Full 1.1 2nd Edition [recorded in
[36]http://www.w3.org/2010/11/04-svg-minutes.html#action10]
[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
[37]http://www.w3.org/2010/11/04-svg-minutes.html#action03]
[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
[38]http://www.w3.org/2010/11/04-svg-minutes.html#action02]
[NEW] ACTION: ed to add informative note about how to handle MS
<filter> from before [recorded in
[39]http://www.w3.org/2010/11/04-svg-minutes.html#action05]
[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
[41]http://www.w3.org/2010/11/04-svg-minutes.html#action07]
[NEW] ACTION: pdengler follow up on tabAtkins gradient requirement
document [recorded in
[42]http://www.w3.org/2010/11/04-svg-minutes.html#action09]
[NEW] ACTION: pdengler to Communicate base value issue between SMIL
and Transitions with CSS Working Group [recorded in
[43]http://www.w3.org/2010/11/04-svg-minutes.html#action01]
[NEW] ACTION: pdengler to submit new filter effects proposals
[recorded in
[44]http://www.w3.org/2010/11/04-svg-minutes.html#action06]
[NEW] ACTION: tAtkinsJ to write requirements document on gradients
and how they work in HTML as related to SVG [recorded in
[45]http://www.w3.org/2010/11/04-svg-minutes.html#action08]
[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
/scribe/
[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
te/
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
height/
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:08:18 UTC