See also: IRC log
<trackbot> Date: 04 November 2010
<scribe> scribe: anthony
<scribe> scribeNick: anthony
<scribe> chair: Erik
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]
<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
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
<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].
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
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].
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> 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
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]