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