IRC log of svg on 2010-11-04

Timestamps are in UTC.

08:33:44 [RRSAgent]
RRSAgent has joined #svg
08:33:44 [RRSAgent]
logging to http://www.w3.org/2010/11/04-svg-irc
08:33:46 [trackbot]
RRSAgent, make logs public
08:33:48 [trackbot]
Zakim, this will be GA_SVGWG
08:33:48 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
08:33:49 [trackbot]
Meeting: SVG Working Group Teleconference
08:33:49 [trackbot]
Date: 04 November 2010
08:33:51 [ed]
chair: ed
08:34:56 [pdengler]
pdengler has joined #svg
08:35:33 [anthony]
anthony has joined #svg
08:36:40 [ed]
Zakim, remind me in 8 hours that anthony is wearing an IE tshirt and opera needs to bring some next time ;)
08:36:40 [Zakim]
ok, ed
08:38:15 [jun]
jun has joined #svg
08:38:30 [anthony_work]
anthony_work has joined #svg
08:39:34 [anthony]
scribe: anthony
08:39:38 [anthony]
scribeNick: anthony
08:39:44 [anthony]
chair: Erik
08:39:53 [anthony]
Topic: High Level Scenarios
08:40:24 [anthony]
PD: I've been thinking about what we should be working on
08:40:35 [anthony]
... and my thinking is that we have two sets of work
08:40:38 [anthony]
... two chunks
08:40:54 [anthony]
... one is rationalizing all the technologies we have in front of us
08:41:05 [anthony]
... HTML, CSS, SVG and Webapps modules
08:41:15 [anthony]
... I don't think there is any mystery there
08:41:22 [anthony]
... Then there is what are the new things we can do
08:41:29 [anthony]
... and thing I would like to see us do
08:41:48 [anthony]
... is see us do a short release of the integration stuff
08:42:04 [anthony]
... where we say we stablise these technologies
08:42:16 [anthony]
ED: I guess it depends on how many people we have working on it
08:42:22 [anthony]
... depends on how many people we have working on it
08:42:29 [anthony]
PD: You think it's a resource issue?
08:42:33 [anthony]
ED: Yes to some degree
08:42:40 [anthony]
... you can have people working on advance gradients
08:42:48 [anthony]
... and it's just research and syntax
08:43:05 [anthony]
... if it's really separate then it can run in parallel
08:43:27 [anthony]
... When there is something that affects other parts of SVG
08:43:32 [anthony]
... the it becomes tricky
08:43:42 [anthony]
PD: There is a finite set of technology
08:43:52 [anthony]
... that can bring it together
08:43:59 [anthony]
... I think it's animation
08:44:59 [anthony]
AG: I think it's that and it's also the rendering model
08:45:03 [anthony]
... and how things interact with that
08:45:20 [ed]
s/... depends on how many people we have working on it//
08:45:32 [anthony]
PD: I think that my first slice with that paper is to say that perhaps solving both problems at once
08:45:34 [anthony]
... would take too long
08:45:49 [anthony]
... What I'm reading is tough luck we need to figure that out
08:46:04 [anthony]
... Let's just decide to do one all the other
08:46:15 [anthony]
... if we do the simpler one then we have something we can achieve
08:46:23 [anthony]
ED: I think it's not a small problem
08:46:32 [anthony]
... there are a finite set of things that could easily be targetted
08:46:45 [anthony]
PD: I'm watching the developers from RIM who played with it
08:46:49 [anthony]
... and Opera's played with it
08:47:01 [anthony]
ED: I don't see any problem with applying transitions to SVG
08:47:13 [anthony]
... there are things where you can use them together
08:47:22 [anthony]
PD: That's my question. Is it that if you're both
08:47:28 [Hyeonsoo]
Hyeonsoo has joined #svg
08:47:31 [anthony]
... If you're using both
08:47:39 [anthony]
... Opera, Mozilla and Webkit
08:47:43 [anthony]
... and I mixed them today
08:47:48 [anthony]
... would I get the same experience
08:47:50 [anthony]
ED: I'm not sure
08:47:54 [anthony]
... they are on the same level
08:47:56 [anthony]
... but if they were
08:47:59 [anthony]
... then yes
08:48:04 [anthony]
PD: So it's defined enough
08:48:18 [anthony]
ED: Sure SMIL can listen for events
08:48:35 [anthony]
... and trigger the transitions
08:48:45 [anthony]
PD: SMIL can listen for events
08:48:47 [anthony]
... and trigger it
08:49:01 [anthony]
ED: You can listen for mouse click
08:49:34 [anthony]
... using SMIL and then animate the class name so you get a transition trigger using the class name
08:49:47 [anthony]
PD: The thing that I was thinking that might cause collisions
08:49:57 [anthony]
... is first off when there are shared properties
08:50:01 [anthony]
... e.g. Transforms
08:50:17 [anthony]
... lets identify those attributes we want to make properties and resolve those conflicts
08:50:24 [anthony]
.... I know we haven't done it across the board
08:50:34 [anthony]
... but we've decided it for Transforms at least
08:50:42 [anthony]
... Let's take opacity which is a property
08:50:45 [jdaggett]
jdaggett has joined #svg
08:50:53 [anthony]
... if CSS is animating and SMIL is animating them at the same time
08:51:06 [anthony]
... will I get a interoperable behaviour?
08:51:12 [anthony]
ED: Why would you do that in the first place?
08:51:17 [anthony]
PD: Only thing I can think of
08:51:29 [anthony]
... is it's accidentally done
08:51:35 [anthony]
... or I've lifted a style sheet
08:51:39 [anthony]
ED: It's not defined
08:51:46 [anthony]
... you'd probably get some kind of behaviour
08:51:53 [anthony]
PD: That was part of my paper that said
08:51:57 [anthony]
... lets leave that undefined
08:52:03 [anthony]
... unless we decide to work on that
08:53:08 [anthony]
ED: I don't think the scenario of animating the same element with two different technologies is a likely case
08:53:24 [anthony]
PD: The only thing I can think of there is contrive a scenario
08:54:02 [anthony]
s/there is contrive/here, and I'm going to contrive/
08:54:13 [anthony]
... If I have a banner add animation
08:54:16 [ed]
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/
08:54:23 [anthony]
... declarative animation
08:54:36 [anthony]
... and there is vector art moving it across the the screen
08:54:39 [anthony]
... using SMIL
08:54:54 [anthony]
... and there is CSS transition where every time I hover over the <g> element it changes the scale
08:54:59 [anthony]
... is that contrived?
08:55:04 [anthony]
... is that a real scenario?
08:55:08 [anthony]
ED: Yeah...
08:55:17 [anthony]
PD: Maybe we do need to figure this out
08:55:29 [anthony]
ED: It's not more complicated than having hover figured out
08:55:37 [anthony]
PD: I can use SMIL to change the transform attribute
08:55:40 [anthony]
... right?
08:55:42 [anthony]
ED: Sure
08:55:49 [anthony]
PD: I'm doing transform translate
08:55:54 [anthony]
... to translate the 'x'
08:56:14 [anthony]
... and then you're using a CSS transition to change the scale function on transform
08:56:21 [anthony]
... I have two things changing the transforms
08:56:31 [anthony]
ED: If we have the transforms draft that Anthony is working on
08:56:46 [anthony]
... then you'd apply the SMIL animation then whatever the CSS transition is applied
08:56:54 [anthony]
... so it's being overridden by the transition
08:56:57 [dino]
dino has joined #svg
08:57:02 [anthony]
PD: So now I have a defined behaviour
08:57:07 [anthony]
... CSS wins
08:57:15 [anthony]
... because that's the defined order of operation
08:57:45 [anthony]
... Lets say I had the <g> as the entire banner
08:58:00 [anthony]
... and I'm SMIL animating the translate transform
08:58:19 [anthony]
... and I use a class to change the inner vector art on the banner
08:58:28 [anthony]
... is that a problem?
08:58:31 [anthony]
ED: I think that is ok
08:58:40 [anthony]
... most of these problems that you're trying to figure out
08:58:43 [anthony]
... can be worked around
08:58:59 [anthony]
... it is possible to get the behaviour you want
08:59:19 [anthony]
PD: I'm trying to tease out if there are any areas that need to be defined still
08:59:54 [anthony]
... like did the DOM consistently change, I'm trying to think if there are any cases
09:00:04 [anthony]
AG: I thought we discussed this at a telcon
09:00:16 [anthony]
... and Alex D said that transitions sits on top of the sandwich model
09:00:33 [anthony]
ED: I think the thing that needs to be defined
09:00:37 [anthony]
... is the base valuye
09:00:45 [anthony]
s/valuye/value/
09:01:07 [anthony]
... I think that should be something that goes into the Transitions spec
09:01:19 [anthony]
... when do apply it to the SMIL model
09:01:56 [anthony]
PD: Should we find a single area owner to define this
09:02:01 [anthony]
... or do we need to spread it out
09:02:16 [anthony]
ED: I think this is a single thing
09:02:26 [anthony]
... that we can give someone an action to follow through on that
09:02:37 [anthony]
PD: And you believe that belongs in the Transitions spec?
09:02:39 [anthony]
ED: Right
09:03:58 [anthony]
ACTION: pdengler to Communicate base value issue between SMIL and Transitions with CSS Working Group
09:03:59 [trackbot]
Created ACTION-2889 - Communicate base value issue between SMIL and Transitions with CSS Working Group [on Patrick Dengler - due 2010-11-11].
09:04:27 [anthony]
PD: So the other thing I thought through
09:05:34 [anthony]
... was can or should SMIL work with HTML when it is a foreignObject in SVG?
09:05:43 [anthony]
... and does that start to go through...
09:05:52 [anthony]
... because those properties will keep cascading
09:06:05 [anthony]
ED: The thing is you can do the same thing with transitions
09:06:14 [anthony]
... even if you didn't come close to touching it
09:06:20 [anthony]
... I think the same thing applies to SMIL
09:06:35 [anthony]
PD: I think a key scenario for SMIL is advertisement
09:06:38 [anthony]
AG: I agree
09:06:57 [anthony]
PD: And in those I don't want to just animate SVG in an ad. Can SMIL animate HTML and SVG?
09:07:02 [anthony]
... we want it to
09:07:07 [anthony]
ED: I guess you could
09:07:18 [anthony]
PD: Why would I want stop at a vector graphic with SMIL
09:08:02 [anthony]
DS: I think if we are going to have this conversation we should get dino on the call
09:08:11 [anthony]
[break for 5 mins]
09:12:39 [shepazu]
shepazu has joined #svg
09:16:21 [shepazu]
Zakim, call Saint_Clair_3B
09:16:21 [Zakim]
sorry, shepazu, I don't know what conference this is
09:16:55 [shepazu]
Zakim, room for 3?
09:16:56 [Zakim]
ok, shepazu; conference Team_(svg)09:16Z scheduled with code 26634 (CONF4) for 60 minutes until 1016Z
09:17:10 [shepazu]
Zakim, call Saint_Clair_3B
09:17:10 [Zakim]
ok, shepazu; the call is being made
09:17:11 [Zakim]
Team_(svg)09:16Z has now started
09:17:33 [shepazu]
dino: can you please call zakim, code 26634?
09:20:47 [anthony]
PD: [Brings Dino up to speed]
09:21:38 [anthony]
DJ: The combined in the agenda topic - what is that?
09:21:47 [anthony]
ED: I haven't really seen a combined proposal so far
09:22:01 [anthony]
PD: Are you asking if there is going to be a larger conversation?
09:22:07 [anthony]
DJ: Interested in both
09:22:32 [sylvaing]
sylvaing has joined #svg
09:23:28 [anthony]
DS: Since I.E. is examining the higher level of animation is that of interest to you?
09:23:31 [anthony]
DJ: Yes
09:23:44 [anthony]
PD: I have a third topic is overlapping technologies
09:23:51 [anthony]
... Today we can talk about Transitions
09:24:20 [anthony]
... I'm assuming that CSS Transitions is a baked spec upfront
09:24:35 [anthony]
... the thing I'm trying to get my head around is how they work together when they are on the same page
09:24:50 [anthony]
... and SVG has SMIL and we were walking through if and any collisions might happen
09:24:58 [hidetaka]
hidetaka has joined #svg
09:25:04 [anthony]
... I think the end outcome and in the Transforms spec that Anthony has been working on
09:25:21 [anthony]
... there has been discussion that when the transform or any property gets animated
09:25:28 [anthony]
... by transitions or animations
09:25:34 [anthony]
... there's a defined order
09:25:38 [anthony]
... in which they apply
09:25:45 [anthony]
... so SMIL animates first then Transitions are applied
09:25:48 [anthony]
... is that correct?
09:26:08 [anthony]
... There's an issue about how do Transitions affect the base value
09:26:26 [anthony]
DS: As I understand it, SMIL says that it is a separate OM to the DOM and the CSS OM
09:26:35 [anthony]
... they are presentation a but they are higher?
09:26:50 [anthony]
... is that a fair characterization?
09:26:56 [anthony]
ED: Not entirely correct
09:27:07 [anthony]
... SMIL is exposed to the DOM
09:27:12 [fantasai]
fantasai has joined #svg
09:27:20 [anthony]
DJ: I think it is undefined at the moment
09:27:39 [ed]
s/SMIL/the animVal (SMIL)/
09:27:48 [anthony]
... The only thing that Transitions and Animations say that the style value on the element is not effect by CSS Animation
09:28:00 [anthony]
... but if you want computed value
09:28:37 [anthony]
... for an element
09:28:56 [anthony]
DS: But for SMIL, it never defined it well?
09:29:05 [anthony]
DJ: SMIL defined it's own DOM extension
09:29:25 [anthony]
... I have no idea if implementations do this
09:29:37 [anthony]
... so CSS Animations works at the same level that SMIL does
09:29:44 [anthony]
... if you have a transition running
09:29:48 [anthony]
... and a CSS Animation
09:29:55 [anthony]
... the Animation will always win
09:30:05 [anthony]
DS: My suggestion in an earlier SVG telcon
09:30:13 [anthony]
... the SMIL OM is obscure and not very clear
09:30:19 [anthony]
... and we need to resolve the interactions
09:30:39 [anthony]
... between what happens when something is SVGA and Transitions
09:31:00 [anthony]
... SVGA should operate on the same level as a CSS Animation
09:31:16 [anthony]
... so they complement each other
09:31:19 [anthony]
DJ: Good idea
09:31:43 [anthony]
... The problem is things like radius on a circle, something that SVGA can animate
09:31:55 [anthony]
... you need to be able to query the current animated state
09:33:15 [anthony]
... Maybe there is some other method to get the current animated value
09:33:28 [anthony]
DS: Even if we don't treat them as properties
09:33:35 [anthony]
... even those these are attributes
09:33:40 [anthony]
... we are exposing them to the CSS OM
09:33:47 [anthony]
... because we are allowing them to be animated?
09:34:05 [shepazu]
s/we are exposing them to the CSS OM/we could expose them to the CSS OM
09:34:24 [anthony]
DJ: So the CSS OM is a bit horrible, the discussion of combining CSSA and SVGA is we should just have a single model
09:34:29 [anthony]
... that would just make more sense
09:34:33 [anthony]
... it would nice
09:34:40 [anthony]
... if we can say windowGetAnimatedElement
09:34:49 [anthony]
... get the current animated state
09:35:09 [anthony]
... You're suggestion to expose SVG properties
09:35:11 [anthony]
... to CSS
09:35:50 [anthony]
... you'd have to come up with some extra mechanism to expose it
09:36:01 [anthony]
... e.g. prefix a name or something
09:36:16 [anthony]
PD: I think the interesting thing is to have a consistent query
09:36:24 [anthony]
... to have a way to get what's happening
09:36:30 [anthony]
... which ever is animating
09:36:49 [anthony]
DS: If we want to come up with a better way to do the animation
09:36:53 [anthony]
... I'm all for it
09:37:00 [anthony]
... a cleaner neater model
09:37:10 [anthony]
... that works better than the CSS OM, I'd be fine with
09:37:16 [anthony]
DJ: We can start small
09:37:37 [anthony]
... It wouldn't be too much of a burden
09:37:53 [anthony]
... I don't know where we are in the discussion
09:38:05 [anthony]
... but CSS animation is about at the same level as SMIL
09:38:15 [anthony]
... and we have to define which overrides each other
09:38:36 [anthony]
PD: I think I heard that SMIL and CSSA are at the same level
09:38:46 [anthony]
... but CSSA overrides SMIL
09:39:02 [anthony]
DJ: I don't think anyones tried that, but we just have to decide
09:39:18 [anthony]
... my suggestion was have them be applied at the same level
09:39:40 [anthony]
DS: I think we are all agreed that we want to get the animated value
09:39:50 [anthony]
... for attributes and properties
09:40:26 [anthony]
... and I think that we are agreed that it should be same object model?
09:40:32 [anthony]
ED: Depends on what you mean exactly I guess
09:41:02 [anthony]
DS: Computed style is part of the CSS OM and the animated value of attributes is different
09:41:14 [anthony]
... but don't we really want to expose both properties
09:41:23 [anthony]
... we want one mechanism to do that
09:41:24 [anthony]
... not two
09:41:34 [anthony]
ED: We have the trait access stuff in Tiny 1.2
09:41:59 [anthony]
... that gives you the animated presentation value or the base value and it works on both
09:42:09 [anthony]
... properties and attributes
09:42:14 [anthony]
... but it wasn't meant for 1.1
09:42:29 [anthony]
DS: We're not talking about 1.1
09:42:36 [anthony]
... we are talking about SVGA
09:43:05 [anthony]
PD: Here is where my mind is cloudy, the question is one animation model more powerful than an other
09:43:13 [ed]
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)
09:43:20 [anthony]
... SMIL is more powerful than CSSA
09:43:23 [anthony]
DS: In some ways
09:43:36 [anthony]
PD: But CSSA is more preferred by web develoeprs
09:43:42 [anthony]
.. .because CSS is well known
09:44:02 [anthony]
... CSS doesn't apply to enough things (attributes) where as SMIL does
09:44:10 [anthony]
... I'm caught between so many differences
09:44:27 [anthony]
... is there a single declarative animation system?
09:44:38 [anthony]
... or are we bring them forward together?
09:45:19 [anthony]
DS: Core Animation it is very like SMIL with out time containers and other SMIL components
09:45:40 [anthony]
DJ: The implementation in webkit uses both
09:45:58 [anthony]
... I wouldn't bring Core Animation into the mix
09:46:02 [anthony]
... I think it's worth nothing
09:46:08 [anthony]
... that when Core Animation was starting
09:46:19 [anthony]
... they found the SMIL animation model as a nice model to follow
09:46:26 [anthony]
... and CSS follows it as well
09:46:34 [anthony]
... forget about syntax and the more complex parts
09:46:46 [anthony]
... like syncing time bases
09:46:56 [anthony]
... and it was really easy to describe that model in CSS
09:47:11 [anthony]
... The reason we applied animations in CSS is it made sense at that level
09:47:19 [anthony]
... it was more familiar to web authors
09:47:29 [anthony]
... and there wasn't a clear way to apply animation to HTML
09:47:55 [anthony]
... the problem is that CSS and SVG is that it's not clear what happens when you combine the two
09:48:09 [anthony]
PD: The thing is you have a syntax that is popular
09:48:20 [anthony]
... we get way more compliments on CSSA than we do complaints
09:48:34 [anthony]
... and I don't want to keep adding to CSSA where it's gaining massive adoption
09:48:39 [anthony]
... so there are things we can fix easily
09:48:52 [anthony]
... and SMIL which is also an excellent model to apply to SVG
09:49:02 [anthony]
... it has this legacy where people don't like SMIL
09:50:05 [anthony]
DJ: Patrick raised the issue about what direction we can go in
09:50:26 [anthony]
DS: I think we agree that SVGA and CSSA should both use the same underlaying model
09:50:38 [anthony]
... if that means simplifying the SVGA model
09:50:41 [anthony]
... then so be it
09:50:50 [anthony]
... because you certainly don't want to implement two
09:51:09 [anthony]
... and we want to have a single API that can apply to both
09:51:24 [anthony]
... I think that is actually two fundamental points of agreement
09:51:32 [anthony]
DJ: Yep I agree with that
09:51:46 [anthony]
PD: I think you're right, give me some time
09:53:22 [shepazu]
zakim, drop Saint_Clair_3B
09:53:22 [Zakim]
Team_(svg)09:16Z has ended
09:53:23 [Zakim]
Attendees were
09:53:25 [Zakim]
sorry, shepazu, I don't know what conference this is
10:13:20 [TabAtkinsTPAC]
TabAtkinsTPAC has joined #svg
10:15:05 [anthony]
s/... we get way more compliments on CSSA/DJ: we get way more compliments on CSSA/
10:17:20 [sylvaing]
sylvaing has joined #svg
10:17:35 [dino]
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/
10:17:39 [jun]
jun has joined #svg
10:18:04 [ed]
[back from break]
10:18:58 [shepazu]
zakim, call Saint_Clair_3B
10:18:58 [Zakim]
sorry, shepazu, I don't know what conference this is
10:19:23 [dino]
zakim, room for 3
10:19:23 [Zakim]
I don't understand 'room for 3', dino
10:19:27 [shepazu]
Zakim, room for 3?
10:19:27 [dino]
zakim, room for 3?
10:19:28 [Zakim]
ok, shepazu; conference Team_(svg)10:19Z scheduled with code 26634 (CONF4) for 60 minutes until 1119Z
10:19:30 [Zakim]
dino, an adhoc conference was scheduled here less than 2 minutes ago
10:19:35 [shepazu]
zakim, call Saint_Clair_3B
10:19:35 [Zakim]
ok, shepazu; the call is being made
10:19:36 [Zakim]
Team_(svg)10:19Z has now started
10:19:48 [adrianba]
adrianba has joined #svg
10:21:45 [anthony]
PD: I have the questions figure that I want
10:21:53 [anthony]
... but I'm going to have make them as statements
10:22:05 [anthony]
... SVG is an XML format and it's started that way
10:22:13 [anthony]
... and that's why it's attribute based
10:22:15 [anthony]
... correct?
10:22:17 [anthony]
DS: Yes
10:22:46 [anthony]
PD: And HTML is not? It's a derivative?
10:22:53 [anthony]
DS: HTML is a text document language
10:23:00 [anthony]
... SVG is a language to describe shapes
10:23:12 [anthony]
... it makes more sense for attributes to be attributes
10:23:20 [anthony]
... if SVG wasn't XML
10:23:25 [anthony]
... it would've been similar model
10:23:28 [anthony]
... look at VMLL
10:23:33 [anthony]
s/VMLL/VML/
10:23:41 [glazou]
glazou has joined #svg
10:23:51 [anthony]
PD: One of the things we talked about was, maybe alot of SVG attributes and are presentation
10:24:01 [anthony]
... and should be in CSS and that is not going to happen
10:24:03 [anthony]
... and that is that
10:24:11 [dbaron]
dbaron has joined #svg
10:24:12 [anthony]
... I believe that the biggest use case for SVG going forward
10:24:16 [anthony]
... is in an HTML document
10:24:22 [anthony]
DS: I think that is arguably correct
10:24:30 [anthony]
PD: Then it falls in to web developers hands
10:24:36 [anthony]
... and we want them to adopt it
10:24:51 [anthony]
DS: Of course we want them to adopt it
10:25:11 [anthony]
PD: They are experienced with document content, CSS and script
10:25:20 [anthony]
DS: I want to illustrate some differences
10:25:23 [anthony]
.. between HTML and SVG
10:25:38 [anthony]
... if you look at those elements in SVG that are not for marking up text
10:25:41 [anthony]
... such as form
10:25:43 [anthony]
... stuff
10:25:49 [anthony]
... they are heavily attribute beased
10:25:58 [anthony]
... I think similar design choices were made for SVG
10:26:05 [anthony]
... the radius of a circle is presentation
10:26:16 [anthony]
... it's the actually circle
10:26:22 [anthony]
... Path
10:26:28 [anthony]
.. .the geometry of the path is the path
10:26:42 [anthony]
... it's not a presentation of the path
10:26:52 [anthony]
... CSS makes more sense for HTML than it does in SVG
10:27:17 [anthony]
... Let me rephrase that SMIL makes less sense for HTML than it does for SVG
10:27:27 [anthony]
... where as CSS animation makes sense for both
10:27:44 [anthony]
PD: Are we saying there is a presentation technology for non-presentation and for presentation technology
10:27:55 [anthony]
DS: Almost. Having one animation technology that works for both
10:28:00 [anthony]
... makes perfect sense
10:28:08 [anthony]
... but that metric may not make sense for HTML
10:28:40 [anthony]
PD: So you don't want to have multiple animation models
10:28:52 [anthony]
... but you are ok with multiple animation syntaxes
10:29:14 [anthony]
DS: I'm ok with CSSA being able to animate the radius of a circle
10:29:27 [anthony]
PD: In an ideal world we'd have model and one syntax
10:29:32 [anthony]
DS: I'm not yet convinced
10:30:04 [anthony]
AG: I think you'd what both
10:30:14 [anthony]
DS: For chaining animations, you'd want both
10:30:36 [anthony]
... the element syntax is element is better for CSS syntax for somethings
10:30:56 [anthony]
DJ: SVGA is an element in the DOM and CSSA is not
10:31:09 [anthony]
... there is no way to get a reference to the CSS object
10:31:14 [TabAtkinsTPAC]
Yet.
10:31:52 [anthony]
AG: I have written SVG script that modifies the animation in the DOM
10:31:58 [anthony]
DJ: T\his is something in SVGA that is currently supported in CSSA
10:32:07 [anthony]
... in an ideal world it would be great to have one syntax
10:32:16 [anthony]
... but I don't think two is necessarily bad
10:32:31 [anthony]
... CSSA may fit better when creating a document
10:32:47 [anthony]
... but SVGA may be good for generated content
10:32:55 [glazou]
+1 TabAtkinsTPAC
10:34:40 [TabAtkinsTPAC]
That... is all of it? I'm not in the room.
10:34:44 [Liam]
Liam has joined #svg
10:35:07 [TabAtkinsTPAC]
Oh!
10:35:17 [TabAtkinsTPAC]
TabAtkinsTPAC: believes a third syntax, specialized for creating and running animations purely in JS, is desirable as well.
10:35:28 [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);"
10:35:45 [anthony]
PD: Elements and attributes aside is it reasonable to predict that CSSA features will be on par with what SMIL does in SVG?
10:35:48 [anthony]
DS: Dino?
10:35:57 [anthony]
DJ: It is definitely realistic
10:36:10 [anthony]
... It would be possible to get to same level of functionality
10:36:22 [anthony]
... it's just not wanting to keep adding to a sped that's in development
10:36:32 [shepazu]
s/sped/spec/
10:36:39 [anthony]
... it's a point where it's almost getting out of control of what the working group wants to do with it
10:37:01 [anthony]
... Adobe are now demonstrating tools that convert Flash to CSSA
10:37:33 [anthony]
... I see comments that ability to chain animations
10:37:41 [anthony]
... have one animation start at the end of another one
10:37:50 [anthony]
... which would be easy to add and implement
10:38:25 [anthony]
... I dunno how much we want to change CSSA until we get some base level
10:38:49 [anthony]
DS: High level comment - I really want Adobe to start attending these telcons. From Dreamweaver or Flash
10:38:59 [anthony]
... it's hard to guess what they're intentions are
10:39:30 [anthony]
DB: There has been some discussion if you have the same feature sets
10:39:33 [anthony]
... and the same model
10:40:07 [anthony]
PD: I would love for Apple to attend these telcons more frequently
10:40:15 [anthony]
DB: and my understanding is that some of the model is substantially different
10:40:32 [anthony]
... I don't know how unified you want the model to be
10:40:52 [Liam]
Liam has joined #svg
10:41:05 [anthony]
DS: Dino is saying that the models can be completely unified
10:41:13 [anthony]
DJ: I'm not a CSS expert
10:41:20 [anthony]
... but as far as animations go
10:41:28 [Hyeonsoo]
y
10:41:31 [anthony]
... then yes
10:41:47 [anthony]
DB: I thought mostly about transitions and how they interact with SMIL
10:42:01 [anthony]
DS: I have to confess that I have not looked much at transitions
10:42:13 [anthony]
... as I understood it they were CSSA country cousin
10:42:27 [anthony]
DB: Because of their model they have to fit in a specific place
10:42:47 [anthony]
... and animations to a degree is built on top of transitions
10:42:51 [hidetaka]
hidetaka has joined #svg
10:43:01 [anthony]
DJ: That might be just a fall over
10:43:10 [anthony]
... that as a implementer that they are really the same implementation
10:43:23 [anthony]
... but I think they are fairly separate
10:43:40 [anthony]
DB: The way I read it was you declare points and force how to transition between the points
10:43:52 [anthony]
DJ: I would say that animations would apply on what the current style is
10:44:02 [anthony]
... at the code level it's the other way aroud
10:44:07 [anthony]
s/aroud/around/
10:44:20 [anthony]
DJ: Transitions happen when the current style changes
10:44:26 [anthony]
... Animations trump that
10:44:34 [anthony]
... and will always compute the final style
10:45:24 [anthony]
DS: Patrick you started this session by saying you know the questions you wanted to ask
10:45:52 [anthony]
PD: If the use cases and scenarios are the same for HTML and SVG and I'll give one particular scenario which started before
10:46:00 [anthony]
... which is an advertisement
10:46:09 [anthony]
... if the scenario is the same and the developer is the same
10:46:22 [anthony]
... why shouldn't the syntax and the underlying model should be same
10:46:45 [anthony]
DS: I think that if the same functionality is going to be same; if they cover the same things
10:47:01 [anthony]
... I think it makes sense for the same developer use the same syntax
10:47:08 [anthony]
... and that syntax is the CSS syntax
10:47:42 [anthony]
PD: How do you make the syntax the same when SVG is attribute based
10:48:14 [anthony]
DS: I perfectly ok with CSS animating SVG attributes in some way
10:48:21 [anthony]
... even though they are attributes they can still be animated
10:48:38 [anthony]
... and this new API (similar to traits maybe) the way of getting the animated value
10:48:49 [anthony]
... access is both equally
10:49:28 [TabAtkinsTPAC]
TabAtkinsTPAC is also fine with CSS animating attributes. I'd prefer it, actually, to be available more widely than SVG.
10:49:29 [anthony]
SG: In orders to use animations those attributes become properties in the sytle sheet
10:49:38 [anthony]
s/sytle/style/
10:49:49 [anthony]
PD: Isnt' there is alternative way?
10:49:51 [anthony]
SG: No
10:50:09 [anthony]
PD: Lets't take the case where there is an attribute that has a corresponding property
10:50:39 [anthony]
... and if you set a style sheet with rect and a width=100 and the style sheet has a width=50
10:50:43 [anthony]
... how do you solve that case
10:50:49 [anthony]
.. how do you solve the 'd' case
10:50:57 [dino]
it's ugly, but you could do something like -svg-rx: 10px;
10:51:30 [anthony]
DJ: One suggestion is you put some kind of namespace on properties that come from SVG
10:51:37 [anthony]
... maybe you don't allow them as property names
10:51:42 [anthony]
... in that they can't be set in animations
10:51:47 [pdengler]
pdengler: would you consider attrib-rx: 10px
10:52:05 [anthony]
s/set in animations/set in CSS/
10:52:09 [anthony]
... but are able to be animated
10:52:33 [anthony]
DB: From a CSS perspective you'll pay most of the cost of making them properties
10:52:46 [anthony]
DS: I have no problems with making them properties
10:53:13 [anthony]
... we need to check to see if it makes sense to make them in to CSS
10:53:37 [TabAtkinsTPAC]
TabAtkinsTPAC reiterates that he's in favor of animating arbitrary DOM properties.
10:54:34 [anthony]
AG: I don't care what model we use, but as long as the animation lives in the DOM
10:54:47 [anthony]
... so agree with Tab
10:55:28 [anthony]
PD: When we animate opacity with CSSA it affects the DOM
10:55:33 [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
10:56:08 [TabAtkinsTPAC]
TabAtkinsTPAC: Yes, animating offsetWidth is what I'm talking about. And arbitrary attributes on elements.
10:56:15 [anthony]
DS: It is likely that people will use both
10:56:25 [anthony]
PD: I don't think they'll use both
10:56:27 [dbaron]
I'm curious what "affects the DOM" means above
10:56:40 [glazou]
glazou has left #svg
10:57:02 [sylvaing]
except offsetWidth is read-only so it makes no sense really
10:57:06 [anthony]
DS: I'm saying that in my idea of the unified model, that SVGA can be done with element syntax
10:57:16 [anthony]
PD: I'm not saying kill that off
10:57:31 [anthony]
... but I don't know what the issue is
10:57:48 [anthony]
DS: Chris has claimed that the CSS WG is against taking on a bunch of properties
10:58:01 [anthony]
DB: Some people don't want more and more properties
10:58:09 [anthony]
SG: But it still happens anyway
10:58:19 [anthony]
PD: If you want more functionality...
10:58:21 [TabAtkinsTPAC]
TabAtkinsTPAC: sylvain, argh, you're right. Sorry. Properties that are writeable.
10:58:55 [anthony]
DB: Would want to Homecome in on this discussion
10:58:59 [sylvaing]
tab, sure but aren't the ones of most interest to authors style properties
10:59:11 [dbaron]
s/Homecome/Håkon/
10:59:29 [anthony]
PD: There is at least an underlying model for SVGA and CSSA
10:59:40 [anthony]
... and there are developers who will not deprecate SVGA
10:59:57 [anthony]
... and if we can allow CSSA to do more with SVG
11:00:25 [anthony]
ED: What do you include in the underlying model?
11:01:39 [anthony]
DS: same underlaying data model
11:01:43 [anthony]
... same functionality'
11:01:51 [anthony]
... share data model
11:02:08 [anthony]
... when you change it in SVGA it is exactly the same if you changed it with CSSA
11:02:13 [anthony]
... they have the same effect
11:02:18 [anthony]
... accessed through the same API
11:02:25 [anthony]
... and they have the same value
11:02:40 [anthony]
... however that proposal is managed
11:02:53 [anthony]
DB: What's separate from computed style?
11:03:29 [anthony]
DS: I think we can agree we want the same underlying feature set
11:03:59 [anthony]
... and data model
11:04:47 [anthony]
SG: We can resolve to have a proposal based on that
11:05:16 [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.
11:06:24 [TabAtkinsTPAC]
TabAtkinsTPAC: It's probably okay if that's only possible via the js api.
11:06:27 [anthony]
RESOLUTION: To have a proposal to have the same shared data model and functionality across SVGA and CSSA
11:07:35 [anthony]
ACTION: Dino to Work with PatrickD on drafting up a proposal for the same shared data model and functionality across SVGA and CSSA
11:07:35 [trackbot]
Sorry, couldn't find user - Dino
11:07:54 [anthony]
ACTION: Dean to Work with PatrickD on drafting up a proposal for the same shared data model and functionality across SVGA and CSSA
11:07:54 [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].
11:11:44 [anthony]
DS: My suggestion is that based on conversations with Dion is that the CSS OM is not necessarily the most efficient way of handling the animations
11:11:53 [anthony]
... and we would want an API to inspect the data model
11:11:55 [dino]
s/Dion/Dean/
11:12:20 [anthony]
ED: Inspecting the data model and not just the values would be useful
11:12:26 [TabAtkinsTPAC]
TabAtkinsTPAC: CSSOM, as currently exists, is the suckiest way to handle the data model. Its only virtue is that it exists.
11:12:48 [dino]
Dean: I agree with Tab.
11:13:00 [anthony]
AG: +1 with what Tab said
11:13:15 [anthony]
DS: As part of the effort going forward we would like to define this API
11:13:21 [ed]
s/model and not just the values would be useful/model and not just the animated (presentational) values would be useful/
11:13:27 [anthony]
PD: In terms of what Dino is going to write up
11:13:35 [anthony]
... one of the things I want to stress
11:13:49 [anthony]
... we need to keep this channel open with the CSS Working Group
11:13:49 [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.
11:14:55 [anthony]
DS: It's a separate discussion, but it's my hope as well
11:15:00 [anthony]
ED: It is a separate discussion
11:16:06 [anthony]
JF: I think we should have someone from Adobe to discuss the interface
11:16:15 [anthony]
DS: I think you're absolutely right
11:16:27 [anthony]
DB: You're talking about an API to trigger one animation to the other
11:16:37 [anthony]
DS: A way to access the current state of animations
11:17:00 [anthony]
DB: So one way was to animate from one value to another, and the other
11:17:14 [anthony]
... is an API to give the page a notifications a time that it should update stuff
11:17:50 [anthony]
... to give pages the ability to animate that can't be done declaratively
11:18:29 [anthony]
... Just giving the browser the ability to update the frame rate
11:18:38 [anthony]
... it's just exposing a small part of the animation model
11:19:02 [anthony]
DS: I think that every body agrees here authors would love to have a better animation model
11:19:18 [dbaron]
http://hacks.mozilla.org/2010/08/more-efficient-javascript-animations-with-mozrequestanimationframe/
11:19:34 [anthony]
DS: If you want to bring the experiment to the group that would be great
11:21:06 [anthony]
DJ: When we start writing up the model, we can propose the API
11:23:37 [Zakim]
Team_(svg)10:19Z has ended
11:23:38 [Zakim]
Attendees were
11:24:00 [ed]
<set attributeName="lunch" to="break" dur="1.5h" begin="0s"/>
11:24:39 [anthony]
anthony has left #svg
11:27:56 [myakura]
rrsagent, make minutes
11:27:56 [RRSAgent]
I have made the request to generate http://www.w3.org/2010/11/04-svg-minutes.html myakura
12:02:01 [myakura]
myakura has joined #svg
12:24:53 [jun]
jun has joined #svg
12:41:18 [myakura]
myakura has joined #svg
12:41:47 [adrianba]
adrianba has joined #svg
12:48:33 [sylvaing]
sylvaing has joined #svg
12:49:22 [pdengler]
pdengler has joined #svg
12:53:22 [kohei_]
kohei_ has joined #svg
12:57:50 [shepazu]
shepazu has joined #svg
13:00:35 [dbaron]
dbaron has joined #svg
13:01:48 [anthony]
anthony has joined #svg
13:01:51 [pdengler]
scribeNick: pdengler
13:03:18 [smfr]
smfr has joined #svg
13:03:41 [smfr]
RRSAgent: pointer
13:03:41 [RRSAgent]
See http://www.w3.org/2010/11/04-svg-irc#T13-03-41
13:03:45 [kennyluck]
kennyluck has joined #svg
13:03:51 [ed]
[back from lunchbreak]
13:04:04 [plinss_]
plinss_ has joined #svg
13:04:06 [pdengler]
topic: SVG Transforms
13:04:41 [johnjan]
johnjan has joined #svg
13:06:34 [pdengler]
pdengler has joined #svg
13:07:23 [anthony]
http://dev.w3.org/Graphics-FX/modules/2D-transforms/spec/2DTransforms.html
13:07:39 [homata]
homata has joined #svg
13:07:47 [smfr]
what's the call-in number?
13:08:34 [shepazu]
Zakim, room for 3?
13:08:36 [Zakim]
ok, shepazu; conference Team_(svg)13:08Z scheduled with code 26635 (CONF5) for 60 minutes until 1408Z
13:08:49 [TabAtkinsTPAC]
TabAtkinsTPAC has joined #svg
13:08:59 [shepazu]
Zakim, call Saint_Clair_3B
13:08:59 [Zakim]
ok, shepazu; the call is being made
13:09:00 [Zakim]
Team_(svg)13:08Z has now started
13:09:19 [dsinger]
dsinger has joined #svg
13:10:08 [shepazu]
RRSAgent, make minutes
13:10:08 [RRSAgent]
I have made the request to generate http://www.w3.org/2010/11/04-svg-minutes.html shepazu
13:10:25 [hidetaka]
hidetaka has joined #svg
13:10:36 [pdengler]
summary of previous discussion on animations
13:11:01 [jfkthame]
jfkthame has joined #svg
13:11:24 [pdengler]
resolved that we want to use the same model for data, API and feature set across CSSA and SVGA
13:11:49 [pdengler]
shepazu: This is to make sure we are only implementing 1 animation model.
13:12:39 [ed]
http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0043.html
13:13:17 [pdengler]
return to topic on transforms
13:13:26 [pdengler]
topic: transforms across SVG and CSS
13:13:57 [pdengler]
anthony: I've been working on the CSS 2d Trasnforms and SVG transforms that are relevant have been merged into 1 spec
13:13:57 [anthony]
http://dev.w3.org/Graphics-FX/modules/2D-transforms/spec/2DTransforms.html
13:14:30 [pdengler]
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
13:15:04 [smfr]
yep
13:15:15 [pdengler]
smfr: On Monday the CSS Working group resolved to move 2d Transforms forward, and the section on animation moved to the transitions spec
13:15:39 [pdengler]
anthony: I'd like to work on a single spec that both groups can use
13:15:49 [dsinger]
dsinger has joined #svg
13:16:12 [pdengler]
chrisl: Sounds like you've done a lot of work; we thought we had agreed to move it to FX for that purpose
13:16:30 [pdengler]
anthony: The idea was to use this spec for SVG 2.0 for the transforms chapter
13:16:42 [pdengler]
anthony: I'm also happy to commit to helping with tests for that as well
13:17:02 [pdengler]
smfr: We have to figure out how the spec gets published
13:17:36 [pdengler]
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
13:18:00 [pdengler]
chrisl: Since they are done in parallel, it usually only takes a week
13:18:30 [pdengler]
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
13:18:34 [ChrisL]
ChrisL has joined #svg
13:19:26 [Liam]
Liam has joined #svg
13:20:17 [pdengler]
smfr: With a combined specification, the two languages means that there is additional complexites as certain functions only apply to certain languages
13:21:03 [pdengler]
anthony: There are areas in the spec where I had to change some wording that does have to take into account CSS and SVG.
13:22:40 [pdengler]
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
13:23:41 [pdengler]
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
13:23:41 [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].
13:24:12 [pdengler]
pdengler: corretino :SVG Transform Attribute
13:24:19 [dbaron]
dbaron has joined #svg
13:24:44 [anthony]
s/correctino :/correction: /
13:24:53 [smfr]
could dbaron approach the phone?
13:24:57 [pdengler]
dbaron: What we decided to move the section on animations from the transforms into the transition spec
13:25:13 [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/
13:25:44 [cslye]
cslye has joined #svg
13:26:05 [pdengler]
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
13:26:26 [dbaron]
Also there are two references to FX that say XF by mistake.
13:26:58 [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
13:27:38 [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
13:27:49 [ChrisL]
... so existing content does not break
13:28:11 [pdengler]
shepazu: We talked before about having different defaults for CSS and SVG with regards to transform orgin
13:28:31 [johnjan]
s/ defsult/ default
13:28:39 [pdengler]
shepazu: It should have the same default when styled with CSS
13:29:26 [r12a]
r12a has joined #svg
13:29:52 [pdengler]
pdengler: Then we should only have to worry abou the unit type (def) and then support the more granular API's
13:30:14 [pdengler]
shepazu: There is an issue of being able to get any particular point of a transformed element and the reverse
13:30:38 [pdengler]
smfr: The CSS workking group at this point doesn't want any script API in the spec
13:30:46 [pdengler]
dbaron: I don't think there is an objection there.
13:31:04 [pdengler]
dbaron: We have four browser implementation of the transforms spec, and not hold it up for additions
13:31:33 [pdengler]
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
13:31:50 [pdengler]
dbaron: What's the signature of the method?
13:32:20 [pdengler]
smfr: In webkit we have a method on the Window object convertPointFromNode and convertPointToNode
13:32:41 [pdengler]
smfr: Folks were resistant to putting new methods on elements, but on the window it wasn't as much of an issue
13:32:52 [pdengler]
dbaron: You could also have an API that converted from one node to another
13:33:19 [pdengler]
smfr: In the CSS working group, was there an objection to having the jscript API .....
13:33:24 [smfr]
dbaron: was the objection to dependencies on CSSValues primarily?
13:33:45 [plinss_lyon]
plinss_lyon has joined #svg
13:33:51 [pdengler]
dbaron: There were two objects. There was only one impelmentation of the API, and that we didn't want a new API on CSSValues
13:34:29 [pdengler]
smfr: The other issue is that in the CSS spec we have the Matrix API and 2d vs 3d
13:35:10 [pdengler]
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
13:35:35 [pdengler]
smfr: Trying to remember if the multiply is backward on one of them
13:35:49 [smfr]
multLeft vs multRight
13:35:50 [pdengler]
anthony: We should examine this very soon and sort them out
13:36:06 [pdengler]
shepazu: I think we would be doing a disservice by not putting this in
13:36:45 [pdengler]
smfr: how do we get a spec that we can move forward on
13:36:56 [pdengler]
anthony: Resolving the issues with the API is necessary
13:37:08 [pdengler]
shepazu: Who had concerns about the script aspects of the API
13:37:20 [pdengler]
dbaron: That part of the CSS object model in genereal didn't want additions
13:38:11 [pdengler]
sylvaing: For authors to manipulate portions of the transform without having to parse strings
13:39:07 [pdengler]
smfr: we need to make sure that the matrix is the same, row major vs. column major
13:39:26 [pdengler]
shepazu: Why would there have been an incompatability in the first place
13:39:57 [pdengler]
anthony: SVG did it one way, CSS did it another.
13:40:05 [pdengler]
shepazu: Could we change the way that CSS is done?
13:40:16 [pdengler]
dbaron: It doesn't get exprssed in an API
13:40:43 [pdengler]
shepazu: Is it too late to change it?
13:41:00 [pdengler]
smfr: We should hold off on deciding on anything until I look into it
13:41:31 [pdengler]
shepazu: We should also include the point transformation in the spec regardless of the matrix
13:41:54 [manyoung]
manyoung has joined #svg
13:43:40 [pdengler]
dbaron: Coordinate system transforms is important across the board
13:43:48 [dbaron]
(not just for transforms)
13:44:55 [dbaron]
(I guess I don't have strong feelings about one spec or two.)
13:45:15 [pdengler]
RESOLUTION: Include the transform to point API in the Transform spec
13:45:27 [smfr]
go Zakim
13:45:31 [ChrisL]
zakim, get a clue
13:45:31 [Zakim]
I don't understand 'get a clue', ChrisL
13:46:10 [shepazu]
Zakim, who is here?
13:46:10 [Zakim]
On the phone I see no one
13:46:12 [Zakim]
On IRC I see plinss_lyon, r12a, cslye, dbaron, Liam, ChrisL, dsinger, jfkthame, hidetaka, TabAtkinsTPAC, homata, pdengler, johnjan, kennyluck, smfr, anthony, shepazu, kohei_,
13:46:14 [Zakim]
... sylvaing, adrianba, jun, fantasai, anthony_work, RRSAgent, karl, ed, trackbot, heycam, Zakim
13:46:19 [pdengler]
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
13:46:32 [pdengler]
ed: Will it supercede the CSS spec, or just become one
13:46:54 [pdengler]
ChrisL: If the later edits are in both specs, we should just merge into one
13:47:24 [pdengler]
anthony: We need the CSS working group to accept this
13:47:51 [smfr]
now i can
13:50:03 [hidetaka_]
hidetaka_ has joined #svg
13:50:12 [pdengler]
fantasai: Each time the FX has a resolution it should be added as an agenda item for each WG
13:50:26 [pdengler]
shepazu: This is a separate topic
13:51:36 [pdengler]
shepazu: It is our understanding that these are joint deliverables. The SVG WG doesn' t need a separate reslution as we all attend
13:52:01 [pdengler]
shepazu: We didn't take into account the size or the way the CSS working group exeucutes. Does CSS needs a seperate CSS resolution?
13:52:35 [smfr]
pdengler: can you minute?
13:52:40 [pdengler]
plinss_lyon: Yes, we should make sure we are clear about ownership and terms to avoid confusion about procedure
13:52:57 [pdengler]
anthony: I wasn't implying anything
13:53:21 [pdengler]
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
13:53:54 [pdengler]
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
13:54:13 [smfr]
dbaron: thanks
13:54:24 [pdengler]
chrisl: That could happen on Wendesday
13:55:19 [pdengler]
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
13:57:04 [Liam]
Liam has joined #svg
13:59:19 [pdengler]
anthony: I have enough work to do to finish this off and work with simon to do so
13:59:50 [pdengler]
shepazu: This general process applies across the FX task force so we don't have to resolve this again for filters, trasnforms, animations, etc
14:00:33 [pdengler]
topic: filters
14:00:45 [ed]
http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html
14:01:12 [pdengler]
ed: Above is the proposal for filters, mask and clip path from Mozilla
14:01:42 [pdengler]
ed: This is a proposal at this point. I have an action item to move it into the FX spec
14:02:00 [anthony]
pdengler: I was just impressed by what was done here
14:02:04 [anthony]
... and I want to move it quicker
14:02:13 [anthony]
... want to get it to the same spot as transforms
14:02:26 [anthony]
... I had seen the implementation but hadn't read this
14:02:41 [anthony]
... The only thing that has potential to make improvements to the model
14:02:49 [anthony]
... does it make sense to have things cascade
14:02:58 [anthony]
... what I saw the implementation doing
14:03:02 [anthony]
... was using the defs
14:03:08 [anthony]
.. and using it as a style
14:03:17 [anthony]
... was that an issue with doing that in HTML?
14:03:26 [anthony]
... All in one file
14:03:37 [anthony]
chrisL: In that case you'll get the cascading
14:03:42 [anthony]
... if you apply something in HTML
14:03:49 [anthony]
... it will inhert to SVG
14:03:57 [anthony]
pdengler: If I want a filter to just apply to HTML
14:04:06 [anthony]
shepazu: use name spaces
14:04:15 [anthony]
pdengler: If I want to apply a filter just to HTML
14:04:22 [anthony]
... I can't do that with just the SVG filters today
14:04:39 [anthony]
chrisL: You mean that I have just a HTML document I want to apply SVG filters?
14:05:12 [anthony]
... In HTML you can have another file in the side and it can be referenced
14:05:21 [anthony]
shepazu: I think he's asking where it is defined
14:05:29 [anthony]
... Yes you can
14:05:39 [anthony]
... there is another thing called Canned Effects
14:05:47 [anthony]
pdengler: There is a Canned Effects
14:05:54 [anthony]
... and do they apply to SVG
14:06:25 [anthony]
chrisL: Don't need to put it in <defs>
14:06:31 [ed]
you can also use datauri:s for putting the filter into the stylesheet
14:06:31 [anthony]
pdengler: Need to have the SVG in there
14:06:38 [anthony]
... in order to apply the filter to HTML
14:06:43 [anthony]
shepazu: Hang on
14:06:57 [anthony]
... [draws example on the board]
14:07:08 [smfr]
you could also invent a syntax to refer to a filter in an external file: filter: url(foo.svg#bar)
14:07:29 [ed]
smfr: that's already possible
14:07:34 [ChrisL]
ChrisL has joined #svg
14:07:42 [smfr]
s/invent a/use the :)
14:07:42 [dbaron]
smfr, it's the normal way, even...
14:07:47 [ChrisL]
rrsagent, here
14:07:47 [RRSAgent]
See http://www.w3.org/2010/11/04-svg-irc#T14-07-47
14:08:19 [anthony]
pdengler: They continue to be and are SVG filters?
14:08:25 [anthony]
shepazu: Yes
14:08:41 [anthony]
pdengler: So they are SVG
14:08:58 [anthony]
dbaron: I think at one point we'd want an alternative syntax
14:09:00 [anthony]
... for CSS
14:09:01 [smfr]
i heard *other than canned effects*, right?
14:09:59 [anthony]
dbaron: One thing we'll want is more input primitives
14:10:10 [anthony]
... e.g. other sources
14:10:48 [anthony]
... in addition to sourceBackground, sourceGraphics
14:11:45 [pdengler]
shepazu: There shouldn't be any 'canned effect' that could not be composed
14:12:06 [ed]
s/composed/decomposed/
14:12:25 [pdengler]
dbaron: For CSS you might be able to seperately apply filters to border, background and different portions of the box model
14:12:45 [dbaron]
and the contents
14:12:47 [pdengler]
shepazu: We are all interested in expanding filters in intereting new ways
14:13:21 [pdengler]
fantasai: We made a list of interesting things to filter: background, border, contents and the composites
14:13:32 [pdengler]
dbaron: You can achieve the composites with SVG Filters
14:13:54 [pdengler]
fantasai: We coudl just start with background
14:14:14 [pdengler]
s/coudl/could/
14:14:19 [smfr]
+q
14:15:14 [pdengler]
ed: Should they go into the same specification?
14:16:06 [dbaron]
ack smfr
14:16:29 [pdengler]
smfr: Can we agree that we are going to use the filter property in CSS. The problem being microsoft using <filter>
14:16:36 [smfr]
example of filter:
14:16:37 [smfr]
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(
14:16:37 [smfr]
src='images/transparent-border.png',
14:16:37 [smfr]
sizingMethod='scale');
14:17:24 [cslye]
cslye has joined #svg
14:17:38 [pdengler]
chrisl: There is a problem with sites using <filter> is using to detect IE
14:18:01 [pdengler]
sylvaing: We don't support this long term, but people use these today
14:18:43 [pdengler]
sylvaing: We can allow for the use of the standards <filter> in standards mode support
14:19:07 [smfr]
do the MS filters always start with "progid"?
14:20:04 [pdengler]
ChrisL: The standard filter property is quite distinct and easy to recognize.
14:20:14 [pdengler]
shepazu: We should an informative note in filters specification
14:20:26 [smfr]
can we resolve to use the "filter" CSS property?
14:20:59 [pdengler]
action: ed to add informative note about how to handle MS <filter> from before
14:20:59 [trackbot]
Created ACTION-2892 - Add informative note about how to handle MS <filter> from before [on Erik Dahlström - due 2010-11-11].
14:21:32 [pdengler]
topic: MS Filters that aren't supported
14:21:39 [pdengler]
ChrisL: There is opacity
14:22:41 [pdengler]
sylvaing: MSFT already has opacity always wins
14:24:41 [pdengler]
action: pdengler to submit new filter effects proposals
14:24:41 [trackbot]
Created ACTION-2893 - Submit new filter effects proposals [on Patrick Dengler - due 2010-11-11].
14:25:27 [pdengler]
pdengler: There were two models we were thinking of. Introducing new primitives, or opening an extensibility model
14:26:26 [pdengler]
shepazu: Are they relatively expensive to implement?
14:26:48 [pdengler]
shepazu: It could also take a while to get them right, which makes it useful to have an extensibility model
14:27:17 [pdengler]
ChrisL: This is where you need a good authoring tool
14:27:53 [smfr]
someone could write a webapp for this
14:28:39 [ChrisL]
someone could indeed
14:29:17 [pdengler]
TabAtkinsTPAC: In terms of CSS, gradients are going to change from the current draft
14:29:22 [pdengler]
topic: Gradients
14:29:40 [pdengler]
TabAtkinsTPAC: For linears, we will move to a scheme that are easier to interpolate
14:30:00 [pdengler]
TabAtkinsTPAC: There are currently two different modes for interopolating that rely on two different sources
14:30:49 [pdengler]
TabAtkinsTPAC: SVG Radial gradients are completely different
14:31:15 [pdengler]
anthony: You cannot do conical graidents in SVG
14:31:23 [pdengler]
TabAtkinsTPAC: You cannot do conical in CSS either
14:31:44 [pdengler]
TabAtkinsTPAC: A proposal was made to do linears the same as SVG. It seems sort of confusing.
14:32:23 [pdengler]
TabAtkinsTPAC: I have another proposal to solve the interopolation issues. I need to sit down with simon
14:32:34 [pdengler]
anthony: You are not happy then with boundingBox proposal
14:32:57 [pdengler]
TabAtkinsTPAC: I think that's wierd and unexpected
14:33:19 [pdengler]
anthony: (drawing)
14:34:18 [pdengler]
gradients in CSS are not skewed
14:34:26 [pdengler]
shepazu: Adopting CSS gradients is fine with me
14:34:47 [pdengler]
shepazu: I would like a way to specificy SVG Gradients...I would just like there to be more similarities
14:35:05 [pdengler]
shepazu: Starting from different points seems wrong
14:35:42 [pdengler]
TabAtkinsTPAC: Adopting the SVG model doesn't solve the interpolation; you cannot support intermediate forms.
14:35:57 [pdengler]
ChrisL: Sounds like you have only looked at bbox and not userspaceonuse
14:36:42 [pdengler]
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.
14:36:55 [pdengler]
anthony: Are you talking about transitions?
14:37:10 [pdengler]
TabAtkinsTPAC : Yes, I should be able to transition from one to the other
14:37:46 [pdengler]
dbaron: There is sitll mutiple possibilities. Its still not clear if you are transitioning the entire gradient line or stops
14:38:06 [pdengler]
anthony: The stops need to be realigned according to the vector you are transforming
14:38:48 [pdengler]
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
14:39:08 [pdengler]
dbaron: One alternative is to animate the end points, and then the color irrespective of where the stops happen to be
14:39:26 [pdengler]
dbaron: Or you could animate the color to the new color. They are different effects.
14:39:51 [pdengler]
anthony: Would it make it sense then to only animate graidents with the same amount of stops
14:40:07 [pdengler]
TabAtkinsTPAC: how does SVG animate gradients
14:40:31 [pdengler]
chrisl: you animate at a more granular level. The developer puts together the transition themselves.
14:41:25 [pdengler]
TabAtkinsTPAC: You want to avoid step transitions. It's not obvious that they bbox and userspace are different things
14:41:46 [pdengler]
anthony: Is there any reason why CSS gradients are going down this path as opposed to the SVG model.
14:42:19 [pdengler]
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.
14:42:49 [pdengler]
plinss_lyon: This seems to be a problem with borders
14:42:54 [pdengler]
2 minute break
14:44:30 [Zakim]
Team_(svg)13:08Z has ended
14:44:30 [Zakim]
Attendees were
15:00:44 [freedom]
freedom has joined #svg
15:02:01 [freedom]
freedom has left #svg
15:03:22 [parkjy]
parkjy has joined #svg
15:04:37 [homata]
homata has joined #svg
15:06:49 [hidetaka]
hidetaka has joined #svg
15:10:06 [plinss_lyon]
plinss_lyon has joined #svg
15:10:58 [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
15:10:58 [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].
15:11:36 [pdengler]
shepazu: Is gradients a deliverable of FX or CSS?
15:11:47 [pdengler]
TabAtkinsTPAC: It's CSS
15:12:03 [shepazu]
Zakim, room for 3?
15:12:05 [Zakim]
ok, shepazu; conference Team_(svg)15:12Z scheduled with code 26637 (CONF7) for 60 minutes until 1612Z; however, please note that capacity is now overbooked
15:12:40 [Zakim]
Team_(svg)15:12Z has now started
15:12:43 [shepazu]
Zakim, call Saint_Clair_3B
15:12:43 [Zakim]
ok, shepazu; the call is being made
15:13:42 [pdengler]
TabAtkinsTPAC: I'm afraid that gradients are complex enough that the language you express them in makes a difference
15:14:16 [shepazu]
Zakim, call Saint_Clair_3B
15:14:16 [Zakim]
ok, shepazu; the call is being made
15:15:06 [pdengler]
pdengler: Does this mean that if they are fundamentally different the CSS should still apply to SVG
15:15:13 [pdengler]
yes
15:16:11 [pdengler]
tabAtkinsTPAC : Things that can be expressed in CSS cannot be expressed in SVG, because for example, applying a gradient to unknown dimension
15:16:23 [pdengler]
... CSS is a superset of SVG Gradients
15:16:36 [pdengler]
ed: If we have CSS gradients, I would expect to be able to use them in SVG as well
15:16:57 [pdengler]
chrisl: Then its the case of managing conflicts
15:18:33 [pdengler]
tabAtkinsTPAC: A CSS Gradient should act like a paint server
15:18:36 [jfkthame]
jfkthame has joined #svg
15:19:15 [pdengler]
anthony: We've consider coons patches gradients, mesh gradients
15:19:46 [pdengler]
chrisl: (describes these gradients)
15:20:20 [pdengler]
chrisl: These create texture or 3d like effects
15:21:13 [pdengler]
tabAtkinsTPAC: Property need only take an URL from SVG and apply as CSS gradient
15:21:22 [pdengler]
fantasai: Can this be done today?
15:21:38 [pdengler]
chrisl: There should be no reason why it shouldn't. Browsers just need to support it
15:23:18 [pdengler]
maintin CSS gradients for simple cases, and then be able to refer to SVG model for more complex gradients
15:23:46 [pdengler]
fantasai: Just have a separate file then for gradients. I don't see the reason for using @ rules on SVG gradients
15:24:07 [fantasai]
s/on SVG/in CSS/
15:24:24 [ChrisL]
ChrisL has joined #svg
15:24:29 [fantasai]
s/gradients/for complex SVG gradients/
15:25:00 [pdengler]
action: tAtkinsJ to write requirements document on gradients and how they work in HTML as related to SVG
15:25:00 [trackbot]
Sorry, couldn't find user - tAtkinsJ
15:26:35 [pdengler]
action: pdengler follow up on tabAtkins gradient requirement document
15:26:35 [trackbot]
Created ACTION-2895 - Follow up on tabAtkins gradient requirement document [on Patrick Dengler - due 2010-11-11].
15:26:41 [TabAtkinsTPAC]
TabAtkinsTPAC has joined #svg
15:27:23 [pdengler]
topic: embed SVG in an HTML with CSS
15:28:18 [pdengler]
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.
15:29:42 [fantasai]
http://fantasai.inkedblade.net/style/discuss/vertical-text/paper
15:30:40 [pdengler]
fantasai: The problem is SVG says height and width is 100%.
15:31:22 [pdengler]
chrisl: The spec says, that SVG drawns 100% inside the container
15:31:36 [pdengler]
dsinger: But the problem happened earlier when you follow the rules for replaced elements in CSS
15:31:52 [pdengler]
fantasai: Which says look at the width and height of the element
15:32:21 [pdengler]
fantasai: in CSS there are two widths/heights. One is the actualy width/height vs width/heigh attributes.
15:32:34 [pdengler]
chrisl: SVG should give you back the viewbox
15:33:48 [pdengler]
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
15:34:52 [shepazu]
q+
15:35:21 [anthony]
DB: If you say have a viewBox of 100 100
15:35:30 [anthony]
... and width = 4in
15:35:35 [anthony]
... and height = 100%
15:35:42 [anthony]
... so based on what you said earlier
15:35:53 [anthony]
... is a 4 inch by 8 inch box
15:36:10 [anthony]
s/100%/50%/
15:36:33 [anthony]
CL: If you do put in a 50% it says
15:36:37 [anthony]
... give the size you want to draw in
15:36:41 [anthony]
... and I'll use half of that
15:37:05 [anthony]
DB: I still think you should end up with 4 x 8 in that case
15:37:14 [anthony]
CL: I guess it depends on which order you consider the arguments here
15:37:27 [anthony]
... with that you have an aspect ratio
15:37:34 [anthony]
TA: That's what I've specified
15:37:53 [anthony]
... CSS asks do you have the definite width and height
15:38:13 [anthony]
DS: I think there are some pros in the spec about intrinsic dimensions which should be taken out
15:38:18 [fantasai]
http://www.w3.org/TR/SVGTiny12/coords.html#IntrinsicSizing
15:38:23 [anthony]
EE: I think there is some stuff in SVG Tiny 1.2
15:38:27 [anthony]
... that is non normative
15:38:32 [anthony]
.... about htis
15:38:38 [anthony]
s/htis/this/
15:38:55 [anthony]
DS: What authoring tools do now, Illustrator and Inkscape
15:39:12 [anthony]
... they give an intrinsic size for the image
15:39:14 [ed]
http://www.w3.org/TR/SVGTiny12/coords.html#IntrinsicSizing
15:39:35 [anthony]
DS: You tell people to make a scalable image you put in a viewBox
15:39:41 [anthony]
... and make width and height 100%
15:39:51 [anthony]
... people I've talking to say this is conceptually difficult
15:40:05 [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."
15:40:11 [fantasai]
Note the "Note:"
15:40:44 [anthony]
DS: So I've talked to a lot of people about this and I can help them change the doc
15:40:55 [anthony]
... and you start talking about coordinate spaces and they don't understand
15:41:10 [anthony]
CL: I've spoken to people who've come across this as well
15:41:55 [anthony]
... and explained this to them
15:42:22 [anthony]
HL: Is there a document which has best practices for this?
15:42:36 [anthony]
CL: I agree that this is a good thing to thing to have
15:42:40 [anthony]
... but we don't have one
15:43:26 [anthony]
DS: I don't think there is any harm in providing short hand way
15:43:30 [anthony]
... to do something
15:43:40 [anthony]
... here is the particular short hand I think we should add
15:43:56 [anthony]
... we add an attribute that says you can have width and height, scaling
15:44:16 [anthony]
s/scaling/and you have a property scaling/
15:44:44 [anthony]
... that why they don't have to worry about what they've specifiefd
15:44:49 [anthony]
PD: Would that override?
15:44:51 [anthony]
DS: Yes
15:45:12 [anthony]
... I think people have a really hard time understanding the width and height issue
15:46:05 [anthony]
s/width and height issue/difference between ratio and width and height/
15:46:12 [anthony]
... but the default would be take into account the width and height
15:46:32 [anthony]
... and the viewBox
15:49:22 [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
15:49:36 [anthony]
or
15:49:36 [anthony]
http://dev.w3.org/SVG/profiles/1.1F2/master/coords.html
15:50:01 [anthony]
ACTION: Chris to Copy the Intrinsic sizing wording in Tiny 1.2 to Full 1.1 2nd Edition
15:50:01 [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].
15:51:12 [fantasai]
http://test.csswg.org/source/contributors/fantasai/submitted/css2.1/replaced-intrinsic-ratio-001.xht
15:58:14 [dbaron]
dbaron has joined #svg
16:00:48 [mmielke]
mmielke has joined #svg
16:04:59 [anthony]
trackbot end telcon
16:05:09 [anthony]
trackbot, end telcon
16:05:09 [trackbot]
Zakim, list attendees
16:05:09 [Zakim]
As of this point the attendees have been (none)
16:05:10 [trackbot]
RRSAgent, please draft minutes
16:05:10 [RRSAgent]
I have made the request to generate http://www.w3.org/2010/11/04-svg-minutes.html trackbot
16:05:11 [trackbot]
RRSAgent, bye
16:05:11 [RRSAgent]
I see 10 open action items saved in http://www.w3.org/2010/11/04-svg-actions.rdf :
16:05:11 [RRSAgent]
ACTION: pdengler to Communicate base value issue between SMIL and Transitions with CSS Working Group [1]
16:05:11 [RRSAgent]
recorded in http://www.w3.org/2010/11/04-svg-irc#T09-03-58
16:05:11 [RRSAgent]
ACTION: Dino to Work with PatrickD on drafting up a proposal for the same shared data model and functionality across SVGA and CSSA [2]
16:05:11 [RRSAgent]
recorded in http://www.w3.org/2010/11/04-svg-irc#T11-07-35
16:05:11 [RRSAgent]
ACTION: Dean to Work with PatrickD on drafting up a proposal for the same shared data model and functionality across SVGA and CSSA [3]
16:05:11 [RRSAgent]
recorded in http://www.w3.org/2010/11/04-svg-irc#T11-07-54
16:05:11 [RRSAgent]
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 [4]
16:05:11 [RRSAgent]
recorded in http://www.w3.org/2010/11/04-svg-irc#T13-23-41
16:05:11 [RRSAgent]
ACTION: ed to add informative note about how to handle MS <filter> from before [5]
16:05:11 [RRSAgent]
recorded in http://www.w3.org/2010/11/04-svg-irc#T14-20-59
16:05:11 [RRSAgent]
ACTION: pdengler to submit new filter effects proposals [6]
16:05:11 [RRSAgent]
recorded in http://www.w3.org/2010/11/04-svg-irc#T14-24-41
16:05:11 [RRSAgent]
ACTION: ed to move http://www.w3.org/Graphics/SVG/WG/wiki/User_talk:Pdengler to the main wikipage and break it into subpages [7]
16:05:11 [RRSAgent]
recorded in http://www.w3.org/2010/11/04-svg-irc#T15-10-58
16:05:11 [RRSAgent]
ACTION: tAtkinsJ to write requirements document on gradients and how they work in HTML as related to SVG [8]
16:05:11 [RRSAgent]
recorded in http://www.w3.org/2010/11/04-svg-irc#T15-25-00
16:05:11 [RRSAgent]
ACTION: pdengler follow up on tabAtkins gradient requirement document [9]
16:05:11 [RRSAgent]
recorded in http://www.w3.org/2010/11/04-svg-irc#T15-26-35
16:05:11 [RRSAgent]
ACTION: Chris to Copy the Intrinsic sizing wording in Tiny 1.2 to Full 1.1 2nd Edition [10]
16:05:11 [RRSAgent]
recorded in http://www.w3.org/2010/11/04-svg-irc#T15-50-01