W3C

- DRAFT -

SVG Working Group Teleconference

04 Nov 2010

See also: IRC log

Attendees

Present
(none)
Regrets
Chair
ed
Scribe
anthony

Contents


<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 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 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 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> 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> 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> 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> 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 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> 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 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 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 http://www.w3.org/Graphics/SVG/WG/wiki/User_talk:Pdengler to the main wikipage and break it into subpages [recorded in http://www.w3.org/2010/11/04-svg-minutes.html#action07]

<trackbot> Created ACTION-2894 - Move 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].

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 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 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> 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> 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> 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> 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> 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 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> 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 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 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 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 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 http://www.w3.org/2010/11/04-svg-minutes.html#action05]
[NEW] ACTION: ed to move http://www.w3.org/Graphics/SVG/WG/wiki/User_talk:Pdengler to the main wikipage and break it into subpages [recorded in http://www.w3.org/2010/11/04-svg-minutes.html#action07]
[NEW] ACTION: pdengler follow up on tabAtkins gradient requirement document [recorded in 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 http://www.w3.org/2010/11/04-svg-minutes.html#action01]
[NEW] ACTION: pdengler to submit new filter effects proposals [recorded in 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 http://www.w3.org/2010/11/04-svg-minutes.html#action08]
 
[End of minutes]

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

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 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 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/
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 (lacks 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 more compliments on CSSA/
Succeeded: s/... and I don't want to keep adding to CSSA where it's gaining massive adoption/... it's rapidly gaining adoption so it is important 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 not 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 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/
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: http://www.w3.org/2010/11/04-svg-minutes.html
People with action items: anthony chris dean dino ed pdengler tatkinsj

[End of scribe.perl diagnostic output]