22:01:00 <RRSAgent> RRSAgent has joined #svg
22:01:00 <RRSAgent> logging to http://www.w3.org/2012/01/13-svg-irc
22:01:03 <heycam> RRSAgent, this meeting spans midnight
22:01:13 <heycam> Meeting: SVG WG Sydney 2012 F2F day 4
22:01:16 <heycam> Chair: Erik
22:01:28 <stakagi> stakagi has joined #svg
22:02:24 <ed> Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda
22:04:24 <birtles> birtles has joined #svg
22:14:12 <heycam> ScribeNick: heycam
22:14:14 <heycam> Topic: Web Animations
22:14:30 <birtles> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/Animations/WebAnimations
22:14:59 <cyril> cyril has joined #svg
22:16:47 <heycam> BB: the last thing I wanted to put forward was the idea of making this Web Animations spec
22:16:52 <heycam> … which covers both SVG and CSS animations
22:17:02 <heycam> … and as was suggested, I think by Dean or someone, also a JS API
22:17:08 <heycam> … in addition to what we already have
22:17:20 <heycam> … you can see the basic ideas there [in thel ink]
22:17:47 <heycam> … there'd be two syntaxes, and along the lines of Filter Effects, it'd probably be that the features available in the CSS syntax would be more limited than those available in the element syntax
22:17:50 <heycam> … that's the basic idea
22:18:06 <heycam> … I've written a few very draft ideas, already just talking with Rik I think I've overhauled large parts of those ideas already
22:18:18 <heycam> … I'll pick out a couple of points
22:18:31 <heycam> … one would be that animation should be able to target more than one element, SVG Animations are limited in that regard at the moment
22:18:36 <heycam> … e.g. we might have a select="" attribute
22:18:45 <heycam> … that's one example of the sort of things I'd add
22:18:45 <cyril> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/Animations/WebAnimations
22:19:14 <heycam> … also you can use an animation defined using an element syntax, reference it using the CSS animation-name property
22:19:32 <heycam> … also talked with Rik and Vincent about how SVG animations are limited in that they can only target one attribute at a time
22:19:41 <heycam> … if you want to target more than one, you need another animation
22:19:47 <heycam> … that's also something we could possibly address here
22:19:58 <TabAtkins> This is relevant to my interests, and I'd like to be involved in seeing it through.  (Shane too, if he's not there today.)
22:20:00 <heycam> … I have a couple of draft ideas here, maybe a semicolon separated list of attribute names
22:20:13 <heycam> … that idea of being able to target more than one attribute/property at a time might be useful
22:20:18 <heycam> … especially with aligning with CSS animations
22:20:33 <heycam> … one issue that I think I'd like to think about is backwards compat
22:21:00 <heycam> … I originally was proposing something separate to what we already have in SVG animations, deprecating what we have and replacing it with something that is not backwards compatible
22:21:12 <heycam> … it's more aligned with CSS animations, but it draws on the learning from SVG's SMIL animation heritage
22:21:15 <heycam> … that was my initial proposal
22:21:32 <heycam> … but I think Cameron suggested that he'd like to see if we could keep backwards compatibility
22:21:42 <heycam> … that's one of the bigger questions
22:21:50 <heycam> … is it ok to make something new, and deprecate the old
22:22:06 <heycam> … or is it important to build on what we have, recognise that that might limit how much we can simplify and align with CSS
22:22:11 <heycam> … maybe that's something we can't answer right now
22:22:15 <heycam> … we need to do more investgation
22:22:40 <heycam> … but I'd be keen to hear everyone's views on backwards compatibility and how important is that, how feasible is it to develop new elements
22:22:52 <heycam> ED: I don't think we can drop current SVG animation support from our implementation
22:23:06 <heycam> … animateTransform is used, animateColor not so much, animateMotion is useful but not used so much
22:23:14 <heycam> BB: I'm thinking about deprecating <animate> as well
22:23:23 <heycam> … so this proposal is for something completely separate
22:23:29 <heycam> … there are subtle differences between CSS and SVG animations
22:23:34 <heycam> … such as rounding behaviour is different
22:23:46 <heycam> … if we want to keep our existing syntax, how can we align with CSS and keep backwards compat
22:23:56 <heycam> … there may be a way to do that, we could have a flag that triggers the different behaviour
22:24:09 <heycam> … but the alternative would be to come up with new elements
22:24:31 <heycam> RC: maybe you could define it in such a way, that someone can write a library that implements the new syntax based on the old syntax
22:24:54 <heycam> BB: the main situation I'm interested in is when you don't have script
22:25:00 <heycam> … that's when you really need declarative animation
22:25:03 <heycam> CC: I like some of the ideas
22:25:15 <heycam> … having one element for the animation, <animate> only, that's fine
22:25:24 <vhardy> vhardy has joined #svg
22:25:24 <heycam> … I like adding selectors, possibilities to target multiple attributes
22:25:33 <heycam> … but the general idea of redesigning something new, that's the thing I don't like
22:25:39 <heycam> … I think we could start with the <animate> element and augment it
22:25:44 <heycam> … so it's easier to use
22:25:55 <heycam> … extend its behaviour so it can do <set>, etc., but not start from scratch
22:25:59 <heycam> BB: what do you think about naming things?
22:26:04 <heycam> … one example here is iteration-count
22:26:08 <heycam> … in SVG it's repeatCOunt
22:26:12 <heycam> s/repeatCOunt/repeatCount/
22:26:25 <heycam> CC: it's fine, we can duplicate the attribute if we want to
22:26:53 <heycam> BB: is it fine to allow also iteration-count and define how it overrides with repeatCount?
22:27:07 <heycam> ED: the only example similar to this I can think of is xml:id and id, which wasn't too popular
22:27:13 <heycam> CC: personally I wouldn't mind having different naming
22:27:28 <heycam> … as long you don't have to store the two different attributes
22:27:33 <heycam> CM: I think you would have to though
22:27:35 <heycam> … the DOM would require you to
22:27:52 <heycam> BB: you could define iteration-count, and if both are used on the element then iteration-count wins
22:28:03 <heycam> … the syntax might differ too, indefinite vs infinite
22:28:10 <heycam> RC: why would you not just make the syntax the same?
22:28:52 <heycam> … and the name?
22:28:58 <heycam> [iterationCount vs animation-iteration-count]
22:29:41 <birtles> <animate animation-iteration-count="" animation-timing-function="" animation-delay="" ... />
22:29:49 <heycam> CM: I don't want to break the identity between presentation attribute names and property names
22:30:19 <heycam> BB: if we match the names exactly, it forces you to have the same behaviour and parsing
22:30:24 <heycam> VH: as the CSS properties?
22:30:25 <heycam> BB: yes
22:30:32 <heycam> CM: which might be a good thing
22:31:07 <TabAtkins> If it's desired that we have identical names between CSS and SVG, that pretty much requires matching CSS at this point, given relative usage.
22:31:29 <heycam> CC: CSS Animations is still a draft, right?
22:31:34 <heycam> CM: there is content out there
22:31:38 <heycam> VH: still prefixed though
22:31:44 <TabAtkins> But I don't think it's a good thing to require "animate" prefix on every attribute of an <animate> element.  The prefix namespaces the CSS property, but the *element* namespaces the attribute.
22:32:13 <heycam> TabAtkins, yeah, I think that's Brian's argument. OTOH there are cognitive advantages to using *exactly* the same property names/values as CSS.
22:32:17 <TabAtkins> CSS is almost certainly *not* able to change its names at this point, unless there's a major problem.  "To match an unwritten SVG proposal" isn't a major problem.
22:32:40 <heycam> TabAtkins, are implementations deployed that use unprefixed names?
22:32:46 <heycam> (or content?)
22:33:27 <TabAtkins> No unprefixed impls yet, but there's unprefixed *content* out there that we'd like to match unless there's a good reason not to, plus tons and tons of tutorial and instructional material using the current names.
22:33:28 <heycam> CC: it's frustrating that CSS animation is not more aligned with SVG animation on simple things like whether floor or round is used for integer interpolation
22:33:39 <heycam> VH: as a group, we should document these issues, send them to the FX taskforce
22:33:47 <heycam> … say we feel they should be aligned, request a change to CSS Animation
22:33:58 <TabAtkins> Cyril: Blame Apple for coming to the WG with a fully-formed and implemented proposal instead of starting discussion early. :/
22:34:06 <heycam> CC: I can understand they don't want SMIL intervals etc., but in the spirit where you want to round trip between one and the other...
22:34:23 <cabanier> cabanier has joined #svg
22:34:52 <heycam> VH: Brian could you draft a list of things we ask of CSS Animations to change, like the rounding stuff?
22:35:15 <TabAtkins> (Details like rounding *are* potentially changeable on the CSS side.)
22:35:16 <heycam> BB: with what scope?
22:35:28 <heycam> … it's almost impossble to change names, rounding behaviour there is some hope of changing
22:35:50 <heycam> VH: the message could just be "here are differences" and a pointer to your document
22:35:59 <heycam> BB: I think the rounding is the most significant issue
22:36:11 <TabAtkins> (Names can *often* be changed, but Animations are pretty mature at this point.  They should have been CR *long* ago, but the editors stopped working on them.)
22:36:58 <heycam> CM: we should identify the features that prevent us from extending/aligning while keeping the same name <animate>
22:37:28 <heycam> ACTION: Brian to identify things that prevent us from having <animate> align with CSS Animations, and present them as change suggestions for CSS Animations in FXTF
22:37:29 <trackbot> Created ACTION-3223 - Identify things that prevent us from having <animate> align with CSS Animations, and present them as change suggestions for CSS Animations in FXTF [on Brian Birtles - due 2012-01-20].
22:39:00 <heycam> BB: another minor one is indefinite vs infinite
22:39:05 <heycam> … that's something we could fix on our side
22:39:22 <heycam> VH: indefinite is used for begin="" as well
22:39:38 <heycam> BB: that's where I think we should deviate from SMIL
22:40:23 <heycam> CC: we should encourage authors to use the updated syntax, but existing implementations would still need to support the old stuff
22:40:35 <heycam> … having a note in the spec for authors about this would be good
22:41:10 <heycam> BB: the rest I think we talked about yesterday, obviating the need for animateTransform, animateColor
22:41:25 <TabAtkins> (We have similar cases in CSS where some legacy syntax is explicitly allowed as an alias, but authors have a MUST NOT requirement against using it.
22:41:26 <heycam> VH: the reason we had for animateColor is that there are properties that take colors and fill patterns
22:42:18 <heycam> … animateColor indicates that they're just colours
22:42:25 <heycam> CM: you don't need to indicate that though
22:42:35 <heycam> … you know you have two colour values, it's clear how to interpolate
22:42:55 <heycam> CC: for animateMotion, in GPAC the way I implemented it is just using <animate> with a pseudo attribute called "motion transform"
22:43:09 <heycam> BB: that's the direction I'm interested in, partly because if we want to introduce motion animation to CSS animation, it would make it easier
22:43:18 <TabAtkins> I think that's a good approach.
22:43:19 <heycam> … CSS Animations doesn't have separate <animate>, <animateMotion>, etc.
22:43:28 <heycam> … if we can do it just with <animate>, it's easier to bring across to CSS Animations
22:43:50 <heycam> CC: in the page it says it should also be possible to animate all colour stops of a gradient at the same time?
22:44:24 <heycam> BB: yes, you can't do that in SVG
22:44:27 <heycam> CM: but you will be able to
22:44:32 <heycam> … because we will support css3-image
22:45:26 <heycam> BB: the main thing I want to get out of this session is some consensus on direction
22:45:30 <heycam> … and then hammer out details later
22:45:35 <heycam> … Vincent's already agreed to help me with that
22:45:41 <heycam> VH: I have a question on <set>
22:46:05 <heycam> … there was a proposal to have a timing element like <set>, and instead of being an animation element like SMIL, it would actually do a real DOM setAttribute operation
22:46:32 <heycam> … one difficulty would be what happens if you have two of these, you'd need to define priority
22:46:46 <heycam> … it could be good for non-scripted situations
22:48:01 <heycam> … but that's a separate discussion
22:48:41 <heycam> BB: moving on, I was thinking of adding an element for timing containers, but I don't think that's such a great idea now
22:48:59 <heycam> … one suggestion was to add a timeContainer attribute on SVG container elements like <g>
22:49:10 <heycam> … I'll work on that
22:49:20 <heycam> … but some way of specifying par/seq time containers is what I'd like
22:49:21 <cyril> http://wam.inrialpes.fr/timesheets/
22:49:57 <heycam> BB: I would like to work out how to align events
22:50:14 <heycam> … maybe making TimeEvent a subinterface of AnimationEvent
22:50:31 <heycam> VH: do any implementations let you use SVG animations target HTML?
22:50:41 <heycam> BB: yes, Gecko lets you target properties of HTML elements from SVG animation elements
22:51:08 <heycam> ED: Opera doesn't, but we could
22:51:26 <heycam> BB: that's another question, whatever we define it should be able to target HTML as well
22:51:33 <heycam> … and then for HTML, whether targetting properties is enough there
22:51:35 <cyril> Tab, does WebKit allow you to animate HTML properties with SVG animation elements ?
22:51:44 <heycam> … and think there's a bit of opposition to targeting HTML attributes
22:52:03 <TabAtkins> I highly doubt it, but it would be easy to test.
22:52:37 <heycam> CM: I want to get a sense of whether HTML folks would want this new <animate> to be able to be put directly in HTML documents without SVG around it
22:53:15 <heycam> BB: we can start with just allowing it in SVG, and if it proves useful, see if HTML folks want to allow it directly
22:53:33 <heycam> … a different discussion perhaps, what to do with DOM storage
22:53:40 <heycam> … the messy baseVal/animVal
22:53:51 <TabAtkins> Burn it with fire?
22:53:54 <heycam> … I wonder what is useful to authors
22:54:08 <heycam> … I find I just use animVal
22:54:13 <heycam> ED: I find baseVal more useful
22:54:20 <heycam> CM: at least when you're modifying you need baseVal
22:54:26 <heycam> BB: but yes, what do we need out of an SVG DOM APi
22:54:30 <TabAtkins> I find that I don't use either, and then things break, and then I cuss until I remember and choose one to use semi-randomly.
22:54:56 <heycam> CM: we will be having a broader discussion about SVG DOM improvments
22:55:12 <heycam> … I don't think those improvements will impact the rest of your proposals here
22:55:19 <ed> s/ find baseVal more useful/ find baseVal more useful because you can read and write to it, unlike with animVal which is readonly/
22:55:48 <shepazu> I suggest we get in touch with Mike Bostock, DmitriB and other animation script lib authors to ask what they want to see in an API
22:56:16 <heycam> BB: seems like we should move forward with this then
22:56:31 <heycam> CM: I would like to hear what the non-SVG FXTF people feel though
22:56:48 <heycam> shepazu, yes good idea
23:14:43 <heycam> RESOLUTION: We will work on a proposal for a Web Animation spec that underlies SVG and CSS Animations, and write up a summary document on which features ought to be supported in CSS Animations with use cases and examples
23:15:20 <heycam> ACTION: Brian to work on the Web Animation spec proposal for the May FXTF meeting
23:15:21 <trackbot> Created ACTION-3224 - Work on the Web Animation spec proposal for the May FXTF meeting [on Brian Birtles - due 2012-01-20].
23:16:14 <RRSAgent> I have made the request to generate http://www.w3.org/2012/01/13-svg-minutes.html shepazu
23:16:28 <heycam> Topic: moar SVG2 Requirements
23:17:32 <birtles> (for ChrisL: http://brian.sol1.net/svg/demo/button.svg)
23:17:53 <ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Look_at_making_paced_animation_easier
23:18:35 <cyril> RRSAgent, pointer please
23:18:35 <RRSAgent> See http://www.w3.org/2012/01/13-svg-irc#T23-18-35
23:18:38 <ed> ISSUE-2281?
23:18:38 <trackbot> ISSUE-2281 -- Look at making paced animations easier -- raised
23:18:38 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2281
23:19:35 <cyril> Doug, do you remember anything on this issue that you raised?
23:19:44 <ChrisL> ChrisL has joined #svg
23:19:48 <heycam> ED: are paced animations hard to write at the moment?
23:19:54 <heycam> BB: it's mostly just for motion animation at the moment
23:19:57 <heycam> … not sure what the particular need is here
23:21:16 <heycam> CM: so this would allow specifying a speed for the motion animation
23:21:29 <heycam> … since you don't know what dur you would specify
23:21:32 <ChrisL> rrsagent, make logs public
23:21:41 <ChrisL> zakim,this meeting spans midnight
23:21:44 <ChrisL> rrsagent, here
23:21:44 <RRSAgent> See http://www.w3.org/2012/01/13-svg-irc#T23-21-44
23:21:44 <heycam> BB: my guess is that cases where you don't know what the path length is, is when you are doing scripted path generation
23:22:20 <shepazu> [[ pace="10px/1s" ]]
23:23:04 <heycam> BB: and if that's so, you can just do getComputedPathLength [or whatever it is]
23:23:42 <heycam> DS: yes it's true you could use that method, if you have a <path>
23:23:48 <heycam> … again that calls for script
23:24:00 <heycam> … the path might change, then you need to do getComputedPathLength every time
23:24:14 <heycam> … if the path is moving, and you want the animated object to move at a steady pace it will be more of a pain
23:24:33 <heycam> … also if you have an animation that is not along a path, you could not do that
23:24:43 <heycam> … e.g. if you just want to move an object to the right [at a certain speed]
23:25:08 <heycam> … you could also see this being used when animating colour, if you want an animation to be synced with another of a certain duration
23:25:23 <heycam> BB: I was thinking when you have <mpath> that's interesting, because the target path might be changing outside of your control
23:27:16 <heycam> CM: is it a problem that instance times change because a path length will change, and an animation along the path is specified using a speed?
23:27:27 <heycam> BB: instance times already can change in the SMIL model, that's one of the more complex parts of SMIL
23:27:39 <heycam> … maybe it would be bad that instance times get updated every animation tick
23:29:27 <heycam> … can <mpath> target an animated path?
23:29:28 <heycam> ED: yes
23:30:14 <heycam> CM: probably not the most important feature, but let's accept it (and prioritise later)
23:30:44 <heycam> BB: this would introduce some coupling between the animation and the timing model
23:30:53 <heycam> … it's not what you normally do, but if it's useful it might be worth it
23:31:14 <heycam> RESOLUTION: We will support motion animation of a specified speed in SVG2.
23:31:21 <heycam> -- break for 15 minutes --
23:47:52 <ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Basic_SVG_UI_enhancements
23:48:29 <vhardy> ScribeNick: vhardy
23:48:45 <vhardy> ed: SVG UI enhancements
23:49:10 <vhardy> heycam: we discussed this before and decided to not do UI in the zoom/pan features.
23:49:22 <vhardy> ed: this is a bit different.
23:49:30 <vhardy> cl: this is not something we should be adding.
23:50:01 <vhardy> ... it is a huge amount of work and not necessarily what people need.
23:50:39 <vhardy> ... the zoom/pan we talked about and we may add through the 'controls' attribute to switch it on/off.
23:50:57 <vhardy> .. this was rejected earlier.
23:51:18 <vhardy> ... for layers, we already have groups and you can switch on/off layer by toggling visibility. 
23:52:39 <vhardy> RESOLUTION: SVG 2.0 will not address the "Basic SVG UI enhancements" requirement.
23:53:17 <vhardy> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Specify_that_unknown_elements_are_treated_as_.3Cg.3E_elements_for_the_purpose_of_rendering
23:53:17 <ed> the layer UI, that's <g>, which already has UI if you use browser debugging tools, e.g dragonfly, firebug or whatever 
23:53:41 <ChrisL> s/ed: SVG UI/topic: SVG UI
23:54:06 <vhardy> Topic: unknown elements treated as <g>
23:54:40 <vhardy> ed: this is asking the opposite of what we require. We say it is display none, so the children do not display.
23:54:46 <TabAtkins>  I suppose that's like HTMLUnknownElement acting like <span>?
23:55:30 <vhardy> heycam: what is described here is similar to what HTML does.
23:56:02 <vhardy> ... I do not think this proposal, or the current way, are completely free of what content is out there.
23:56:08 <vhardy> ed: I do not think this is a good idea.
23:56:17 <vhardy> ... I think that not showing anything is reasonnable.
23:56:28 <vhardy> ... if you want so kind of fallback, we could do it some other way.
23:56:39 <vhardy> cl: this is related to the switch requirement later on.
23:56:49 <vhardy> ed: we resolved to fix the issues with <switch>.
23:57:06 <vhardy> .. by saying the requiredFeatures on unknown elements is still looked at.
23:57:31 <vhardy> cyril: the use case is fallback for connectors.
23:57:40 <cabanier> cabanier has joined #svg
23:58:05 <vhardy> ... it is not a valid use case because an old browser, when encountering a connector, will not render the inside of a connector, and new browsers, which know connectors, will render them.
23:58:46 <vhardy> cl: I have preference the <switch> way to provide a fallback (rather than the children way of HTML).
23:58:59 <vhardy> ... I prefer the test statements that <switch> provide.
23:59:08 <vhardy> s/provide/provides
23:59:20 <vhardy> heycam: but people dislike featureString
23:59:33 <ChrisL> as long as the tests work, which is not really the case with feature strings
23:59:35 <heycam> s/featureString/feature strings/
23:59:54 <vhardy> heycam: I slightly hesitate to change the behavior, but I do not mind to mind.
00:01:02 <vhardy> ds: I can see both ways. 
00:01:31 <shepazu> q+
00:02:16 <vhardy> cl: rendering children has not worked well in HTML with <object>. In some cases browsers rendered the whole lot, in some cases they rendered nothing. That was both an implementation and specification issue. In general, it makes it hard to see what the different alternates are. I would rather have different trees taht are the alternates.
00:02:24 <vhardy> s/taht/that
00:02:54 <vhardy> ds: has it become an anti-pattern.
00:03:01 <vhardy> cl: it has become an anti-pattern.
00:03:23 <vhardy> ds: I do not think it is an anti-pattern. New elements are just treated that way in HTML5.
00:04:00 <vhardy> cyril: I think it works well in HTML because of the CSS box model. In SVG, you need explicit positioning of the object. If you way it works like a <g>, do you need to accept the transform attribute.
00:04:06 <vhardy> ds: I do not understand your point.
00:04:53 <vhardy> cyril: if you do not know an element and render its children instead of that element: it makes sense in HTML because it will not disturb the whole layout because it is dynamic. In SVG, where everything is positioned, I think it distrubs the whole rendering.
00:05:09 <vhardy> cl: in HTML, the unknown element is treated as a span.
00:05:53 <vhardy> ds: in the case of <connector> and it does not render as a connector, but if inside that you have a path element that draws the connector, then you have a fallback. The transforms would be in the path or in the subtree. 
00:06:04 <ChrisL> s/n HTML, the unknown element is treated as a span./in CSS, the default styling for unknown elements is display: inline,which works ok for text
00:06:14 <vhardy> ... in HTML, if you have something that is replacement content, it make a box around itself. In SVG, it is just rendered.
00:06:29 <vhardy> heycam: I think it is plausible to create fallback content that renders fine.
00:07:12 <vhardy> cc: I do not know how to explain differently. We are talking about elements in the SVG namespace? 
00:07:26 <vhardy> cl: what happens with an HTML parsing? Isn't it going back to HTML?
00:07:37 <vhardy> cmc: I think it stays in SVG.
00:07:55 <vhardy> cc: if the elements are metadata, we do not want that to be rendered.
00:08:08 <vhardy> ds: you could put display:none, or put it in a <defs> element.
00:08:43 <ChrisL> what about <newFooElement><title>text</title><desc>blah blah</desc> .... </newFooElement>
00:09:26 <vhardy> cmc: in this example, <title> and <desc> do not get rendered.
00:10:05 <vhardy> ds: if we did not have <textPath> and added your proposal, and then we added <textPath> then the text under it would display.
00:10:32 <vhardy> cmc: I just tested the HTML5 parser, the unknown element gets put in the SVG namespace.
00:10:37 <heycam> http://livedom.validator.nu/?%3C!DOCTYPE%20html%3E%0A%3Csvg%3E%0A%20%20%3Cunknown%3E%3C%2Funknown%3E%0A%3C%2Fsvg%3E%0A%3Cscript%3Edocument.write(document.getElementsByTagName(%22unknown%22)%5B0%5D.namespaceURI)%3C%2Fscript%3E
00:11:28 <vhardy> cmc: in HTML, nearly all elements are container elements. In SVG, most elements are not container elements. It's more likely that a new element is not going to render its children in SVG>
00:11:44 <vhardy> ds: I see what you are saying, but is that a reason to keep the current behavior.
00:11:50 <vhardy> cc: I can go either way.
00:12:04 <vhardy> ... is there content outside that relies on unknown element not being rendered?
00:12:23 <vhardy> cl: we encouraged people to put elements in their own namespace. In practice, people did not do that.
00:12:36 <vhardy> .. I suspect we would find usage of that.
00:13:29 <vhardy> ds: I think it is compatible with HTML and it gives us an extensibility mechanism that does not require using <switch>. It lets people do content in an intuitive way they are used to, regardlesss of how it worked in the past. It is a change for SVG, from SVG 1.1
00:13:53 <vhardy> ... it is not clear if it is beneficial for all UA. From SVG 2.0, we could use that extensibility mechnism.
00:14:53 <vhardy> ed: I am not sure. To me, it would be confusing. Some UA would do the old way, some would do the new way, and then you would need a script to deal with the difference. What is hte benefit?
00:15:04 <vhardy> ds: you would have to do a short script.
00:15:11 <vhardy> ed: but you could do a scirpt to do what you want.
00:15:25 <TabAtkins> Note that, for most authors, the only UAs that matter are browsers.
00:15:32 <vhardy> ds: I think that script would be short lived (3-5 years). As opposed to 'everything in the future"
00:15:59 <vhardy> ed: I do not know how much would break.
00:16:14 <vhardy> cmc: we could resolve for it under the provision that it does not break existing content.
00:16:30 <vhardy> cl: it is tied to the item on <switch> and not using feature string.
00:17:01 <vhardy> ... I share ds 's concern that it does not work currently. I use <switch> a lot, but this is not the way I would like to do it.
00:17:25 <vhardy> ds: there are places where I would use switch, but I think that it would be handier to not have to use it for simple cases.
00:17:52 <vhardy> ds: I do not mind if we revisit this later. I would like for us to accept this and then reject it later and reverse if we find it is a bad idea.
00:18:20 <vhardy> cc: we could put it in the spec. and see if people think it will break their content. We could mark it at risk.
00:18:33 <vhardy> cmc: may be we can mark features that we are not entirely sure about.
00:18:43 <vhardy> ed: it would be nice to have more examples that show how it might be used.
00:18:57 <vhardy> cl: it would be find as a paragraph in the extensibility chapter. 
00:19:08 <vhardy> ed: it would be good to get this to work especially in the SVG in HTML context.
00:19:36 <vhardy> ds: it fits well with the web component model. Because we would not have to explicitly add the elements that they are talking about. They would simply work the way they are.
00:19:48 <vhardy> cc: let's not argue anymore. We have a consensus.
00:20:28 <vhardy> ed: I would be surprised if you could write a script that makes things work in older browsers and new ones. It is more complicated.
00:20:41 <vhardy> cc: we should find out how hard it woudl be for shims to work. 
00:20:54 <vhardy> ed: I would like to see a fallback script to understand how hard it would be.
00:21:06 <vhardy> ed: we could write a fallback script right now to see how it works.
00:21:14 <cyril> s/cc: we should find out/cl: we should find out/
00:21:24 <vhardy> ed: I think we could investigate it and accept if there are not issues.
00:22:50 <ChrisL> vh: torn on it, can see dougs point butits not a high priority item
00:25:54 <vhardy> RESOLUTION: Accept having unknown elements treated as <g> for the purpose of rendering. However, the groups wants community feedback on how much content would be impacted.
00:26:29 <vhardy> ACTION: Doug to write scripts showing how a shim could bridge the old and new behaviors for content under unknown elements.
00:26:30 <trackbot> Created ACTION-3225 - Write scripts showing how a shim could bridge the old and new behaviors for content under unknown elements. [on Doug Schepers - due 2012-01-21].
00:26:56 <ChrisL> topic: SVG copy/paste
00:26:57 <ed> s/It is more complicated./It is more complicated because you'd need to modify the DOM structure to get it to render, and that might affect other things too/
00:27:20 <vhardy> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Specify_how_SVG_graphics_and_text_are_copy.2Fpasted
00:27:34 <vhardy> Topic: Specify how SVG graphics and text are copy/pasted.
00:27:36 <ChrisL> http://www.w3.org/TR/SVG/mimereg.html
00:28:11 <vhardy> cl: if you look at the media type registration, I added stuff about copy/paste in response to feedback saying we needed to specify what happens with clipboard.
00:28:33 <vhardy> .. the Windows one is a string. The Mac one is saying that SVG is both an image an xml.
00:28:39 <ChrisL> Macintosh Universal Type Identifier code:
00:28:39 <ChrisL>     org.w3c.svg conforms to public.image and to public.xml
00:28:55 <vhardy> ... is this somethign the platform needs to do.
00:29:13 <vhardy> ... if pasting into an editor, you could do useful things with it.
00:29:26 <vhardy> ... it is not fully specify, but there is something there.
00:29:49 <vhardy> ed: I think we should not make it a requirement. It should be a 'should'. I think the UA should be left to decide to rasterize or not.
00:30:18 <vhardy> vhardy: I think that most clipboards allow you to copy in multiple formats.
00:30:20 <vhardy> ed: right.
00:31:00 <vhardy> ... in the way it works on Mac, you announce which formats you can generate, and the receiving application says the one it prefers, which is then the one generated by the app (from which the cut happens).
00:31:16 <vhardy> ... I think it is find to make recommendations, but I do nto think we should have a hard MUST requirement.
00:31:34 <ed> s/find/fine/
00:31:43 <TabAtkins> I disagree - web applications need to know what the format of the data is on the clipboard if they're going to deal with it.
00:31:45 <vhardy> cmc: I do not think we should be requiring special UA behavior for how content is selected.
00:32:20 <vhardy> ... there is a clipboard API spec, and there is a way to put things in the clipboard with type and content.
00:32:34 <heycam> http://dev.w3.org/2006/webapi/clipops/
00:33:37 <vhardy> cmc: this clipboard API allows you to say 'copy this string to the clipboard and interpret it as SVG'.
00:34:45 <vhardy> cmc: I think someone should look into the existing API to see if we need to specify anything additional.
00:35:03 <vhardy> .. it may be outside of our scope to add anything. We may need to suggest rasterization.
00:35:30 <vhardy> ... I am happy with the requirement saying how applications should behave if pasting SVG content in them.
00:35:36 <vhardy> cl: yes, but it should be more guidance.
00:37:15 <vhardy> RESOLUTION: Accept the requirement on how SVG graphics and text are copy/pasted for the SVG 2.0 specification, considering both non-normative and script API related requirements.
00:37:56 <vhardy> ed: there might be different behaviors between devices and user agent. For example, on a mobile you might want to copy just the text, and not the SVG as you would on a desktop.
00:38:34 <vhardy> Topic: consider removing the requirement for @widht and @height for <foreignObject>
00:38:36 <vhardy> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_removing_the_requirement_for_.40width_and_.40height_for_.3CforeignObject.3E
00:39:06 <vhardy> cl: for widht/height is put 'no' in the document because the box model needs the values. There is no automagic sizing.
00:39:41 <vhardy> ... but, if we are unifying the width/height properties with the width/height attributes, we could specify them with stylesheet, which would be fine and satisfy the requirment.
00:40:08 <vhardy> cl: the request is to have them not specified, and have that does not work.
00:40:23 <vhardy> cmc: isn't there shrink wrapping on absolutely positioned elements?
00:40:28 <vhardy> vh/cl: yes.
00:40:47 <vhardy> cmc: couldn't we have the same behavior for <foreignObject>?
00:40:50 <vhardy> cl: I guess we could.
00:41:01 <vhardy> cl: yeah, we could specify it that way.
00:41:24 <vhardy> cmc: ed has an ACTION to propose something.
00:41:32 <vhardy> ed: I think it would be nice to have that behavior.
00:41:53 <vhardy> cmc: if you want to include HTML content and you do not know how big it would be, that would be useful.
00:42:12 <vhardy> cl: if we want to rely on the shrink-wrap behavior, then that is fine.
00:42:48 <vhardy> cmc: I would be surprised if content rely on the widht/height in foreignObject defaulting to zero and not displaying if zero.
00:43:20 <vhardy> cl: it needs to be more speced out, but more tractable than I originally thought.
00:43:28 <vhardy> ed: I think we should accept the requirement.
00:43:32 <vhardy> cmc: I agree.
00:44:08 <vhardy> RESOLUTION: Accept the requirement to remove the requirement to have @widht and @height on foreignObject.
00:44:47 <vhardy> Topic: Consider the future of feature strings and the switch element.
00:44:48 <vhardy> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_the_future_of_feature_strings_and_the_switch_element
00:45:13 <vhardy> cl: we definitely need to do this. We changed the syntax twice. 
00:45:24 <vhardy> ... last time changed in SVG 1.1 2nd edition. 
00:45:41 <vhardy> ... I think <switch> is fine, but the feature strings need to be totally reworked.
00:46:10 <vhardy> RESOLUTION: Accept the requirement ot consider the future of feature strings and the switch element
00:46:35 <ed> ISSUE-2422?
00:46:35 <trackbot> ISSUE-2422 -- Define switch to work with unknown elements and processing behaviour for audio elements etc -- raised
00:46:35 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2422
00:46:36 <ChrisL> issue-2422?
00:46:36 <trackbot> ISSUE-2422 -- Define switch to work with unknown elements and processing behaviour for audio elements etc -- raised
00:46:38 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2422
00:47:23 <vhardy> Topic: consider treating audio separately to graphics.
00:47:24 <vhardy> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_treating_audio_separately_to_graphics
00:48:28 <vhardy> cl: we tried to do this in 1.2 tiny time frame. We had lots of discussion on display:none and visibility:hidden impacting audio. In general, we need a way to control audio separately and display/visibility do not seem to be the right controls. I would like to look at the HTML5 behavior.
00:48:51 <vhardy> cmc: I am wondering if there is a css property to set the volume.
00:49:01 <TabAtkins> There is not, but there could be.
00:49:21 <TabAtkins> We could either yoke this to Speech (probably not a good idea) or make a new one.
00:49:26 <vhardy> cl: there was in the aural CSS but there is not in the new work on text to speech done by Daniel Weck.
00:49:37 <ChrisL> tab, prefer the newone
00:50:04 <ChrisL> and in tiny..2 we had an audio-level property
00:51:49 <vhardy> cmc: we need to define how we turn audio off. I am not ready to accept any specific proposal yet.
00:52:39 <vhardy> RESOLUTION: SVG 2.0 will provide a way to control audio level and playback.
00:53:25 <vhardy> Topic: Consider adding new interface for easier use of positional property.
00:53:27 <vhardy> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_new_interface_for_easier_use_of_positional_properties
00:53:42 <ChrisL> s/SVG 2.0/SVG2/g
00:54:11 <vhardy> cmc: this is a way to get better positions out of MouseEvents, and I think we all agree.
00:54:41 <vhardy> RESOLUTION: SVG 2 will provide positioning information in MouseEvents.
00:55:18 <vhardy> Topic: Consider adding method to return array of declarative timeline
00:55:34 <vhardy> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_method_to_return_array_of_declarative_timeline
00:56:43 <vhardy> cmc: this relates to the scripting api for animation and we should deal with this as part of the Web animations work.
00:56:51 <vhardy> cl: I am not clear on what is asked.
00:57:07 <vhardy> cmc: he is asking to get the timeline information.
00:58:22 <vhardy> cmc: I would be in favor of exposing more information than we do currently about animation.
01:00:30 <vhardy> RESOLUTION: The WebAnimations proposal will provide an API to get animation timeline information (i.e., current state of the timing engine, running animations, pending animations , frozen animations etc...). SVG 2 will not address this requirement directly.
01:01:42 <vhardy> Topic: Consider adding API for saving and restoring SVG state.
01:01:43 <vhardy> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_API_for_saving_and_restoring_SVG_state
01:04:09 <vhardy> cmc: I was wondering how to address the requirement to turn a bit of SVG to PNG.
01:04:18 <cyril> Scribe: cyril
01:04:24 <cyril> ScribeNick: cyril
01:04:46 <cyril> CM: as part of that, to get that to work in FF, you can construct a data url out of the image and draw that in the canvas
01:05:17 <cyril> VH: a couple of months ago, it didnt work in webkit
01:05:25 <cyril> CM: in the recent builds, it works
01:05:37 <cyril> ED: you cant have anything external
01:05:47 <cyril> VH: why does it have to be a data url
01:06:25 <cyril> CM: because drawImage takes an HTML image element and that can only reference an entire document
01:06:57 <cyril> ... there was a recent fix in FF
01:07:25 <cyril> ... regardless of whether that works, if you want to do it by script, you'd want to serialize the current state
01:07:26 <ed> s/you cant have anything external/you cant have any external references AFAIK, so if you wanted to draw <svg><image xlink:href="foo.png"/></svg> into a canvas element then it would probably just ignore the external reference/
01:07:59 <cyril> ... including the computed style of every property and the animated value of every attribute
01:08:13 <cyril> VH: didn't we talk about XML serialization before
01:08:23 <cyril> ED: it doesn't give the animation state
01:08:46 <cyril> CC: you could use getPresentationTrait
01:09:03 <cyril> CM: yes or using animVal, it shouln't be difficult
01:09:50 <cyril> VH: CanVG was parsing the SVG and making rendering calls, because that wouldnt make the canvas dirty
01:10:14 <cyril> CM: I would say no to the req because it's not hard to do in a script
01:10:42 <cyril> RESOLUTION: SVG 2 will not add an API for saving and restoring the SVG state
01:11:15 <vhardy> ScribeNick: vhardy
01:11:24 <vhardy> Topic: CSS3 Color syntax in SVG
01:11:31 <vhardy> http://www.w3.org/Graphics/SVG/WG/wiki/index.php?title=SVG2_Requirements_Input&section=117
01:12:00 <vhardy> cl: we already resolved to accept this requirement in Seattle and I got an ACTION which I completed.
01:12:23 <vhardy> Topic: Align with CSS WG preserveAspectRatio
01:12:36 <vhardy> http://www.w3.org/Graphics/SVG/WG/wiki/index.php?title=SVG2_Requirements_Input&section=118
01:13:01 <vhardy> cl: this is in CSS image value spec. which we agreed to review. 
01:13:16 <vhardy> ... we also agreed to depend on that specification.
01:13:25 <ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Resolutions
01:13:33 <vhardy> cmc: where is the list of CSS modules that we will depend on?
01:13:43 <vhardy> cl: we went though this before.
01:14:02 <ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Resolutions#CSS_Spec_dependencies
01:14:32 <vhardy> RESOLUTION: SVG 2 will work with CSS image-fit.
01:14:47 <vhardy> Topic: Should be possible to determine intrinsic size of an image
01:15:00 <vhardy> http://www.w3.org/Graphics/SVG/WG/wiki/index.php?title=SVG2_Requirements_Input&section=119
01:15:12 <vhardy> cl: we talked about it earlier and agreed it was useful.
01:15:53 <vhardy> cmc: I am not sure if a dedicated API is needed. In HTML, people just create an Image, set its source, and then query the widht/height when loaded.
01:17:21 <vhardy> cl: because of our earlier decision on auto size images, this will work.
01:17:39 <vhardy> cmc: it is easier in HTML because the DOM is better.
01:17:48 <vhardy> cl: this should be addressed with our DOM work.
01:18:51 <vhardy> RESOLUTION: SVG 2 will not provide a separate interface to get image intrinsic size because it will be possible to query the size on the SVG image elements.
01:19:24 <vhardy> Topic: Consider adding convenience methods for currentScale/currentTranslate
01:19:42 <vhardy> http://www.w3.org/Graphics/SVG/WG/wiki/index.php?title=SVG2_Requirements_Input&section=120
01:20:10 <vhardy> --- LUNCH BREAK ---
01:34:02 <birtles> birtles has joined #svg
02:45:38 <stakagi> stakagi has joined #svg
02:57:58 <cabanier11> cabanier11 has joined #svg
02:58:10 <cabanier11> scribenick: cabanier
02:58:38 <cabanier> cabanier has joined #svg
02:58:49 <cabanier> scribenick: cabanier
02:58:58 <vhardy> vhardy has joined #svg
02:59:34 <cabanier> Topic: addconvenience methods for currentScale/currentTranslate
03:00:37 <cabanier> cm: we did say that we want to make it easy to get to zoom and pan
03:00:47 <cabanier> ed: might be good to pull those together
03:00:57 <cabanier> ed: get the two requirement together
03:01:30 <cabanier> cm: that was in the mapping discussion of the first day
03:01:44 <cabanier> ed: it might be nice. How difficult is it?
03:01:56 <cabanier> cm: viewbox is not exposed as a matrix
03:03:27 <cabanier> cm: currentscale/currenttranslate provides one that is seperate from the viewbox
03:03:54 <cabanier> does it make sense to keep distinction between zoom/pan and the viewbox
03:04:18 <cabanier> cm: what would these new methods affect?
03:04:45 <cabanier> cm: we can accept the requirement to say something to make it easier to get to zoom/pan
03:05:46 <cabanier> resolution: svg2 will make it easier to write a zoom/pan widget. possibly by adding convenience method to get scale/transfer
03:06:02 <heycam> s/transfer/translate/
03:14:20 <cabanier> (discussion on  panning and zooming)
03:14:45 <cabanier> bb: is up to the browser to optimize the behavior?
03:14:52 <cabanier> cm: yes
03:15:24 <cabanier> cm: suspendredraw is not good for situations where you only want to redraw a certain region
03:15:54 <stakagi> I have noticed my explanation was insufficient regarding http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#API_for_smooth_transition_action_of_zooming.2Cpannning.2Crotating 
03:16:05 <stakagi> Please give the comment to this subject.
03:16:41 <stakagi> This is another things about smooth transition.This data is about 10MB of huge SVG file. Originally, such a data is not suitable in terms of size. But I often look at such a data as a business-use of GIS or CAD data and they often tests the usability of these data using SVG viewer (browser) without tiling. Please see the zooming and pannning transition action.  As for this example, redraw is performed also in the midst of the transition.  On the other hand , t
03:16:42 <stakagi> his is not performed redraw (suspendRedraw-like). If we can built such UI, SVG is usable in this usecase. First, should such a transition effect be controllable by javascript? Is it suitable to use what kind of application programming interface? 
03:17:19 <cabanier> cm: at some point it is up to the browser to optimize the movements of shape
03:17:54 <cabanier> cm: in this case, if you set a clip when you start the panning and then just change the transform, hopefully the browser can optimize that
03:18:37 <cabanier> ed: this is work we did last year: http://www.newdesignworld.com/press/story/470436
03:19:02 <cabanier> ed: this is a press release talking how we optimized the browser
03:19:27 <cabanier> cm: file a bug with the browser if you find a case that is slow
03:20:13 <cabanier> bb: we did some optimizations too
03:20:49 <cabanier> topic: Align with CSS Value and Units
03:20:58 <cabanier> resolution: we already did that
03:21:24 <cabanier> topic: Gzip-compressed svg in data URIs
03:22:00 <cabanier> cl: it would need to be an update to the rfc that defines the data URI
03:23:47 <cabanier> resolution: this is outside of our charter. out of scope for SVG2
03:24:06 <cabanier> topic: Deprecate baseline-shift and use vertical-align instead
03:24:23 <cabanier> cl: I can see it but they are not quite the same
03:24:30 <cabanier> cl: we should go with what CSS is doing
03:25:00 <cabanier> cm: I agree. 
03:26:07 <cabanier> cl: I want to get rid of it
03:27:52 <cabanier> resolution: we will deprecate baseline shift and use vertical align instead in SVG2
03:28:08 <cabanier> topic: Media elements in SVG need ability to associate captions and description
03:28:25 <cabanier> cc: we already agreed to do that in HTML5
03:28:58 <cabanier> cc: I don't like this because it makes it hard to overlay graphics on top of video
03:29:04 <cabanier> cm: why is that?
03:29:32 <cabanier> cm: are you restricted to the 3 types of track?
03:30:16 <heycam> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#the-track-element
03:30:58 <cabanier> cm: there are 5 kinds
03:31:06 <cabanier> cc: but they are text tracks
03:32:14 <cabanier> ed: this is for a different group
03:33:14 <cabanier> cc: right now you have to use webvvt but it doesn't support xml/svg
03:33:53 <cabanier> bb: subtitles are often colored and animated in Japan
03:34:15 <cabanier> vh: this is why I thought that you could do this with webvtt
03:34:34 <cabanier> vh: what can we ask?
03:34:53 <cabanier> cc: I sent an email to create a more generic track interface
03:35:18 <cabanier> cc: people think webvtt should only be text
03:39:10 <cabanier> resolution: SVG2 will allow video elements to have captions, tracks, etc
03:39:18 <cyril> http://lists.w3.org/Archives/Public/public-web-and-tv/2011Aug/
03:39:46 <cabanier> topic: Consider adding a 'inverse' value to clip-rule
03:39:59 <ed> ISSUE-2354?
03:39:59 <trackbot> ISSUE-2354 -- Consider adding a 'inverse' value to clip-rule -- raised
03:39:59 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2354
03:40:34 <cabanier> cl: you do need to know what the outside is
03:41:02 <cabanier> cm: it is convenient to write it that why
03:41:37 <cabanier> rc: this seems to be what mask is for
03:42:31 <cabanier> vh: this would requires us to do all the geometry
03:43:04 <cabanier> vh: we can take the requirement
03:43:11 <cabanier> vh: but you can use the mask
03:46:50 <stakagi> stakagi has joined #svg
03:50:42 <cabanier> cc: ask Tav why they implemented this in inkscape
03:51:23 <cabanier> cc: inkscape has a use case for it
03:52:45 <cabanier> resolution: since it easy to do in masks and difficult to do in geometry, we will not make it part of SVG2
03:53:46 <cyril> s/why they implemented/how they would implement/
03:54:41 <cabanier> topic: Consider allowing the 'clip' property to reference any element, not just 'clipPath'
03:54:50 <ed> ISSUE-2355?
03:54:50 <trackbot> ISSUE-2355 -- Consider allowing the 'clip' property to reference any element, not just 'clipPath' -- raised
03:54:50 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2355
03:54:59 <cabanier> cm: did we already talk about that?
03:56:43 <cabanier> rc: this would be handy to have
03:56:55 <cabanier> cm: people might think that the stroke is part of the mask
03:57:05 <cabanier> rc: that is true
03:57:12 <cabanier> cm: it would indeed be handy
03:58:11 <cabanier> resolution: we should allow <g> inside of a clip path
03:58:30 <cabanier> resolution: we will allow clip to point to regular elements
03:58:43 <heycam> s/clip to/clip-path, mask and similar properties/
03:59:20 <heycam> s/regular/to regular/
04:00:59 <cabanier> topic: Consider adding renderedWidth/renderHeight properties to SVG root
04:01:02 <ed> ISSUE-2356?
04:01:02 <trackbot> ISSUE-2356 -- Consider adding renderedWidth/renderHeight properties to SVG root -- raised
04:01:02 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2356
04:01:06 <cabanier> cm: I don't know if we need this
04:01:47 <cabanier> cm: I think you already have the information you need
04:02:26 <cabanier> cl: eventually have a rendered size. How do you get to that?
04:02:51 <cabanier> cm: viewport should give you that size
04:03:38 <cabanier> rc: why would you want to know this?
04:03:47 <cabanier> bb: it is useful
04:04:02 <ed> http://www.w3.org/TR/SVG11/struct.html#__svg__SVGSVGElement__viewport
04:04:12 <cabanier> bb: for laying out ui elements
04:04:51 <cabanier> resolution: no, we already have it (see link)
04:05:13 <krit> krit has joined #svg
04:06:00 <cabanier> topic: Consider adding a fixed-stroke property
04:06:06 <ed> ISSUE-2357?
04:06:06 <trackbot> ISSUE-2357 -- Consider adding a fixed-stroke property -- raised
04:06:06 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2357
04:06:17 <cabanier> cl: how is this different from non-scaling stroke?
04:06:20 <cabanier> cm: i agree
04:06:49 <cabanier> cm: maybe if you're inside a scaled iframe?
04:07:11 <cabanier> cm: what would be the use case for this?
04:07:58 <cabanier> cm: do we want something that counteracts the outside transformation?
04:08:35 <cabanier> vh: isn't this how we originally specified this?
04:09:01 <cabanier> cl: yes. but it raised many issues
04:09:14 <ChrisL> its asking for a min-stroke-width I think
04:12:29 <ed> http://www.w3.org/TR/SVGTiny12/painting.html#NonScalingStroke
04:12:50 <cabanier> vh: current non-scaling stroke would still scale if the svg element itself is scaled
04:13:22 <cabanier> rc: this seems wrong when you're doing inline svg since you only have one document
04:14:26 <cabanier> vh: checking the document, it seems that the scale of the SVG document does not affect non-scaling strokes
04:15:37 <cabanier> resolution: the current non-scaling stroke already defines this behavior
04:16:11 <cabanier> topic: Consider allowing geometry to be defined using properties
04:16:22 <ed> ISSUE-2359?
04:16:22 <trackbot> ISSUE-2359 -- Consider allowing geometry to be defined using properties -- raised
04:16:22 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2359
04:16:40 <cabanier> cm: no, Patrick already came up with a list
04:17:16 <cabanier> resolution: we will support the properties from Patrick's proposal
04:17:32 <cabanier> topic: Consider adding a 'key()' keyword for animation triggers
04:17:40 <ed> ISSUE-2362?
04:17:40 <trackbot> ISSUE-2362 -- Consider adding a 'key()' keyword for animation triggers -- raised
04:17:40 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2362
04:19:03 <vhardy> http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0168.html
04:19:09 <cabanier> bb: you can also use script
04:19:55 <cabanier> bb: in any case where you can receive event you can also use script
04:20:39 <cabanier> bb: this is not critical. 
04:22:09 <cabanier> ed: most interesting case require script anyway
04:22:43 <cabanier> vh: I don't agree with that. How would you start an animation with a mouse event?
04:23:38 <ed> s/case/cases/
04:26:03 <cabanier> cc: I think we should declarative animations using keys
04:26:30 <cabanier> cc: I know that people are using that certain application
04:27:12 <cabanier> s/certain/in certain
04:27:51 <cyril> for instance in electronic program guids
04:28:32 <ed> the EPGs i've seen have all used javascript
04:29:13 <vhardy> vh: I think that declarative animation is useful and that having timing tied to events is one of its key features. Therefore, I think we should be able to tie in UI events, animation events and custom events alike. Key events seem important and I think we should definitely have a way to tie in keypresses to animation timing.
04:32:30 <cabanier> cm: can we resolve this as part of the animation spec
04:32:43 <cabanier> ed: it is part of animation so it makes sense
04:33:22 <cabanier> vh: Brian, can you add that to requirements spec?
04:36:14 <cabanier> bb: it is hard since browsers use different modifiers
04:36:28 <cabanier> vh: the proposal is to tie it do regular dom events
04:36:50 <cabanier> bb: this seems like a major security issue
04:37:35 <cabanier> vh: can you explain this more?
04:38:01 <cabanier> vh: if scripts are allowed, can't I get all events anyway?
04:38:13 <cabanier> bb: that is true
04:40:50 <cabanier> action: Brian to create wiki for web animations
04:40:51 <trackbot> Created ACTION-3226 - Create wiki for web animations [on Brian Birtles - due 2012-01-21].
04:41:15 <cabanier> resolution: we will decide this in the animation spec
04:42:46 <cabanier> topic: Consider adding scrolling to editable text
04:43:54 <ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_scrolling_to_editable_text
04:43:57 <cabanier> cm: that is the SVG tiny 1.2 one
04:44:13 <cyril> http://www.w3.org/TR/SVGTiny12/svgudom.html#KeyIdentifiersSet
04:44:18 <cyril> http://www.w3.org/TR/SVGTiny12/animate.html#AccessKeyValueSyntax
04:45:53 <cabanier> we will address this in a bit
04:45:55 <cabanier> topic: Consider adding a property for autoscaling
04:45:59 <ed> ISSUE-2378?
04:45:59 <trackbot> ISSUE-2378 -- Consider adding a property for autoscaling -- raised
04:45:59 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2378
04:47:30 <cabanier> cl: I read the proposal
04:48:01 <cabanier> cm: what does it mean?
04:48:08 <cabanier> cc: we discussed this before
04:48:57 <cabanier> cl: authoring tools are designed for printing so they always have a width and height
04:49:33 <cabanier> cl: we have spent a lot of time on this on the CSS working group
04:49:52 <cabanier> cc: this could create confusion
04:51:34 <cabanier> resolution: no. This is not really necessary.
04:51:56 <cabanier> topic: Consider adding advanced font metrics interface
04:51:57 <ed> ISSUE-2379?
04:51:57 <trackbot> ISSUE-2379 -- Consider adding advanced font metrics interface -- raised
04:51:57 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2379
04:52:41 <cabanier> ed: didn't we already resolve this?
04:52:47 <cabanier> cm: not really
04:52:59 <cabanier> cm: this would be very useful
04:53:08 <cabanier> vh: this seems like a fx issue
04:53:13 <cabanier> everyone: that's right
04:54:13 <cabanier> resolution: yes, but we need a more concrete proposal and go through the fx group. Everyone agrees that it is needed
04:54:27 <cabanier> topic: Consider making svgz files just as valid and useful as svg files
04:55:44 <cabanier> ed: make local SVGZ files open
04:55:53 <cabanier> cl: nothing is stopping that
04:56:01 <cabanier> ed: the spec says it is disallowed
04:56:18 <cabanier> cm: the spec says it has to be xml
04:58:38 <cabanier> cl: the summary is that systems that look at the mime type and the content encoding
04:59:28 <cabanier> cl: systems that don't that (such as the file system), have to look at the file extension or the first bytes of the file
05:00:37 <cabanier> vh: this should just be a spec clarification?
05:01:56 <cabanier> resolution: SVG2 will clarify that SVGZ files should be treated the same as SVG
05:02:44 <cabanier> topic: Consider allowing CSS 'color' property to apply to 'fill'
05:03:59 <cabanier> resolution: We already have currentColor for allowing CSS 'color' property to apply to 'fill'
05:04:14 <cabanier> topic: Consider adding a DOM method to convert a <text> element to outline path data
05:05:08 <cabanier> vh: this seems very useful in other contexts such as canvas
05:05:21 <krit> Make sure that the outline may differ between implementations please
05:06:53 <cabanier> resolution: add a DOM method to convert a <text> element to outline path data and possible migrate to fx
05:07:07 <cabanier> topic: Simpler interpolation between two paths for animations
05:07:19 <cabanier> bb: I like it
05:07:30 <krit> What does that mean?
05:07:34 <cabanier> cl: needs a more flexible proposal
05:07:55 <ChrisL> s/flexible/fleshed-out/
05:07:56 <krit> Animation between different paths and different segments?
05:08:11 <ChrisL> krit - we are not sure actually what the request is
05:16:06 <cyril> http://dl.acm.org/citation.cfm?id=256162
05:16:07 <cabanier> resolution: svg2 will try to introduce simpler path interpolation 
05:16:49 <cabanier> topic: next f2f meeting
05:17:07 <cabanier> vh: can we have a 2 day svg meeting and 1 day of fx?
05:17:18 <cabanier> vh: otherwise I have 6 days of meetings
05:17:29 <ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F_Hamburg_2012
05:17:35 <cabanier> vh: 2 days of svg, 1 day break and then 1 joint meeting
05:19:09 <cabanier> vh: meet 6-7 for svg, 8 is break and fx is on 9
05:19:25 <cabanier> cl: css is 10-11
05:19:41 <cabanier> bb + ed: can we not meet on sunday?
05:20:17 <cabanier> vh: OK. let's meet on 7-8 and have fx on the 9
05:20:42 <ed> ACTION: ed to create registration questionaire for Hamburg 2012 f2f
05:20:43 <trackbot> Created ACTION-3227 - Create registration questionaire for Hamburg 2012 f2f [on Erik Dahlström - due 2012-01-21].
05:21:02 <cabanier> cl: sept 11-14 is svg open in Zurich
05:21:14 <ed> http://svgopen.org/2012/
05:21:15 <cabanier> cl: do we want to meet then?
05:21:27 <cabanier> cc: I prefer after
05:22:07 <ChrisL> css meetings? http://wiki.csswg.org/planning 
05:22:19 <vhardy> http://wiki.csswg.org/planning/2012
05:22:22 <cabanier> resolution: we will meet 7-8 for SVG and 9 for FX in Hamburg
05:23:11 <cabanier> cl: tpac is in November in Lyon
05:23:45 <cabanier> vh: where do we meet after May?
05:24:10 <cabanier> vh: ah, let's meet at SVG Open and then at TPAC
05:24:20 <ChrisL> 29 October - 2 November 2012 Lyon, France
05:24:28 <ChrisL> http://www.w3.org/2012/10/TPAC/
05:26:13 <cabanier> cl: I'm sure we can find a room in Zurich
05:26:24 <cabanier> cl: if we ask early
05:28:07 <cabanier> ed: let's also meet in July
05:28:27 <cabanier> ed: working draft is supposed to be ready then
05:28:48 <krit> That will be a meeting every two month
05:29:34 <ed> the schedule is rather aggressive, see http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page
05:29:43 <ChrisL> i think the plan is to not meet at svg open as its too close to tpac, butto meet in july instead
05:30:11 <ChrisL> so seattle in July could be good (Adobe or Microsoft could host)
05:34:41 <cabanier> resolution: let's meet in July 25-27 in Seattle and TPAC in November
05:35:38 <ed> RRSAgent, make minutes
05:35:38 <RRSAgent> I have made the request to generate http://www.w3.org/2012/01/13-svg-minutes.html ed
06:17:48 <birtles> birtles has joined #svg
07:21:07 <birtles> birtles has joined #svg
08:49:27 <Anthony> Anthony has joined #svg
08:50:19 <Anthony> Anthony has left #svg
23:02:00 <ChrisL> ChrisL has joined #svg
23:16:39 <Anthony> Anthony has joined #svg
00:07:36 <Anthony> Anthony has joined #svg
01:54:54 <Anthony> Anthony has joined #svg
01:59:29 <Anthony> Anthony has left #svg
01:59:59 <Anthony> Anthony has joined #svg
02:02:45 <Anthony> Anthony has joined #svg
02:10:34 <Anthony> Anthony has joined #svg
08:16:57 <stearns> stearns has joined #svg
00:00:04 <karl> karl has joined #svg
04:33:08 <ed> ed has joined #svg
08:26:22 <shepazu> shepazu has joined #svg