20:04:08 <RRSAgent> RRSAgent has joined #svg
20:04:08 <RRSAgent> logging to http://www.w3.org/2011/03/02-svg-irc
20:04:10 <trackbot> RRSAgent, make logs public
20:04:12 <trackbot> Zakim, this will be GA_SVGWG
20:04:12 <Zakim> ok, trackbot; I see GA_SVGWG(SVG1)2:30PM scheduled to start 34 minutes ago
20:04:13 <trackbot> Meeting: SVG Working Group Teleconference
20:04:13 <trackbot> Date: 02 March 2011
20:04:33 <heycam> RRSAgent, this meeting spans midnight
20:05:46 <Zakim> GA_SVGWG(SVG1)2:30PM has now started
20:05:53 <Zakim> + +1.649.363.aaaa
20:06:14 <jwatt> jwatt has joined #svg
20:07:02 <birtles> birtles has joined #svg
20:08:16 <shepazu> shepazu has joined #svg
20:08:52 <anthony_nz> anthony_nz has joined #svg
20:10:51 <birtles> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements
20:13:12 <Zakim> +tbah
20:13:33 <birtles> Presentation: http://brian.sol1.net/svg/pres/SVG 2 Animation.html
20:13:43 <birtles> Presentation: http://brian.sol1.net/svg/pres/SVG%202%20Animation.html
20:15:19 <roc> roc has joined #svg
20:29:21 <AD> AD has joined #svg
20:29:40 <heycam> Scribe: Cameron
20:29:44 <heycam> ScribeNick: heycam
20:29:50 <heycam> Topic: overflow auto
20:29:59 <heycam> RO: the spec currently says that overflow:auto should be treated as visible
20:30:04 <heycam> ... that is incorrect
20:30:12 <heycam> ... in non SVG contexts, overflow:auto clips
20:30:17 <heycam> ... scrollbars if necessary, btu always clips
20:30:23 <heycam> ... for consistency, overflow:auto should be interpreted as clipping
20:30:29 <heycam> ... I don't think we should add scrollbars in SVG
20:30:32 <heycam> ... it's a pain
20:30:39 <heycam> ... we don't have that feature currently, don't want to add it now
20:30:46 <heycam> ... so we should make overflow:auto clip to be consistent with HTML
20:30:58 <heycam> ED: are the use cases for HTML and SVG different?
20:31:03 <heycam> ... for us, implementation wise it's cheaper to not clip
20:31:05 <heycam> ... but that's a detail
20:31:09 <heycam> ... in that sense I don't really care
20:31:16 <heycam> ... it makes it easier for people not to clip
20:31:19 <heycam> RO: auto is not the default value
20:31:22 <heycam> ... the default is visible
20:31:31 <heycam> ... so it only affects people who say overflow:auto
20:31:48 <heycam> ... people setting overflow:auto and expecting it to have no effect is unlikely
20:31:51 <heycam> DS: what about scroll?
20:31:59 <heycam> RO: the spec says treat it as hidden
20:32:20 <heycam> ... I'm saying treat overflow: auto, scroll, hidden all the same
20:32:43 <heycam> ... we provide scrollbars on the viewport
20:32:47 <heycam> ... but this is for a non-root element
20:32:50 <heycam> ... the root element is special
20:32:51 <heycam> DS: ah ok
20:33:07 <heycam> RO: css defines that, and we do that for svg
20:33:09 <heycam> ... which makes sense
20:33:13 <heycam> ... this is for non-root SVG elements
20:33:24 <heycam> CM: how does this relate to markers?
20:33:46 <heycam> ED: markers are overflow:hidden by default
20:34:07 <heycam> RO: so that would be totally unaffected
20:34:39 <heycam> ED: we probably need more tests around overflow
20:35:00 <heycam> RO: CSS is reinterpreting overflow as a shorthand for overflow-x and overflow-y
20:35:08 <heycam> ... if one of them is not visible, then the other one is treated as hidden
20:35:13 <heycam> ... so you can't clip in one axis only
20:35:24 <heycam> ... SVG should probably change that, but that's a separate issue
20:35:42 <heycam> ... so we need to add text to say that overflow: auto, hidden and scroll should all clip
20:36:24 <heycam> RESOLUTION: overflow:auto will be treated as hidden
20:38:33 <heycam> Topic: shorthand presentation attributes
20:40:10 <heycam> CM: if overflow becomes a shorthand, then what happens to the overflow="" presentation attribute?
20:40:24 <heycam> ... we have rules to say that we don't have presentation attributes for shorthands
20:40:27 <heycam> ... I think that should change
20:48:38 <heycam> ACTION: Cameron to write a proposal for allowing shorthand presentation attributes
20:48:38 <trackbot> Created ACTION-2992 - Write a proposal for allowing shorthand presentation attributes [on Cameron McCormack - due 2011-03-09].
20:49:23 <anthony_nz> Scribe: Anthony
20:49:27 <anthony_nz> ScribeNick: anthony_nz
20:49:28 <birtles> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements
20:49:54 <birtles> Presentation: http://brian.sol1.net/svg/pres/SVG%202%20Animation.html
20:49:56 <ed> Topic: Animation improvements
20:50:15 <anthony_nz> BB: The presentation is pretty much the same as what's on the wiki
20:50:28 <anthony_nz> ... The topic is "what we are going to do with SMIL"
20:50:33 <anthony_nz> ... want to keep it high level
20:50:43 <anthony_nz> ... and decide on what direction we want to head
20:51:00 <anthony_nz> ... What are we trying to solve with declarative animation?
20:51:14 <anthony_nz> ... The presentation is just to give some background
20:51:19 <anthony_nz> ... for discussion later on
20:51:38 <anthony_nz> ... the question is what we want to do with SMIL: drop it, patch it or something in between
20:52:00 <anthony_nz> ... [goes through presentation]
20:53:41 <anthony_nz> ROC: If you're creating the image from scratch, but if you want to import some other animated image and your tool doesn't understand the JS library that was used
20:53:44 <anthony_nz> ... then you're stuck
20:54:02 <anthony_nz> ... one thing that SMIL gives you is a standard vocabulary
20:54:23 <anthony_nz> BB: The trouble is what tools
20:54:30 <anthony_nz> ... and I don't think that hasn't been realised yet
20:54:38 <anthony_nz> DS: We know we need tools for animation
20:54:44 <anthony_nz> ... and that is going to emerge
20:54:56 <anthony_nz> ... and it is important that we keep the facility in there to keep that interchange
20:55:22 <anthony_nz> ED: Wanted to say something about the first point. There is small possibility to optimise things if you know what's going to happen in the document
20:55:30 <anthony_nz> ... with script it is a bit more difficult
20:55:47 <anthony_nz> ... in animation it is more possible to do some optimisations
20:56:33 <anthony_nz> CM: There is probably still more chances for bridges between JS and animation
20:56:38 <eseidel> eseidel has joined #svg
20:56:51 <anthony_nz> ... have the timing done in the animation but have the values fed by script
20:57:08 <anthony_nz> DS: That actually comes close to defining a script library defined by animation
20:57:25 <anthony_nz> BB: [continues with presentation]
20:58:01 <Zakim> -tbah
20:58:27 <eseidel> eseidel has joined #svg
20:58:28 <Zakim> +tbah
20:59:02 <anthony_nz> DS: One thing that SMIL can't do is get the mouse position. So perform animation based on mouse position
20:59:40 <anthony_nz> ... you frequently want to move something around with the mouse and you want to be able to do that declaratively
20:59:58 <anthony_nz> BB: [Continues with presentation]
21:00:20 <anthony_nz> ... [Slide: But SMIL isn't perfect...]
21:01:07 <anthony_nz> ... [Slide: SMIL is complicated by syncbase timing]
21:02:14 <anthony_nz> ED: Between fragments you mean between separate SVG paths?
21:02:26 <anthony_nz> ... I don't think it's defined in the spec or in CDF
21:02:33 <heycam> s/paths/files/
21:02:51 <ed> s/svg paths/svg fragments/
21:02:57 <anthony_nz> BB: [Slide: SMIL is complicated by syncbase timing contd.]
21:03:28 <anthony_nz> ... [Slide: Remove syncbase timing and replace with time containers]
21:03:55 <anthony_nz> ... [Slide: SMIL 3 time containers - <par>]
21:04:41 <anthony_nz> ... [Slide: SMIL 3 time containers - <excl>]
21:04:55 <anthony_nz> ... [Slide: SMIL 3 time containers - nested contd.]
21:05:08 <anthony_nz> ... [Slide: Wins]
21:05:37 <anthony_nz> DH: What do you mean cancel the group?
21:06:17 <anthony_nz> BB: If you have all these animations grouped together and you end that group then all the children will end as well
21:06:26 <anthony_nz> ... so allows you to cancel that chain which you previously couldn't do
21:06:44 <anthony_nz> ... so that's one of the advantages of having time containers and sync based timing
21:06:54 <anthony_nz> ... [Slide: Challenges]
21:07:04 <anthony_nz> ... [Slide: Challenges contd.]
21:07:47 <anthony_nz> AG: You mean deprecating?
21:08:29 <anthony_nz> BB: Might be a bit harsh, just say somethings don't work with the new containers
21:08:44 <anthony_nz> DS: I basically deprecating, means we recommend don't using this feature
21:09:26 <anthony_nz> BB: One of the issues with sync based timing you need to go through all the events when you do a sync
21:09:57 <anthony_nz> ... we can keep event based timing, because that would allow you to do a lot of the current use cases
21:09:59 <dholbert> s/do a sync/do a seek/
21:10:41 <anthony_nz> DS: If you had them in the same time container, then you'd be guaranteed of syncronisation. I like that you can syncronise multiple resources
21:10:56 <anthony_nz> ... then if event based timing doesn't guarantee that, then I'd be worried
21:12:10 <anthony_nz> BB: You can still syncronise event based timing using a time stamp
21:13:18 <anthony_nz> ED: Another point with sync based thing, is that if you have an SVG image would that impose some restrictions
21:14:22 <anthony_nz> BB: Some complex interactions would not be supported
21:14:35 <anthony_nz> ... where two different elements can trigger the animation
21:15:25 <anthony_nz> ED: There is a repeat event which is event based
21:15:34 <anthony_nz> BB: But it describes a qualified repeat event
21:16:20 <ed> s/would that impose some restrictions/would that impose some restrictions, because it's being suggested that eventbase timing wouldn't be allowed in svg-in-img/
21:16:52 <anthony_nz> BB: ... [Slide: Limiting the scope]
21:17:32 <anthony_nz> CM: In SVG you use structure alot to control the rendering. If you introduce the containers control the timing
21:17:39 <ed> s/There is a repeat event which is event based/There is a repeat event which is event based, but there's also repeat-value which isn't the same exactly as event-base/
21:18:35 <anthony_nz> BB: As it stands that is an issue, and you would need to redo where you are putting all your animations and all that
21:19:16 <anthony_nz> DS: Bitflash based on one of their customers needs, added a state machine, I noticed one of the things you were going to talk about was reversing animations
21:19:22 <anthony_nz> ... specifically they added SCXML
21:19:44 <anthony_nz> ... the state machine was attractive because you could define how things interact under changed conditions
21:19:55 <anthony_nz> ... if you're in this state do this thing, etc
21:20:03 <anthony_nz> ... I authored to it and I found it very handy
21:20:18 <anthony_nz> ... their extension of it would allow you keep the history of what had gone one
21:20:44 <anthony_nz> ... navigating around a UI using the state machine would allow the reuse of animations
21:20:57 <anthony_nz> ... it was completely declarative
21:21:07 <anthony_nz> ... not sure where that fits with your proposal
21:21:30 <anthony_nz> BB: There is a whole bunch of stuff in the SMIL state and I was thinking about that recently
21:21:41 <anthony_nz> ... because I thought it would be good to be able to track state more
21:22:08 <anthony_nz> DS: When we are talking about the animation use case, I think the state machine would be very useful for handling the sync for UI stuff
21:22:21 <anthony_nz> ... I think we should take a serious look at it
21:22:56 <heycam> http://www.w3.org/TR/scxml/
21:23:07 <anthony_nz> BB: [Slide: Limiting the scope]
21:23:18 <pdengler> pdengler has joined #svg
21:23:37 <anthony_nz> ... [Slide: Structural manipulations need specification]
21:23:46 <anthony_nz> ... not defined in SMIL so we need to
21:23:54 <anthony_nz> DS: They didn't anticipate script
21:24:10 <anthony_nz> CL: They were very much looking at authoring tools, because of the people involved
21:26:05 <anthony_nz> ... One of the guys that really understands it has joined this working group now and he's interested in reworking it
21:26:23 <Zakim> -tbah
21:26:43 <Zakim> - +1.649.363.aaaa
21:26:44 <Zakim> GA_SVGWG(SVG1)2:30PM has ended
21:26:46 <Zakim> Attendees were +1.649.363.aaaa, tbah
21:26:53 <heycam> Zakim, room for 4
21:26:53 <Zakim> I don't understand 'room for 4', heycam
21:26:54 <heycam> Zakim, room for 4?
21:26:55 <Zakim> ok, heycam; conference Team_(svg)21:26Z scheduled with code 26631 (CONF1) for 60 minutes until 2226Z
21:27:03 <Zakim> Team_(svg)21:26Z has now started
21:27:10 <Zakim> + +1.649.363.aaaa
21:27:27 <Zakim> +tbah
21:28:34 <ed> (15min break)
21:28:41 <Zakim> -tbah
21:29:05 <anthony_nz> BB: [Slide: Structural manipulations need specifications]
21:31:22 <tbah> I'm done for the night so Patrick could dial in direct (it was a better connection than through the bridge).
21:37:03 <Zakim> - +1.649.363.aaaa
21:37:05 <Zakim> Team_(svg)21:26Z has ended
21:37:05 <Zakim> Attendees were +1.649.363.aaaa, tbah
21:37:34 <heycam> Zakim, room for 3?
21:37:36 <Zakim> ok, heycam; conference Team_(svg)21:37Z scheduled with code 26633 (CONF3) for 60 minutes until 2237Z
21:38:35 <Zakim> Team_(svg)21:37Z has now started
21:38:41 <Zakim> + +1.649.363.aaaa
21:41:53 <pdengler_home> pdengler_home has joined #svg
21:45:19 <heycam> Zakim, who is on the call?
21:45:19 <Zakim> On the phone I see +1.649.363.aaaa
21:45:38 <pdengler_home> that's me
21:47:27 <Zakim> + +1.425.868.aabb
21:47:56 <birtles> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements
21:48:00 <birtles> Presentation: http://brian.sol1.net/svg/pres/SVG%202%20Animation.html
21:48:28 <anthony_nz> BB: [Slide: Structural manipulations need specification]
21:48:59 <ed> ed has left #svg
21:49:01 <anthony_nz> ... [Slide: Specify and test structural manipulations]
21:49:06 <ed> ed has joined #svg
21:49:37 <anthony_nz> ... [Slide: Discrete to-animation is counter-intuitive]
21:50:21 <anthony_nz> ... [Slide: Fix discrete to-animation]
21:50:39 <karl> karl has joined #svg
21:50:51 <anthony_nz> ... [Slide: Frozen to-animation is broken]
21:53:33 <anthony_nz> ... [Slide: The requirement for an end-instance time is confusing]
21:54:36 <Zakim> - +1.649.363.aaaa
21:55:11 <Zakim> + +1.649.363.aacc
21:55:23 <heycam> Zakim, who is on the call?
21:55:23 <Zakim> On the phone I see +1.425.868.aabb, +1.649.363.aacc
21:57:01 <anthony_nz> BB: Basically if doesn't find an end instance it just sits there
21:57:07 <anthony_nz> AD: It never starts
21:57:14 <anthony_nz> CM: Doesn't create the interval?
21:57:30 <anthony_nz> BB: After that first interval it will never find the end time
21:57:44 <anthony_nz> ... [Slide: Fix end-instance condition]
21:58:13 <anthony_nz> ... [Slide: min/max aren't necessary useful]
21:58:22 <anthony_nz> CM: Can you explain what the use cases are?
21:58:45 <anthony_nz> BB: Just put a cap on the length on your child animations without knowing anything about them
21:59:17 <anthony_nz> CL: If you have all these time animations and you want them to end a certain point then you specify the ending time for them
21:59:20 <anthony_nz> ... then they all stop
21:59:30 <anthony_nz> BB: [Slide: animateTransform]
22:00:47 <anthony_nz> DS: One of the things I hate is the term "fill" on animations
22:01:04 <anthony_nz> ... you had to determine by the context what "fill" meant
22:01:14 <anthony_nz> CM: In CSS it is animation-fill-mode
22:01:23 <anthony_nz> JW: What are the values?
22:01:28 <anthony_nz> CM: Before, after, both
22:01:41 <anthony_nz> ... both means to fill backwards before the animation
22:02:03 <anthony_nz> ... the property value you can't understand it in isolation
22:02:14 <anthony_nz> BB: [Slide: Reversing animations]
22:03:38 <anthony_nz> CL: So you had the mouse over the button and it grew as big as it could then went back to the original size
22:03:44 <anthony_nz> ... SMIL doesn't have this concept
22:04:01 <anthony_nz> ... [Slide: Add a reverse feature to time containers]
22:04:29 <anthony_nz> s/... [Slide: Add a reverse feature to time containers]/BB: [Slide: Add a reverse feature to time containers]/
22:04:38 <anthony_nz> JW: Maybe call it rewind?
22:04:50 <anthony_nz> BB: [Slide: Add a reverse feature to time containers contd.]
22:06:12 <anthony_nz> ... need to work out if want to do an ease in then an ease out or an ease in then an ease in going in reverse
22:06:21 <anthony_nz> ... might need to do the exact reverse
22:06:28 <anthony_nz> AD: I think that would be the logical thing to do
22:06:43 <anthony_nz> ... running the clock backwards
22:07:54 <anthony_nz> ... would need to work out how to specify it
22:08:04 <anthony_nz> BB: [Slide: Re-use animations]
22:08:54 <anthony_nz> BB: [Slide: Re-use animations contd.]
22:09:38 <anthony_nz> ... [Slide: Brief overview of SMIL Timesheets]
22:10:18 <anthony_nz> CL: That would be really nice with :target
22:10:46 <anthony_nz> BB: [Slide: Selectors can be nested]
22:11:12 <anthony_nz> ... [Slide: Other features introduced by SMIL Timesheets]
22:12:12 <anthony_nz> DS: Can I trigger something manually for when I'm making a presentation
22:12:21 <anthony_nz> CL: You'd want two triggers in that case
22:12:35 <anthony_nz> ... When the time hits or when I press the mouse
22:12:38 <anthony_nz> BB: Not sure
22:12:59 <anthony_nz> ... [Slide: Consider integrating SMIL Timesheets]
22:14:20 <anthony_nz> CL: If you're animating class it's a discrete animation
22:14:38 <anthony_nz> BB: Need to define how it all gets resolved
22:14:55 <anthony_nz> ... [Slide: Migration path]
22:15:59 <anthony_nz> CL: So the first one has a slight risks regarding confusions
22:16:06 <anthony_nz> ... the second one is more what we are doing
22:16:18 <pdengler_home2> pdengler_home2 has joined #svg
22:16:34 <anthony_nz> ... the third seems somewhat drastic but if we are combining SMIL and CSS animation then we are harmonising it
22:16:48 <anthony_nz> ... At the end of the day it's also about animating HTML as well
22:17:18 <anthony_nz> ... So I can see the third option as long as it does right
22:17:57 <anthony_nz> DS: I think using the word SMIL is somewhat dangerous, because SMIL can mean different things to different people
22:18:42 <anthony_nz> ... There is also the case where people will compare it to SMIL
22:19:01 <anthony_nz> ... There are some people out there that dislike SMIL so it might not be as friendly to them
22:19:15 <anthony_nz> ... If we are going to change it dramatically, I'm not sure the second way makes sense
22:19:27 <anthony_nz> ... We could have backwards compatibility with SVG 1.1
22:19:34 <pdengler_home2> I don't think I have been bashful about this.  This is a great presentation.  I believe we should focus on one animation engine/syntax.  I thought this is what we exited Lyon with.  Why would we continue to enhance something that no web developer is looking at?  Let's take these ideas/proposals to CSS :)
22:20:40 <AD> AD has joined #svg
22:20:49 <anthony_nz> DS: One concern I have is as flawed as it is, and if we are going to reinvent the wheel we should be careful about what we do
22:20:54 <anthony_nz> ... we may introduce new problems
22:21:04 <anthony_nz> ... so we need to be careful about what we do with the new stuff
22:21:05 <pdengler_home2> I don't disagree; just like in other areas (gradients, transforms, etc) this group has a lot of experience. We can contribute to a single effort and spread the knowledge more quickly.
22:22:11 <anthony_nz> AD: In terms of web animations 1.0. One of the things we want to achieve is harmony between CSS and SVG. We take the things that we think are good in SMIL
22:22:23 <anthony_nz> ... and add that to Web 1.0 along with the new stuff
22:22:49 <anthony_nz> ... I'm not talking about breaking with the syntax, I'm talking about taking a subset
22:22:58 <anthony_nz> ... and adding that to Web animation 1.0
22:23:38 <anthony_nz> ... We kind of deprecate the SMIL stuff we say is not useful but provide better alternatives
22:23:53 <anthony_nz> CL: It's a gradual already ramp up
22:24:01 <anthony_nz> ... to a certain extent the process has already started
22:24:11 <anthony_nz> ... it will be more widely available when we have first working draft
22:24:18 <anthony_nz> DS: I am curious about time lines
22:24:26 <anthony_nz> ... when do we realistically think this could be done
22:24:39 <anthony_nz> ... I'd like to see some of this stuff in the next releases of web browsers
22:24:44 <anthony_nz> ... these time lines are important
22:25:53 <heycam> Scribe: Cameron
22:25:55 <heycam> ScribeNick: heycam
22:26:23 <heycam> JW: if there are resources available in the css animation community, and those in smil, and can collaborate in the short term, maybe it can happen quickly
22:26:28 <heycam> ... but I don't know if that will happen
22:26:32 <heycam> AD: i really like the reverse stuff
22:26:49 <heycam> JW: i'm more concerned about if we're chopping up smil, or doing something else, we should do it pretty soon
22:27:05 <heycam> DS: i'm also concerned with having 3 major vendors here, with 1 mobile vendor, all on the same page
22:27:11 <heycam> ... we don't have google/webkit people here
22:27:18 <heycam> ... authoring tool people?
22:27:41 <heycam> CL: authoring tool people would be unwise to start now, if we're going to change things
22:27:47 <heycam> ... unless you're right in the discussions
22:27:53 <heycam> DS: so they should participate in the discussions
22:27:56 <heycam> ... content creators, too
22:30:16 <anthony_nz> Scribe: Anthony
22:30:21 <anthony_nz> ScribeNick: anthony_nz
22:39:37 <pdengler_home2> For this proposal, my key contributions are the scenarios and the properties/attributes that I think we need to animate to satisfy them.
22:39:58 <pdengler_home2> My approach is to keep the list of attributes/properties constrained also to simple types so as to no introduce complicated interpolation issues. 
22:40:11 <ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/CSS_Animation
22:40:14 <pdengler_home2> This should is consistent with my original proposal last year to keep SVG 2.0 scenario and use case driven, and incremental. 
22:40:24 <anthony_nz> PD: This is to reduce complexity
22:40:24 <pdengler_home2> Also, supports Jonathon’s desire to move quickly.
22:40:35 <pdengler_home2> Further simplification attempts to avoid the discussion of animVal by using the CSS model.
22:40:47 <pdengler_home2> Though there is a recommended proposal for promoting attributes to properties I was sufficiently convinced for good reasons why this is not a wise idea and these are indicate by Cameron here: http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation
22:41:10 <pdengler_home2> I like these proposals and could live with any that satisfy the scenarios put forth, and that don’t push us into a corner.
22:41:23 <pdengler_home2> The key is to also recognize the imperative need to coordinate with the CSS working group.  I’ve tried contacting Dean with this proposal but I do not believe I got a response.
22:41:54 <pdengler_home2> As a group we should decide as to whether or not we should be doing this (obviously I think yes), if yes, then choose a model which does not paint us into a corner, and get it socialized quickly with CSS.
22:42:47 <anthony_nz> PD: I believe my proposal doesn't quite work given Cameron's comments
22:43:09 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation
22:43:12 <anthony_nz> CM: All this is based on that you should be able to use the CSS Animation syntax to target things which are currently not properties in SVG
22:43:25 <anthony_nz> ... Section 1 presents a few different ways in achieving that goal
22:44:08 <anthony_nz> ... Simplest on the surface would be to convert all these attributes we think are worth animating into properties
22:44:09 <jwatt> jwatt has left #svg
22:44:11 <jwatt> jwatt has joined #svg
22:44:26 <anthony_nz> ... then naturally they will animatable with CSS animations
22:45:01 <anthony_nz> ... [Reads downsides from wiki]
22:45:46 <anthony_nz> CL: The definition in CSS 2.1 is very precise for width and height
22:46:00 <anthony_nz> ... could run into problems with inheriting
22:46:32 <anthony_nz> CM: So this proposal is promoting to properties and using the exact names we have for attributes
22:47:30 <anthony_nz> ... A major issue is that changes the distinction between attributes and properties
22:48:04 <anthony_nz> ... There is a chance here to allow that sort of distinction to say which are styling attributes and which are presentation attributes
22:48:57 <anthony_nz> CL: We were thinking about this and we'd ask what would make sense to re-style on a graphic
22:49:07 <anthony_nz> ... geometry ended up being content in that way
22:50:25 <anthony_nz> DS: One of the most important semantics about SVG is about how it is interpreted by accessibility agents
22:50:42 <anthony_nz> ... and how SVG can be made accessible is not defined
22:50:59 <anthony_nz> CM: The next point against this proposal is the whole SVG DOM interface
22:51:31 <anthony_nz> ROC: We can have them reflect the CSS animated values
22:51:35 <anthony_nz> ... and we can keep them
22:51:51 <anthony_nz> CM: Another issue is which particular set of attributes we'd promote to properties
22:52:07 <anthony_nz> ... in this proposal I think you should convert all the animatable attributes
22:52:18 <pdengler_home2> The only objection I have to that is staging/timing 
22:52:21 <anthony_nz> ... this is so we have the same functionality between CSS animations
22:52:47 <anthony_nz> ... I think Patrick argument is starting with a smaller set is it is achievable goal
22:52:49 <homata_> homata_ has joined #svg
22:53:09 <pdengler_home2> Interopolation is the item I worry about, but they may already be well specified with SMIL
22:53:41 <anthony_nz> CL: If we do a certain subset and they don't scale across then we've painted ourselves into a corner
22:53:56 <anthony_nz> ... If we were going to promote things to properties then we'd do them all at once
22:53:56 <pdengler_home2> Either way we should nail the syntax that CSS animations and transitions need to pick up to target attributes and start there, yes?
22:54:01 <anthony_nz> ... but I still think that is a bad idea
22:54:10 <anthony_nz> ... because it has a lot problems
22:54:57 <anthony_nz> CM: This is probably the fundamental issue about how to target these attributes
22:55:11 <anthony_nz> ... the biggest argument against this proposal is the names these attributes have
22:55:29 <anthony_nz> ... we have attributes that have name as existing properties
22:55:41 <anthony_nz> ... and we may limit CSS from expanding into certain areas
22:56:27 <anthony_nz> CL: One of the other differences between properties and attributes
22:56:36 <anthony_nz> ... is properties can apply to all elements
22:56:51 <anthony_nz> ... so if we have a circle radius, it means that every element has a circle radius
22:57:08 <pdengler_home2> Isn't that already the case with stop-color for example?
22:57:12 <anthony_nz> ... it's pointless to have a radius on all elements
22:57:25 <anthony_nz> ... In CSS they want to restrict the property set
22:58:13 <anthony_nz> ... so if look at proposals they normally choose the proposal that has the least number of properties
22:58:38 <anthony_nz> ROC: We should actually check to see how many properties we have
22:58:42 <anthony_nz> ... and what can be grouped together
22:58:54 <anthony_nz> ... it is a lot of properties but you're adding more leverage to CSS
22:59:07 <anthony_nz> DS: Some people want to do more of what we do in SVG in CSS
23:00:35 <pdengler_home2> I thought it was generally agreed upon in Lyon that animating attributes in CSS was a goal.  I agree that introducing more properties / aligning properties could take time.  Could we start with attributes and worry about what’s a property and what does inheritance mean later (I realize this is against my proposal)
23:00:54 <anthony_nz> CM: So there already are CSS properties that only apply to certain SVG elements
23:00:58 <anthony_nz> ... and like wise for HTML
23:02:00 <anthony_nz> ... Second proposal is the same as the first
23:02:10 <anthony_nz> ... but giving new names
23:02:18 <anthony_nz> CL: So it's really an alias
23:02:37 <anthony_nz> CM: They are given unique names to avoid conflicts and short names e.g. "r'
23:02:46 <anthony_nz> s/"r'/"r"/
23:03:21 <anthony_nz> CM: You could introduce a circle radius attribute to maintain consistency and say how they both work
23:03:41 <anthony_nz> ... and secondly you could break the naming correspondence 
23:04:05 <anthony_nz> CL: I'd prefer to have a table that has the correspondence between the properties and the attributes
23:04:24 <anthony_nz> ... I guess people may start putting it in as an attribute and wondering why it's not working
23:04:33 <anthony_nz> CM: Third is to not do an promotion
23:04:38 <pdengler_home2> Me too!
23:04:54 <anthony_nz> ... and make attributes animatable by CSS Animations
23:05:01 <pdengler_home2> Yes, I changed my mind; I never came up with a syntax that worked but Cameron did.
23:06:10 <anthony_nz> CM: The simple way is to just allow the attribute  names where you can put property name inside the key sets
23:06:23 <anthony_nz> ... then it's unclear if it's a property name or attribute name
23:06:52 <anthony_nz> ... you're stepping on the namespace area again
23:07:16 <pdengler_home2> YES! Perfect Chris!
23:07:52 <anthony_nz> CL: CSS has rect { transition: (attr x) 0.5s; animation: a 0.5s both infinite }
23:07:55 <AD> rect { transition: attr(x) 05.s ...
23:08:21 <pdengler_home2> ship it
23:08:49 <anthony_nz> ROC: attr() seems like the right thing to me
23:09:06 <anthony_nz> ... because it's existing syntax and it's already there
23:09:33 <anthony_nz> CM: Downside is the animation attributes is quite different about how you specify properties
23:10:20 <anthony_nz> ... The third code snippet is a different proposal in this domain 
23:10:52 <anthony_nz> CL: How would you evaluate that one compared to attr()
23:11:51 <anthony_nz> ... currently attr is used on the right hand-side of the ":"
23:12:10 <anthony_nz> CM: I don't think CSS people would be happy with using that in normal rule sets
23:13:24 <anthony_nz> ... These last few code snippets have the same idea
23:13:59 <anthony_nz> ... Why do I prefer promoting properties - it seems less of a hack
23:14:03 <anthony_nz> ... doesn't require new syntax
23:14:14 <anthony_nz> ... I like the idea of extending the scope of properties
23:14:20 <anthony_nz> ... the downside is quite a small set
23:14:41 <anthony_nz> DS: I don't particularly care for the semantics argument
23:14:53 <anthony_nz> ... the semantics argument is not a strong one in my opinion
23:15:23 <anthony_nz> CM: If we can animate these things with CSS animations why wouldn't you want style these things regularly
23:15:39 <pdengler_home2> Whether or not we want to style them, IMHO is a seperate argument. I don't want to style stdDeviation
23:15:41 <anthony_nz> DS: Because of all the problems with promoting them to properties
23:16:51 <anthony_nz> CM: Rest of the page is timing and interpolation functions and features that are missing
23:17:05 <anthony_nz> ... and also how the sandwiches interact
23:17:19 <anthony_nz> ... and a lot more so questions rather specific answers
23:19:19 <anthony_nz> ROC: First of all, David Barron will be implementing CSS Animations in Gecko
23:19:32 <heycam> s/Barron/Baron/
23:19:40 <anthony_nz> ... he's got a lot of knowledge in Transitions and Animations
23:20:12 <anthony_nz> DS: So Chris do you predict any issues with putting attr on the left-hand side
23:20:21 <anthony_nz> CL: Some
23:20:45 <anthony_nz> ROC: In the context of animations it's doable
23:21:03 <anthony_nz> ... in the context of actually doing it, it's probably not doable
23:21:10 <anthony_nz> CL: It depends on why we would be doing this
23:21:31 <anthony_nz> ... if the point is to get CSS Animation to work
23:21:39 <anthony_nz> ... if the point is to style anything
23:22:00 <anthony_nz> ROC: In the key frame stuff, it would work
23:22:04 <anthony_nz> ... not for general stuff
23:22:26 <anthony_nz> PD: Is this also Transitions?
23:22:29 <anthony_nz> CL: Yes
23:23:35 <anthony_nz> CM: So you don't have a problem with attr() on the left-hand side of the ":"
23:23:42 <anthony_nz> ... because you need that for Transitions
23:23:45 <anthony_nz> ROC: Why?
23:24:52 <anthony_nz> CL: Transitions are triggered by certain things - changes attribute
23:25:05 <anthony_nz> ROC: All Transitions says, when something changes make the change smooth
23:25:33 <anthony_nz> CM: [Writes on the board]
23:25:56 <anthony_nz> ... rect {transition: attr(x) 1s}
23:26:02 <homata_> homata_ has joined #svg
23:26:10 <anthony_nz> ... rect: hover {attr(x): 50x}
23:26:19 <anthony_nz> ROC: We shouldn't allow rect: hover
23:26:35 <anthony_nz> CM: So you're saying that CSS Transitions can never change attributes
23:27:53 <anthony_nz> ... Patrick do you have any thoughts about transitions not working CSS styled transition animations?
23:28:06 <anthony_nz> ... the second rule is a straight style rule
23:28:15 <anthony_nz> ... what if you change the x in the DOM
23:28:19 <anthony_nz> ... would that cause a Transition?
23:28:23 <anthony_nz> ROC: Yes
23:30:07 <anthony_nz> DS: If you already have the underlaying model, then changing the parser to set up the model seems trivial
23:30:12 <anthony_nz> CL: I agree
23:30:22 <anthony_nz> ... it's the core animation stuff and how you do your display
23:31:25 <pdengler_home2> so attr() works on transitions, animations and selectors?
23:31:32 <anthony_nz> ROC: I would like to run it by David Baron
23:31:37 <anthony_nz> ED: I will ask the people at Opera
23:32:54 <anthony_nz> CM: The result of this discussion is that putting attr() in regular style rules on the left-hand side wouldn't work
23:33:09 <anthony_nz> ... but the attr() in the Transition would still work
23:33:12 <pdengler_home2> rect:hover{attr(x): 50px}
23:33:21 <anthony_nz> PD: That's not supported?
23:33:24 <anthony_nz> CL: Correct
23:33:35 <anthony_nz> ... you'd thrash the DOM doing it that way
23:33:42 <anthony_nz> CM: The work around is to make a CSS Animation
23:34:05 <anthony_nz> ... because you can make the animation apply on the :hover
23:35:50 <anthony_nz> ... We can discuss the proposal at the next FX call
23:36:10 <anthony_nz> ... in two weeks
23:36:11 <ed> next fx telcon will be in two weeks time
23:36:27 <anthony_nz> CL: Get it finialised if we meet in June with CSS Working Group
23:38:56 <anthony_nz> RESOLUTION: We prefer to use the attr() solution that allows CSS animations to target SVG attributes directly rather promoting attributes to properties
23:39:08 <ed> (break for lunch)
23:39:57 <Zakim> - +1.425.868.aabb
23:40:04 <Zakim> - +1.649.363.aacc
23:40:06 <Zakim> Team_(svg)21:37Z has ended
23:40:07 <Zakim> Attendees were +1.649.363.aaaa, +1.425.868.aabb, +1.649.363.aacc
00:21:51 <pdengler_home2> I sent some of you an email with files to support our intrinsic sizing discussion. If I am late, please begin without me and I will catch up.  See the agenda page for clear information about what we discovered.
00:22:03 <pdengler_home2> Jonathan has been working on this for a while and shared his tests with all of us a long time ago.  
00:22:17 <pdengler_home2> We wanted to share some tests back and perhaps we can use them as a test bed for the test framework discussed on Monday.
00:22:23 <pdengler_home2> We believe that these tests are accurate to the specification and where we believe the spec to be ambiguous, is within the spirit of the specification and/or interoperable.
00:22:26 <pdengler_home2> So we can start with what we found (http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Intrinsic_sizing_tests) and I can post a test page with images.
00:22:30 <pdengler_home2> For the tests, you will notice that indeed IE9 passes all of them; this is because we used these tests to develop our platform.  
00:22:43 <pdengler_home2> As indicated on the email DL, after our latest platform preview we caught some sizing discrepancies between our implementation and the spec; we subsequently made adjustments
00:22:53 <pdengler_home2> At the time of the change we aligned with Firefox beta.  I think Firefox made adjustments for interop based upon our implementation (I think that’s what Rob said).
00:22:59 <pdengler_home2> My apologies on this and my lack of communication on our last minute updates.  They were fast and furious and as I promised these tests we want to contribute and believe that they accurately reflect the specification.
00:23:52 <pdengler_home2> (be back shortly0
00:37:40 <birtles> birtles has joined #svg
00:41:44 <heycam> Zakim, room for 3?
00:41:46 <Zakim> ok, heycam; conference Team_(svg)00:41Z scheduled with code 26631 (CONF1) for 60 minutes until 0141Z
00:42:11 <Zakim> Team_(svg)00:41Z has now started
00:42:17 <Zakim> + +1.649.363.aaaa
00:43:32 <ed> i see that the examples patrick mailed out uses preserveAspectRatio="None" (caveat being that svg attributes are case-sensitive)
00:44:01 <ed> the keyword value that is
00:45:45 <ed> just one of the files: test_svg_viewbox_preserveratio.svg
00:49:26 <jwatt> scribe: Jonathan Watt
00:49:29 <jwatt> scribenick: jwatt
00:50:01 <jwatt> topic: Animation Improvements
00:51:09 <jwatt> BB: do we want a new spec for Web Animations, or to continue work on SVG animation?
00:51:31 <jwatt> CM: so would Web Animations be an abstract spec about the model?
00:51:38 <jwatt> DS: I think a single spec
00:52:09 <jwatt> BB: I think we want this to apply to CSS properties in HTML, so have it separate to SVG
00:52:11 <Zakim> - +1.649.363.aaaa
00:52:12 <Zakim> Team_(svg)00:41Z has ended
00:52:12 <Zakim> Attendees were +1.649.363.aaaa
00:52:44 <Zakim> Team_(svg)00:41Z has now started
00:52:51 <Zakim> + +1.649.363.aaaa
00:53:38 <jwatt> CM: would that allow <animate> et. al. in HTML documents?
00:54:03 <jwatt> ...or just have those elements being in SVG fragments but being allowed to target CSS properties in HTML documents?
00:54:29 <jwatt> BB: defined in a way to allow HTML X to pull it in
00:54:58 <jwatt> ...to target attributes if they wanted to do that
00:55:20 <jwatt> DS: I think DOM bindings should be defined in that spec
00:56:06 <jwatt> CM: separate spec sounds similar to the way we have separate SMIL specs now
00:56:40 <jwatt> ...would it define elements that a host language can put it its own namespace?
00:58:05 <jwatt> BB: I don't want to make in so abstract that we're not giving elements with names
00:59:17 <jwatt> DH: it worries me slightly that we'll end up with four separate animation specs which people implement subsets of
00:59:33 <jwatt> ...it seems like it might make more sense to keep in in the SVG spec
00:59:49 <jwatt> s/in in/it in/
01:00:38 <jwatt> ...to deserve the name "Web Animations" it would have to be a super-model to rule them all
01:01:01 <jwatt> BB: getting CSS animations in the same spec
01:02:35 <jwatt> DS: having a distinct and short name for the spec would have value
01:04:22 <jwatt> ...I suggest we put something on paper as a single spec, try that, and split it if we have to
01:07:41 <jwatt> ROC: first I want to get everyone together to figure out what browsers currently do with SMIL and CSS animation integration
01:08:05 <jwatt> ...and transitions
01:10:57 <jwatt> ...how they interact
01:10:58 <jwatt> DS: it seems like the CSS stuff should override
01:11:13 <jwatt> ROC: having CSS animations override SMIL animVals makes sense to me
01:11:27 <heycam> heycam has joined #svg
01:11:32 <anthony_nz> anthony_nz has joined #svg
01:11:32 <birtles> birtles has joined #svg
01:11:55 <roc> roc has joined #svg
01:12:30 <jwatt> ROC: I would put everything in one spec
01:12:57 <jwatt> DH: so scrap the CSS-animations spec its current incarnation?
01:13:11 <jwatt> ROC: I think so
01:13:54 <shepazu> s/so scrap the CSS-animations spec its current incarnation/so integrate the existing CSS animations spec into a single unified spec/
01:14:31 <jwatt> ACTION: Jonathan to Get Daniel to talk to David about making a new harmonized animations spec
01:14:31 <trackbot> Created ACTION-2993 - Get Daniel to talk to David about making a new harmonized animations spec [on Jonathan Watt - due 2011-03-10].
01:18:28 <jwatt> RESOLUTION: Try to bring the existing declarative animation spec work together into a single spec, with separate sections for CSS animation and SVG animation
01:20:31 <jwatt> ACTION: Erik to bring up the one true animation spec on the fx call
01:20:31 <trackbot> Created ACTION-2994 - Bring up the one true animation spec on the fx call [on Erik Dahlström - due 2011-03-10].
01:26:09 <AD> AD has joined #svg
01:28:04 <Zakim> + +1.425.868.aabb
01:28:28 <birtles> scribenick: birtles
01:28:35 <birtles> Scribe: Brian
01:29:09 <pdengler_home2> can't understand
01:29:19 <pdengler_home2> Filters
01:29:31 <pdengler_home2> How about filters
01:29:41 <pdengler_home2> I have some text I wrote
01:29:53 <birtles> topic: SVG 2 / CSS Filters Module
01:30:35 <jwatt> jwatt has left #svg
01:34:33 <pdengler_home2> are we all on the same chat now?
01:34:44 <dholbert> I'm here
01:34:52 <dholbert> heycam, can you see me? :)
01:35:00 <heycam> ACTION: Cameron to bring up the CSS-animations-targetting-SVG-attribtues in the next FX telcon
01:35:01 <trackbot> Created ACTION-2995 - Bring up the CSS-animations-targetting-SVG-attribtues in the next FX telcon [on Cameron McCormack - due 2011-03-10].
01:35:03 <dholbert> (heycam says 'yes')
01:36:30 <roc> roc has joined #svg
01:36:34 <jwatt> jwatt has joined #svg
01:36:46 <AD> AD has joined #svg
01:37:04 <birtles> birtles has joined #svg
01:37:04 <anthony_nz> anthony_nz has joined #svg
01:37:08 <birtles> scribenick: birtles
01:37:10 <ChrisL> ChrisL has joined #svg
01:37:11 <birtles> Scribe: Brian
01:37:18 <birtles> ED: I did some updates to the filter spec
01:37:18 <ed> http://dev.w3.org/Graphics-FX/modules/filters/publish/SVGFilter.html
01:37:29 <ChrisL> rrsagent, here
01:37:29 <RRSAgent> See http://www.w3.org/2011/03/02-svg-irc#T01-37-29
01:37:32 <birtles> I added some wording for handling filters applied to HTML thru CSS
01:37:40 <homata_> homata_ has joined #svg
01:37:45 <birtles> ... based on what roc wrote up
01:37:55 <birtles> ... taking part of the spec from Mozilla and integrating it into this filter spec
01:38:10 <AD> AD has joined #svg
01:39:02 <pdengler_home2> We need to distinguish what the filter is being applied to.  From my simple understanding, the SVG Filters apply to graphical elements and paint underneath.
01:39:10 <pdengler_home2> HTML “filters” (box-shadow, text-shadow) target different parts.  
01:39:15 <pdengler_home2> I suggest we add a ‘filter-target’ property to target different things (“box|text”) or (“content|whole”). 
01:39:42 <birtles> PD: need to differentiate between targetting background content vs content itself
01:40:22 <pdengler_home2> yes i can hear you
01:40:33 <birtles> RO: I think the best way to do that is to add new images
01:40:44 <birtles> ... right now you have SourceAlpha etc.
01:40:55 <birtles> ... ContentImage, ContentAlpha etc.
01:41:18 <birtles> ED: I added into the spec some wording in red about this
01:41:33 <birtles> RO: I don't think it's difficult to add new image names here
01:41:45 <birtles> ED: So what do we want to add Border? Background?
01:41:54 <birtles> RO: Border, Background, Outline are the 3 main ones
01:41:59 <birtles> ... Content would be everything else
01:42:07 <birtles> ... that includes everything their child can containa
01:42:16 <birtles> ... that would be really powerful, and easy to undersatnd
01:42:20 <birtles> ... let's do it
01:42:27 <birtles> ED: Does that map to something in SVG
01:42:30 <birtles> RO: no
01:42:46 <ChrisL> s/containa/contain, including their borders and backgrounds
01:43:46 <birtles> CM: What are you thinking of?
01:43:54 <birtles> CL: Of those, SVG only has Content
01:44:03 <birtles> ... Content would apply to SVG and HTML equally
01:44:13 <birtles> PD: So I want to be able to only target the background of a table
01:44:30 <birtles> ... I want to take a SVG filter and target it to the text in this page, the background in another
01:44:36 <birtles> ... so it shouldn't be on the filter
01:44:45 <pdengler_home2> filter-target="background"
01:44:53 <birtles> CM: So it should be on the property not the filter
01:45:12 <birtles> CL: But sometimes you want more than one
01:45:18 <birtles> CM: But for the simple case you only need one
01:45:49 <birtles> RO: one thing that's missing is how to interpret user space units
01:45:53 <pdengler_home2> filter-target="border|background|content(default)"
01:46:00 <birtles> ED: it's there
01:46:39 <birtles> PD: I'm talking about targetting a div
01:47:16 <birtles> CM: we're talking about things (1) inside the filter introduce new filter primitive keywords (2) targetting a whole filter to only one aspect of a box
01:47:23 <birtles> s/about things/about two things/
01:47:42 <birtles> CL: there's always going to be a limit to what you can do with shorthand properties
01:47:49 <birtles> ED: keep the canned filters as simple as possible
01:47:59 <birtles> CM: I'd be happy with a feature like that
01:48:04 <birtles> PD: I agree
01:48:20 <birtles> ... the shorthand lets people doing something quickly
01:48:29 <birtles> ... but if you want to do something more complex you have to dig deeper
01:48:41 <birtles> ... and that's in a new spec where you start talking about new sources
01:49:09 <pdengler_home2> So how do we get that to the CSS working group? Next FX call 
01:49:31 <birtles> ED: Dino has an action to come up with the proposed syntax for the shorthands
01:49:37 <birtles> ... he's the co-editor of the spec
01:49:44 <birtles> ... it's moved to the public fx taskforce
01:49:54 <birtles> ... I'll get in touch with him to see how it's going
01:50:02 <pdengler_home2> Sounds great, for my ability to track this can you create an issue on that
01:50:19 <birtles> ED: If he's too busy I'll propose something
01:50:28 <birtles> ... I'd like to remove the margin attribute
01:50:40 <birtles> ... and figure out the filter regions so we don't get clipping by default
01:50:57 <pdengler_home2> All of this sounds great Eric
01:51:12 <birtles> ... the margins were in the original SVG 1.1 which was suppose to address blur margins
01:51:24 <birtles> ... but all implementations are doing optimisations to address the slow cases anyway
01:51:31 <birtles> ... so they need to optimise the regions anyway
01:51:40 <birtles> CM: was there other stuff you'd like to rip out
01:51:46 <birtles> ED: they were the major things
01:51:47 <pdengler_home2> I was going to say we clamp, but....we don't do filters...
01:51:53 <birtles> ... the next step would be new filter primitive
01:52:02 <ed> http://www.w3.org/Graphics/fx/wiki/Filter_effects
01:52:25 <birtles> CM: experience shows explicit clamping in there didn't prove to be a useful optimisation
01:52:31 <birtles> ... people don't do it properly
01:52:55 <birtles> PD: if we were to do clamping it would be nice to have specific properties
01:53:19 <birtles> ... e.g. to what extent to you extend to infinite regions
01:53:39 <birtles> ... i'd like a story that says you can shoot yourself in the foot, but this is as far as you can go
01:53:44 <birtles> RO: can you give us an example?
01:53:53 <birtles> ... what are you talking about clamping?
01:53:58 <pdengler_home2> i'm talking about clamping the combination of dx, stddeviation etc. don't worry
01:54:06 <pdengler_home2> i prefer the margin proposal
01:54:10 <birtles> CM: we're talking about different things
01:54:13 <pdengler_home2> Sorry
01:54:52 <birtles> ED: in those cases it might make sense to have limits
01:55:01 <birtles> ... although it needn't necessarily be in the spec
01:55:09 <birtles> ... but implementations should probably have limits
01:55:41 <birtles> CL: shorthand properties (canned filters) should say that here is an SVG filter that is equivalent
01:55:49 <birtles> ... but make clear you don't have to implement it like that
01:55:53 <birtles> ... as long as it has the same effect
01:56:03 <birtles> ... but authors shouldn't expect that SVG filter to show up in the DOM
01:56:13 <birtles> ... that allows hardware/platform acceleration to be used
01:56:28 <pdengler_home2> Sure
01:56:54 <ed> ED: could you explain a bit more about the point: "Support the inclusing of SVG <defs> as part of <link> in HTML"
01:57:21 <pdengler_home2> <link rel=”import” type=”image/xml+svg” href=”file.svg”>.
01:57:26 <birtles> PD: I often end up with fairly large filters which I'd like to link externally
01:57:49 <birtles> CM: the current way you reference filters is in this way: url # something
01:57:54 <pdengler_home2> <link rel="import" type="image/xml+svg" href="file.svg">.
01:58:02 <ChrisL> url()
01:58:13 <pdengler_home2> <filter="url(svg1.svg#mydef)"
01:58:27 <birtles> ED: how does import work?
01:58:59 <birtles> PD: it's difficult to import gradient, image definitions
01:59:10 <birtles> RO: you can reference all of those with URL # references
01:59:15 <birtles> ... what's wrong with that?
01:59:28 <birtles> PD: i don't have a bit complaint
01:59:33 <birtles> s/bit/big/
02:00:17 <birtles> RO: there's one situation: people writing stylesheets would like to reference filters without requiring yet another document
02:00:27 <birtles> ... one proposal is allowing CSS to contain XML
02:00:37 <birtles> ... so you can put the filter directly in the stylesheet
02:00:44 <birtles> ... I don't think it's a bad idea
02:00:55 <birtles> ... but for now the URL syntax seems to work
02:01:06 <birtles> PD: yeah, that makes sense
02:01:14 <birtles> ... let's leave it
02:01:37 <AD> AD has joined #svg
02:01:38 <birtles> CL: in SVG we were very careful to use URI refs rather than ID ID-refs
02:01:46 <birtles> ... since that doesn't work for other docs
02:01:55 <birtles> ... so it gives us flexibility to address that
02:02:31 <birtles> ED: in this draft here I have one filter primitive that's not defined yet
02:02:35 <birtles> ... feCustom
02:02:47 <birtles> ... it's for defining shaders with SVG filters
02:03:04 <birtles> ... one possible way is to allow people to write filter primitives with open CL
02:03:10 <birtles> ... or perhaps WebGL
02:03:21 <birtles> ... it's lower level but gives you a lot of power
02:03:33 <birtles> CL: previously we proposed javascript callbacks for this
02:03:37 <birtles> ED: that would be slow
02:03:45 <birtles> CL: yeah, so this looks like more practical
02:03:57 <birtles> ED: so do you want to allow software-only engines to run shaders?
02:04:36 <birtles> PD: before we go to far down this path... is WebGL going to be brought into the W3C
02:04:38 <birtles> ?
02:04:48 <birtles> RO: WebGL may  not be W3C but it is a standard
02:05:05 <pdengler_home2> Is webgl under the same patent policy as w3c?
02:05:23 <ChrisL> http://en.wikipedia.org/wiki/WebGL
02:05:35 <birtles> ... on any platform that can run WebGL you should be able to use WebGL in a shader
02:05:40 <birtles> ED: could be a feature string
02:05:48 <birtles> ... so if you can run this, do this, otherwise do that
02:06:03 <birtles> CL: or we could use another language feature
02:06:13 <birtles> DS: what's the license?
02:06:21 <birtles> RO: not sure
02:06:29 <birtles> ... but the Chronos group has dealt with IP a lot
02:06:52 <heycam> s/Chronos/Khronos/
02:07:12 <birtles> ED: so if we do that it would be good to pull into filter input images
02:07:17 <birtles> ... and integrate with the rest of the filter spec
02:07:22 <ChrisL> http://en.wikipedia.org/wiki/HLSL
02:07:27 <birtles> ... means some definition of how it integrates with the shader language
02:07:35 <ChrisL> http://en.wikipedia.org/wiki/Cg_%28programming_language%29
02:07:37 <birtles> ... how SVG filters integrate
02:07:53 <birtles> ... otherwise you could have just the shader and some fallback
02:08:07 <birtles> CM: so you want 1/2 inputs just like you do with filter primitives?
02:08:14 <birtles> ED: what does the shader look for?
02:08:27 <birtles> CM: mapping from the SVG buffer to whatever the shader takes
02:08:33 <birtles> ED: same for the output from the shader too
02:08:53 <birtles> CL: Cg lang can output different types of shaders
02:09:04 <birtles> ... so it could provide different shaders depending on the platform
02:09:12 <birtles> RO: Google provide ANGLE
02:09:41 <pdengler_home2> "almost native" 
02:10:12 <birtles> PD: will you pull that stuff out in the next week or so?
02:10:13 <ChrisL> http://code.google.com/p/angleproject/issues/detail?id=35
02:10:20 <birtles> ED: in the coming weeks
02:10:41 <birtles> CL: I want some language in the spec about the canned effects
02:10:55 <birtles> ... that you don't actually need the equivalent SVG in the DOM as long as you get the same result
02:11:15 <pdengler_home2> Did we solve the issue I brought up before with filter-target on HTML elements?
02:11:40 <birtles> ACTION: Erik to work on removing the margins and put some proposed text for how to deal with the proposed filter regions into the filters spec
02:11:41 <trackbot> Created ACTION-2996 - Work on removing the margins and put some proposed text for how to deal with the proposed filter regions into the filters spec [on Erik Dahlström - due 2011-03-10].
02:12:17 <birtles> ACTION: Erik to follow up Dino about the shorthand syntax for filter effects
02:12:18 <trackbot> Created ACTION-2997 - Follow up Dino about the shorthand syntax for filter effects [on Erik Dahlström - due 2011-03-10].
02:12:21 <ChrisL> actually http://code.google.com/p/angleproject/ is a better pointer for angle
02:13:06 <pdengler_home2> my phone failed
02:13:12 <Zakim> - +1.425.868.aabb
02:13:14 <pdengler_home2> I don't have my machine configured
02:13:18 <pdengler_home2> to check into W3C
02:13:34 <pdengler_home2> I emailed them, can someone please do that for me (my apologies)
02:13:40 <pdengler_home2> (Did you get them in email?)
02:13:54 <pdengler_home2> Ok I will get another phone and meet back after your break
02:14:16 <ChrisL> s/yes we did/yes at least erik did and he is checking them in/
02:17:49 <ed> http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size/svg_size.html
02:18:12 <Zakim> disconnecting the lone participant, +1.649.363.aaaa, in Team_(svg)00:41Z
02:18:16 <Zakim> Team_(svg)00:41Z has ended
02:18:18 <Zakim> Attendees were +1.649.363.aaaa, +1.425.868.aabb
02:22:26 <dholbert> pdengler_home2, so it looks like your page ^ is pairs of [svg testcase] [raster expected-rendering], right?
02:30:28 <pdengler_home2> *should* be a test with the expected rendering next to it in a raster format
02:34:33 <heycam> Zakim, room for 3?
02:34:35 <Zakim> ok, heycam; conference Team_(svg)02:34Z scheduled with code 26631 (CONF1) for 60 minutes until 0334Z
02:34:56 <Zakim> Team_(svg)02:34Z has now started
02:35:03 <Zakim> + +1.649.363.aaaa
02:36:25 <Zakim> + +1.425.868.aabb
02:38:39 <pdengler_home2> we overloaded the server with .5MB? :)
02:50:51 <birtles> birtles has joined #svg
02:50:55 <anthony_> anthony_ has joined #svg
02:50:59 <heycam> Zakim, who is on the call?
02:51:00 <Zakim> On the phone I see +1.649.363.aaaa, +1.425.868.aabb
02:51:21 <birtles> scribenick: birtles
02:51:21 <anthony_nz> anthony_nz has joined #svg
02:51:25 <birtles> Scribe: Brian
02:51:28 <birtles> topic: Intrinsic sizing
02:51:36 <AD> AD has joined #svg
02:51:53 <jwatt> jwatt has joined #svg
02:52:36 <pdengler_home2> Jonathan has been working on this for a while and shared his tests with all of us a long time ago.  
02:52:49 <birtles> http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size/svg_size.html
02:53:52 <birtles> ED: I've made some fixes (doctype, preserveAspectRatio="none" <-- lowercase "none")
02:55:56 <roc> roc has joined #svg
02:57:37 <ChrisL> ChrisL has joined #svg
02:57:51 <ChrisL> rrsagent, here
02:57:51 <RRSAgent> See http://www.w3.org/2011/03/02-svg-irc#T02-57-51
02:58:49 <jwatt> http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size/svg_size.html
03:00:11 <ed> (for completeness, here are the unmodified files from patrick: http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size-patd-original/svg_size.html )
03:00:19 <homata> homata has joined #svg
03:01:29 <pdengler_home2> We wanted to share some tests back and perhaps we can use them as a test bed for the framework discussed on Monday.
03:01:43 <pdengler_home2> We believe that these tests are accurate to the specification and where we believe the spec to be ambiguous, is within the spirit of the specification and/or interoperable.
03:02:19 <pdengler_home2> For the tests, you will notice that indeed IE9 passes all of them; this is because we used these tests to develop our platform.  
03:02:46 <pdengler_home2> As indicated on the email DL, after our latest platform preview we caught some sizing discrepancies between our implementation and the spec; we subsequently made adjustments.
03:02:53 <pdengler_home2> At the time of the change we aligned with Firefox beta.  I think Firefox made adjustments for interop based upon our implementation (I think that’s what Rob said).
03:03:05 <pdengler_home2> (http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Intrinsic_sizing_tests) 
03:04:23 <birtles> PD: Let's see if we can agree on what the spec says, or if the tests are wrong
03:04:36 <birtles> JW: I think the 7th and 8th images are not being sized correctly on IE
03:04:56 <jwatt> JW: "SVG sizing with 'viewbox' specified while 'width' and 'height' is percentage inside an 'object' tag."
03:05:16 <birtles> JW: the 4th set of images
03:05:47 <birtles> JW: from my understanding, the object element ends up with width 50%, height: auto because the containing block, the body, has height auto
03:06:07 <birtles> ... which gets you to section 10.6.2 of CSS 2
03:06:10 <jwatt> http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-height
03:06:49 <jwatt> JW: Otherwise, if 'height' has a computed value of 'auto', and the element has an intrinsic ratio then the used value of 'height' is:
03:06:51 <jwatt> JW: (used width) / (intrinsic ratio)
03:07:16 <birtles> ... since the height is not resolvable you end up using the intrinsic dimensions of SVG (100x100) --> ratio 1:1
03:07:27 <birtles> ... so the height of the object tag should be given the same computed value as its width
03:07:34 <birtles> ... so you should end up with square
03:07:42 <birtles> s/square/a square/
03:08:26 <birtles> PD: so firefox ends up with a square on this one?
03:08:36 <birtles> JW: previously you might have been testing firefox in quirks mode
03:08:46 <birtles> ... but if you run the test again you'll see it is a square in firefox
03:09:28 <birtles> PD: Erik, what's your interpretation
03:09:36 <birtles> ED: Jwatt is probably right
03:09:44 <birtles> ... what does the P1, P2, P2 mean in the wiki page
03:09:54 <pdengler_3> pdengler_3 has joined #svg
03:09:58 <birtles> PD: ignore that
03:10:11 <jwatt> RRSAgent: make minutes
03:10:11 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/02-svg-minutes.html jwatt
03:10:34 <birtles> ED: The P3 might have only been wrong because of the capitilisation of preserveAspectRatio
03:10:45 <birtles> PD: do you agree with jwatt's assessment that it should be 1:1
03:10:48 <birtles> ED: yeah, I think so
03:10:53 <birtles> PD: what does Opera do?
03:11:19 <birtles> DH: Opera matches the bitmap on my computer
03:11:25 <birtles> PD: it's the same as IE9 on my computer
03:11:46 <birtles> DH: could it be that they're using the viewBox to generate an aspect ratio?
03:11:52 <birtles> ... in this case there's a width and a height
03:12:38 <birtles> ED: jwatt is probably correct here
03:12:48 <birtles> ... I think the spec says the width/height takes precedence in this case
03:12:57 <birtles> ... and viewBox is used if there's no width/height
03:13:07 <pdengler_3> My understanding is that the viewBox would take precidence as the percentage is 100% correct?
03:13:34 <dholbert> height/width are both 100px
03:13:40 <birtles> JW: I'm pretty sure I'm right
03:13:49 <dholbert> there's no percentage 100%, IIUC
03:14:07 <birtles> CL: 1.1F2 should have the same wording as Tiny
03:14:08 <birtles> ED: so width/height should have precedence
03:14:58 <birtles> PD: I want to make sure we're on the same page and it seems Erik and Jonathan are agreed
03:15:09 <birtles> ... I think this would be a good set of tests to formalise
03:15:18 <birtles> ... into the test bed
03:15:32 <birtles> ... where else do you think our interpretation might be incorrect?
03:16:19 <birtles> ... bear in mind that these tests are hot off the press
03:18:00 <jwatt> JW: I think FF currently handles "SVG sizing without 'viewbox' specified while 'width' and 'height' is percentage inside an 'object' tag." incorrectly
03:18:06 <dholbert> I agree
03:18:34 <birtles> JW: it doesn't override the width/height on the SVG tag
03:18:37 <ed> "SVG sizing with 'viewbox' specified while 'width' and 'height' is percentage inside an 'object' tag."
03:18:56 <birtles> ED: the first example says the width/height is % but the test case doesn't use % -- was the test case wrong
03:19:00 <birtles> ... oh it refers to the object element
03:20:21 <pdengler_3> Eric, do you mean the very first test?
03:20:44 <ed> http://dev.w3.org/SVG/profiles/1.1F2/publish/coords.html#IntrinsicSizing
03:21:16 <birtles> ED: yes, so I just wasn't sure where the percentages were, but it's ok
03:22:35 <pdengler_home5> pdengler_home5 has joined #svg
03:23:27 <birtles> ED: So, is Firefox's handling of the first case is incorrect?
03:23:30 <birtles> JW: no not the first case
03:24:15 <jwatt> JW: "SVG sizing without 'viewbox' specified while 'width' and 'height' is percentage inside an 'object' tag." - half way down the page
03:25:05 <ed> ED: sorry, misread it, a bit confused by the similar text descriptions
03:25:27 <birtles> JW: So those are the only two cases I would point out
03:25:36 <birtles> DH: Looks like we match the reference on everything else
03:25:40 <pdengler_home5> Ok, and that's the same issue as the 4th one right?
03:25:56 <birtles> ED: you mean just the SVG part, not the dotted lines
03:26:10 <birtles> DH: I mean including the dotted lines
03:26:18 <birtles> ... but ignoring the padding
03:26:35 <birtles> JW: Are the images supposed to match in size and position as well?
03:26:51 <birtles> PD: I believe Opera had some differences with the stylesheet
03:27:12 <birtles> JW: In IE9 after adding the doctype the rendering and bitmaps don't seem to be the same
03:27:26 <pdengler_home5> That' because we made changes since PPB7 in RC to match Firefox :)
03:27:39 <pdengler_home5> and the spirit and letter of the spec (I hope)
03:28:16 <birtles> PD: They all match for me on my build
03:28:46 <pdengler_home5> SVG sizing without 'viewbox' specified while 'width' and 'height' is percentage inside an 'object' tag."
03:29:19 <birtles> JW: Mozilla needs to fix that
03:29:30 <birtles> DH: Firefox does that incorrectly
03:29:33 <pdengler_home5> The only issue is then that we have #4 incorrect
03:29:52 <pdengler_home5> (aside from the preserveAspectRatio casing)
03:30:07 <birtles> JW: For the examples on this page, the first one I pointed out you don't do correctly, but the second one you and Opera do correctly and Mozilla does not
03:30:31 <birtles> ED: I think we should try to forward this to the WebKit guys
03:31:00 <birtles> ... our next step would be to try to collect these test cases into a test framework
03:31:09 <birtles> ... but it sounds like we're mostly on the same page
03:31:22 <birtles> PD: maybe contact with WebKit will really get us online
03:32:01 <birtles> JW: on the wiki page, under Firefox 4 there are 5 bullet points
03:32:24 <birtles> ... referring to the third one
03:32:43 <birtles> ... I think this is the correct thing to do
03:33:12 <birtles> ... did you remove viewBox logic?
03:33:44 <birtles> ... talking about it in terms of a viewBox is just to get the desired result
03:33:51 <birtles> ... to give the same effect as for raster images
03:34:22 <birtles> The point in question is "Next Firefox 4 beta will have Opera’s <img> viewBox logic."
03:34:36 <birtles> DH: I think the problem is when you have a non-percent width/height and NO viewbox
03:34:46 <birtles> ... we've changed it to synthesize a viewBox in that case
03:34:46 <pdengler_home5> I think we all recognize that this is probably desirable, but I definitely want to raise the issue that injecting a missing attribute might be considered "quirks"
03:34:50 <birtles> ... that's what Opera does
03:35:32 <birtles> ... this is for scaling
03:36:05 <birtles> ... the straightforward thing to do is to clip but what Opera does and what we think authors expect is to have the image scale
03:36:09 <birtles> ... like with a raster image
03:36:16 <birtles> ... an author can add a viewBox to get that behaviour
03:36:26 <birtles> ... but authoring tools generally don't do that
03:36:45 <birtles> CL: but then you can't get the image to be the size you desire anymore
03:37:04 <birtles> JW: if that's what you want just put width/height auto on your image tag
03:37:22 <birtles> DH: it's only when the SVG width/height doesn't match the image width/height
03:37:33 <shepazu> shepazu has joined #svg
03:37:40 <pdengler_home5> That was our concern; it may make sense, but it is assuming an attribute that is not there
03:37:47 <birtles> ... we do it on the image tag, list style image (CSS images), but not on the SVG:image tag because it's well defined there
03:37:52 <birtles> ED: we don't do it there either
03:38:23 <birtles> DS: Tab Atkins wrote on www-style that he found the intrinsic sizing discussion a bit confusing
03:38:55 <birtles> ... we sorted out what was confusing him -- it wasn't clear to him that the SVG canvas extended infinitely on all sides
03:39:06 <birtles> ... he thought we could make that more clear
03:39:23 <birtles> ... and that if we talked about % width/height as a transformation
03:39:32 <birtles> CL: it's fairly easy to explain
03:39:37 <shepazu> q+
03:39:42 <birtles> ... e.g. 30% each transform="scale(0.3)"
03:41:02 <birtles> DS: I thought it would be harmless to explain in those terms
03:41:27 <birtles> ACTION: Doug to add some additional clarification to the intrinsic sizing part of the spec
03:41:27 <trackbot> Created ACTION-2998 - Add some additional clarification to the intrinsic sizing part of the spec [on Doug Schepers - due 2011-03-10].
03:42:20 <eseidel_> eseidel_ has joined #svg
03:42:34 <birtles> CL: (re Patrick's concern about the "quirk" of adding a viewBox attribute)
03:42:53 <birtles> DH: it doesn't match object
03:43:00 <birtles> PD: it doesn't match the spec
03:43:11 <birtles> DH: it doesn't match the spirit of the spec
03:43:22 <birtles> CL: is there anything in the HTML spec regarding this behaviour for PNG images etc.
03:43:32 <birtles> ... we could see if we're consistent with that
03:43:42 <birtles> DH: I'm sure it's in the CSS spec for raster images / replaced elements
03:43:59 <birtles> ... but I think a lot of the CSS spec text about this stuff doesn't expect images that react to their viewport
03:44:13 <birtles> JW: the bottom line is that without this viewBox insertion behaviour is unexpected for authors
03:44:15 <ChrisL> until recently, that was certainly true
03:44:28 <birtles> ... with this they get what they expect
03:44:48 <birtles> PD: I'm not sure, it's tough
03:44:59 <jwatt> JW: some very loose spec text that daniel and I came up with while trying to get images to behave as authors expect: "for SVG-as-an-image, if the /embedding/ element doesn't implement preserveAspectRatio and the root <svg> in the image doesn't have a viewBox, resolve the <svg>'s width/height to pixels values and use viewBox="0,0,resolvedwidth,resolvedheight" and preserveAspectRatio=none...
03:45:01 <jwatt> ...(ignoring any preserveAspectRatio on the <svg>)"
03:45:11 <birtles> DH: I acknowledge our current behaviour makes me uncomfortable given the lack of clarity in the spec
03:45:19 <birtles> ... I'd be more comfortable if we had something in the spec
03:45:27 <birtles> PD: it does say that for image
03:45:39 <birtles> ... but not when used as an <img>
03:46:39 <birtles> DH: the SVG image has different behaviour than the HTML <img> element for raster images
03:46:49 <birtles> ... so it's not unexpected that it would be different for SVG images either
03:48:20 <birtles> CL: Well we shouldn't define it in terms of faking a viewBox, but rather by analogue with raster images
03:48:39 <birtles> JW: maybe we can express it in terms of inserting an extra transform
03:48:47 <birtles> ... actually that's what we do
03:49:10 <birtles> ... we talk about viewBox to make it easier for an author to understand
03:49:54 <birtles> CL: if an image has an intrinsic size / fixed size and you want to make it bigger
03:50:09 <birtles> ... for raster images you scale it up
03:50:16 <birtles> ... and same for SVG but it just happens to scale nicely
03:50:32 <birtles> ... it's not SVG, it's about CSS replaced content
03:50:45 <birtles> ... it has an intrinsic size and we scale it up because the context in which it's being used says to
03:50:59 <birtles> DH: but you can find tune that scaling with a viewBox and preserveAspectRatio
03:51:06 <birtles> ... that's why we "add a viewBox"
03:51:17 <birtles> s/find tune/fine tune/
03:51:35 <birtles> JW: we'd say more than just scaling, but some other wording that didn't mention "viewBox"
03:52:01 <birtles> ... which will be more complicated but avoids talking about fake viewBoxs
03:52:07 <birtles> ED: as long as we get the same behaviour
03:52:22 <birtles> ... I think jwatt's text is more clear
03:55:47 <birtles> ACTION: Patrick to consider intrinsic sizing behavior (particularly when a viewBox is not provided) and follow-up test cases
03:55:48 <trackbot> Created ACTION-2999 - Consider intrinsic sizing behavior (particularly when a viewBox is not provided) and follow-up test cases [on Patrick Dengler - due 2011-03-10].
03:56:05 <jwatt> JW: another set of tests for sizing: https://jwatt.org/svg/tmp/embedded-sizing/embedded.html
03:56:30 <birtles> JW: we seem to diverge widely on these tests
03:57:10 <birtles> ED: can we put these in the UA sizing?
03:57:17 <birtles> JW: yes
03:58:05 <birtles> ... Patrick, those tests seem to show that IE's implementation of the CSS replaced elements stuff seems wrong
03:58:15 <birtles> ... especially further down where everything just collapses to nothing
03:59:10 <birtles> ... we've run out of time to talk about individual ones there
03:59:22 <birtles> ... but if you disagree with our implementation on any of those can you get back to me and I'll explain
04:01:11 <ed> Topic: Automatic image sizing
04:02:06 <birtles> JW: currently the SVG <image> tag if you don't specify width/height they default to 0 and nothing is shown
04:02:11 <birtles> ... they're required
04:02:15 <Zakim> - +1.425.868.aabb
04:02:21 <birtles> ... no way to get the width/height to automatically resize to the image you're embedding
04:02:31 <birtles> ... we should do what CSS embedding algorithm
04:02:33 <birtles> ... but simpler
04:02:52 <birtles> ... one or both of width/height can be specified and we determine the width/height
04:03:03 <birtles> CL: is this for SVG 2nd ed or 2?
04:03:07 <birtles> JW: SVG2
04:03:20 <birtles> JW: I'd like the attributes to be optional
04:03:48 <birtles> ... we use the image aspect ratio to calculate the width/height
04:03:56 <birtles> DS: it's a breaking change
04:04:15 <birtles> CL: only if you're linking to images without specifying width/height
04:04:22 <birtles> DS: which I've done
04:04:41 <birtles> JW: I think the value of this is high enough that we should just go ahead and do this
04:05:02 <ChrisL> DS: I did that to force preload of images
04:05:19 <ChrisL> JW: Use visibility: hidden in future
04:05:56 <birtles> CM: I can imagine someone relying on that behaviour because they're going to animate it out
04:06:16 <birtles> ... (i.e. relying on it becoming 0, 0)
04:06:30 <birtles> DS: I usually make the attributes 0, 0
04:07:15 <Zakim> disconnecting the lone participant, +1.649.363.aaaa, in Team_(svg)02:34Z
04:07:16 <birtles> ... this does break the idea of a rect with no width/height is 0,0
04:07:19 <Zakim> Team_(svg)02:34Z has ended
04:07:21 <Zakim> Attendees were +1.649.363.aaaa, +1.425.868.aabb
04:07:38 <heycam> Zakim, room for 3?
04:07:40 <Zakim> ok, heycam; conference Team_(svg)04:07Z scheduled with code 26631 (CONF1) for 60 minutes until 0507Z
04:07:46 <birtles> JW: but rectangles don't embed resources
04:08:00 <birtles> DS: I think your rationale is perfectly reasonable
04:08:20 <birtles> ... I think this will be much more user-friendly
04:08:22 <birtles> CM: I agree
04:08:32 <birtles> ... is this for rasters and SVGs?
04:08:44 <birtles> JW: anything that can be embedded by an image tag that has an intrinsic size
04:08:47 <AD> AD has joined #svg
04:08:55 <birtles> DS: how about an SVG with % width/height
04:09:02 <birtles> ... would it act the same as an HTML img element?
04:09:09 <birtles> JW: yes, but I need to look into it
04:09:14 <birtles> ... I want to simplify what CSS is doing
04:09:29 <birtles> ED: what does Tiny say about %s, are they intrinsic?
04:10:01 <birtles> s/ED: what/JW: what/
04:10:43 <birtles> JW: I don't particularly like the idea of resources that don't know what they're getting put into
04:10:55 <birtles> ACTION: Jonathan to come up with text for automatic image sizing
04:10:55 <trackbot> Created ACTION-3000 - Come up with text for automatic image sizing [on Jonathan Watt - due 2011-03-10].
04:11:14 <ChrisL> kiriban!
04:13:15 <birtles> RESOLUTION: For SVG <image> missing an explicit width/height we will take in account the intrinsic dimensions/aspect ratio of the resource being embedded
04:13:31 <birtles> ED: this is not just for image
04:13:38 <birtles> ... there's feImage and potentially other places
04:13:42 <birtles> ... animation element
04:14:16 <birtles> DS: so bbox will clearly get the width/height
04:14:18 <ed> foreignObject too
04:14:33 <birtles> ... however, what about getting the attribute
04:14:38 <birtles> ... 0? null? undefined?
04:14:51 <birtles> CM: you'd get empty
04:14:58 <birtles> ... it wouldn't affect the DOM
04:15:39 <birtles> ... it should do whatever we do for other automatic values
04:16:18 <birtles> ED: currently we'd just create an object on the fly for cases like that
04:16:48 <birtles> DS: if you change the href if would also change
04:16:57 <birtles> ... do we need to put that in the spec?
04:17:01 <ed> s/cases like that/cases like image without width, and you tried to fetch image.width.baseVal.../
04:17:18 <birtles> JW: I don't think that's necessary but it might be helpful as a note
04:17:30 <birtles> ... but you should apply the same rule with a new image
04:17:41 <birtles> DS: "even if the resource should change"
04:18:19 <ed> trackbot, end telcon
04:18:19 <trackbot> Zakim, list attendees
04:18:19 <Zakim> sorry, trackbot, I don't know what conference this is
04:18:20 <trackbot> RRSAgent, please draft minutes
04:18:20 <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/02-svg-minutes.html trackbot
04:18:21 <trackbot> RRSAgent, bye
04:18:21 <RRSAgent> I see 9 open action items saved in http://www.w3.org/2011/03/02-svg-actions.rdf :
04:18:21 <RRSAgent> ACTION: Cameron to write a proposal for allowing shorthand presentation attributes [1]
04:18:21 <RRSAgent>   recorded in http://www.w3.org/2011/03/02-svg-irc#T20-48-38
04:18:21 <RRSAgent> ACTION: Jonathan to Get Daniel to talk to David about making a new harmonized animations spec [2]
04:18:21 <RRSAgent>   recorded in http://www.w3.org/2011/03/02-svg-irc#T01-14-31
04:18:21 <RRSAgent> ACTION: Erik to bring up the one true animation spec on the fx call [3]
04:18:21 <RRSAgent>   recorded in http://www.w3.org/2011/03/02-svg-irc#T01-20-31
04:18:21 <RRSAgent> ACTION: Cameron to bring up the CSS-animations-targetting-SVG-attribtues in the next FX telcon [4]
04:18:21 <RRSAgent>   recorded in http://www.w3.org/2011/03/02-svg-irc#T01-35-00
04:18:21 <RRSAgent> ACTION: Erik to work on removing the margins and put some proposed text for how to deal with the proposed filter regions into the filters spec [5]
04:18:21 <RRSAgent>   recorded in http://www.w3.org/2011/03/02-svg-irc#T02-11-40
04:18:21 <RRSAgent> ACTION: Erik to follow up Dino about the shorthand syntax for filter effects [6]
04:18:21 <RRSAgent>   recorded in http://www.w3.org/2011/03/02-svg-irc#T02-12-17
04:18:21 <RRSAgent> ACTION: Doug to add some additional clarification to the intrinsic sizing part of the spec [7]
04:18:21 <RRSAgent>   recorded in http://www.w3.org/2011/03/02-svg-irc#T03-41-27
04:18:21 <RRSAgent> ACTION: Patrick to consider intrinsic sizing behavior (particularly when a viewBox is not provided) and follow-up test cases [8]
04:18:21 <RRSAgent>   recorded in http://www.w3.org/2011/03/02-svg-irc#T03-55-47
04:18:21 <RRSAgent> ACTION: Jonathan to come up with text for automatic image sizing [9]
04:18:21 <RRSAgent>   recorded in http://www.w3.org/2011/03/02-svg-irc#T04-10-55