See also: IRC log
<heycam> ScribeNick: heycam
BB: the last thing I wanted to put forward was the idea of making this Web Animations spec
… which covers both SVG and CSS animations
… and as was suggested, I think by Dean or someone, also a JS API
… in addition to what we already have
… you can see the basic ideas there [in thel ink]
… 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
… that's the basic idea
… I've written a few very draft ideas, already just talking with Rik I think I've overhauled large parts of those ideas already
… I'll pick out a couple of points
… one would be that animation should be able to target more than one element, SVG Animations are limited in that regard at the moment
… e.g. we might have a select="" attribute
… that's one example of the sort of things I'd add
… also you can use an animation defined using an element syntax, reference it using the CSS animation-name property
… also talked with Rik and Vincent about how SVG animations are limited in that they can only target one attribute at a time
… if you want to target more than one, you need another animation
… that's also something we could possibly address here
<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.)
… I have a couple of draft ideas here, maybe a semicolon separated list of attribute names
… that idea of being able to target more than one attribute/property at a time might be useful
… especially with aligning with CSS animations
… one issue that I think I'd like to think about is backwards compat
… 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
… it's more aligned with CSS animations, but it draws on the learning from SVG's SMIL animation heritage
… that was my initial proposal
… but I think Cameron suggested that he'd like to see if we could keep backwards compatibility
… that's one of the bigger questions
… is it ok to make something new, and deprecate the old
… or is it important to build on what we have, recognise that that might limit how much we can simplify and align with CSS
… maybe that's something we can't answer right now
… we need to do more investgation
… 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
ED: I don't think we can drop current SVG animation support from our implementation
… animateTransform is used, animateColor not so much, animateMotion is useful but not used so much
BB: I'm thinking about deprecating <animate> as well
… so this proposal is for something completely separate
… there are subtle differences between CSS and SVG animations
… such as rounding behaviour is different
… if we want to keep our existing syntax, how can we align with CSS and keep backwards compat
… there may be a way to do that, we could have a flag that triggers the different behaviour
… but the alternative would be to come up with new elements
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
BB: the main situation I'm interested in is when you don't have script
… that's when you really need declarative animation
CC: I like some of the ideas
… having one element for the animation, <animate> only, that's fine
… I like adding selectors, possibilities to target multiple attributes
… but the general idea of redesigning something new, that's the thing I don't like
… I think we could start with the <animate> element and augment it
… so it's easier to use
… extend its behaviour so it can do <set>, etc., but not start from scratch
BB: what do you think about naming things?
… one example here is iteration-count
… in SVG it's repeatCount
CC: it's fine, we can duplicate the attribute if we want to
BB: is it fine to allow also iteration-count and define how it overrides with repeatCount?
ED: the only example similar to this I can think of is xml:id and id, which wasn't too popular
CC: personally I wouldn't mind having different naming
… as long you don't have to store the two different attributes
CM: I think you would have to though
… the DOM would require you to
BB: you could define iteration-count, and if both are used on the element then iteration-count wins
… the syntax might differ too, indefinite vs infinite
RC: why would you not just make the syntax the same?
… and the name?
[iterationCount vs animation-iteration-count]
<birtles> <animate animation-iteration-count="" animation-timing-function="" animation-delay="" ... />
CM: I don't want to break the identity between presentation attribute names and property names
BB: if we match the names exactly, it forces you to have the same behaviour and parsing
VH: as the CSS properties?
CM: which might be a good thing
<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.
CC: CSS Animations is still a draft, right?
CM: there is content out there
VH: still prefixed though
<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.
TabAtkins, yeah, I think that's Brian's argument. OTOH there are cognitive advantages to using *exactly* the same property names/values as CSS.
<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.
TabAtkins, are implementations deployed that use unprefixed names?
<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.
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
VH: as a group, we should document these issues, send them to the FX taskforce
… say we feel they should be aligned, request a change to CSS Animation
<TabAtkins> Cyril: Blame Apple for coming to the WG with a fully-formed and implemented proposal instead of starting discussion early. :/
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...
VH: Brian could you draft a list of things we ask of CSS Animations to change, like the rounding stuff?
<TabAtkins> (Details like rounding *are* potentially changeable on the CSS side.)
BB: with what scope?
… it's almost impossble to change names, rounding behaviour there is some hope of changing
VH: the message could just be "here are differences" and a pointer to your document
BB: I think the rounding is the most significant issue
<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.)
CM: we should identify the features that prevent us from extending/aligning while keeping the same name <animate>
<scribe> 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 [recorded in http://www.w3.org/2012/01/13-svg-minutes.html#action01]
<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].
BB: another minor one is indefinite vs infinite
… that's something we could fix on our side
VH: indefinite is used for begin="" as well
BB: that's where I think we should deviate from SMIL
CC: we should encourage authors to use the updated syntax, but existing implementations would still need to support the old stuff
… having a note in the spec for authors about this would be good
BB: the rest I think we talked about yesterday, obviating the need for animateTransform, animateColor
<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.
VH: the reason we had for animateColor is that there are properties that take colors and fill patterns
… animateColor indicates that they're just colours
CM: you don't need to indicate that though
… you know you have two colour values, it's clear how to interpolate
CC: for animateMotion, in GPAC the way I implemented it is just using <animate> with a pseudo attribute called "motion transform"
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
<TabAtkins> I think that's a good approach.
… CSS Animations doesn't have separate <animate>, <animateMotion>, etc.
… if we can do it just with <animate>, it's easier to bring across to CSS Animations
CC: in the page it says it should also be possible to animate all colour stops of a gradient at the same time?
BB: yes, you can't do that in SVG
CM: but you will be able to
… because we will support css3-image
BB: the main thing I want to get out of this session is some consensus on direction
… and then hammer out details later
… Vincent's already agreed to help me with that
VH: I have a question on <set>
… 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
… one difficulty would be what happens if you have two of these, you'd need to define priority
… it could be good for non-scripted situations
… but that's a separate discussion
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
… one suggestion was to add a timeContainer attribute on SVG container elements like <g>
… I'll work on that
… but some way of specifying par/seq time containers is what I'd like
BB: I would like to work out how to align events
… maybe making TimeEvent a subinterface of AnimationEvent
VH: do any implementations let you use SVG animations target HTML?
BB: yes, Gecko lets you target properties of HTML elements from SVG animation elements
ED: Opera doesn't, but we could
BB: that's another question, whatever we define it should be able to target HTML as well
… and then for HTML, whether targetting properties is enough there
<cyril> Tab, does WebKit allow you to animate HTML properties with SVG animation elements ?
… and think there's a bit of opposition to targeting HTML attributes
<TabAtkins> I highly doubt it, but it would be easy to test.
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
BB: we can start with just allowing it in SVG, and if it proves useful, see if HTML folks want to allow it directly
… a different discussion perhaps, what to do with DOM storage
… the messy baseVal/animVal
<TabAtkins> Burn it with fire?
… I wonder what is useful to authors
… I find I just use animVal
ED: I find baseVal more useful because you can read and write to it, unlike with animVal which is readonly
CM: at least when you're modifying you need baseVal
BB: but yes, what do we need out of an SVG DOM APi
<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.
CM: we will be having a broader discussion about SVG DOM improvments
… I don't think those improvements will impact the rest of your proposals here
<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
BB: seems like we should move forward with this then
CM: I would like to hear what the non-SVG FXTF people feel though
shepazu, yes good idea
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
<scribe> ACTION: Brian to work on the Web Animation spec proposal for the May FXTF meeting [recorded in http://www.w3.org/2012/01/13-svg-minutes.html#action02]
<trackbot> Created ACTION-3224 - Work on the Web Animation spec proposal for the May FXTF meeting [on Brian Birtles - due 2012-01-20].
<birtles> (for ChrisL: http://brian.sol1.net/svg/demo/button.svg)
<trackbot> ISSUE-2281 -- Look at making paced animations easier -- raised
<cyril> Doug, do you remember anything on this issue that you raised?
ED: are paced animations hard to write at the moment?
BB: it's mostly just for motion animation at the moment
… not sure what the particular need is here
CM: so this would allow specifying a speed for the motion animation
… since you don't know what dur you would specify
BB: my guess is that cases where you don't know what the path length is, is when you are doing scripted path generation
<shepazu> [[ pace="10px/1s" ]]
BB: and if that's so, you can just do getComputedPathLength [or whatever it is]
DS: yes it's true you could use that method, if you have a <path>
… again that calls for script
… the path might change, then you need to do getComputedPathLength every time
… if the path is moving, and you want the animated object to move at a steady pace it will be more of a pain
… also if you have an animation that is not along a path, you could not do that
… e.g. if you just want to move an object to the right [at a certain speed]
… you could also see this being used when animating colour, if you want an animation to be synced with another of a in certain duration
BB: I was thinking when you have <mpath> that's interesting, because the target path might be changing outside of your control
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?
BB: instance times already can change in the SMIL model, that's one of the more complex parts of SMIL
… maybe it would be bad that instance times get updated every animation tick
… can <mpath> target an animated path?
CM: probably not the most important feature, but let's accept it (and prioritise later)
BB: this would introduce some coupling between the animation and the timing model
… it's not what you normally do, but if it's useful it might be worth it
RESOLUTION: We will support motion animation of a specified speed in SVG2.
-- break for 15 minutes --
<vhardy> ScribeNick: vhardy
heycam: we discussed this before and decided to not do UI in the zoom/pan features.
ed: this is a bit different.
cl: this is not something we
should be adding.
... it is a huge amount of work and not necessarily what people need.
... the zoom/pan we talked about and we may add through the 'controls' attribute to switch it on/off.
... this was rejected earlier.
... for layers, we already have groups and you can switch on/off layer by toggling visibility.
RESOLUTION: SVG2 will not address the "Basic SVG UI enhancements" requirement.
<ed> the layer UI, that's <g>, which already has UI if you use browser debugging tools, e.g dragonfly, firebug or whatever
ed: this is asking the opposite of what we require. We say it is display none, so the children do not display.
<TabAtkins> I suppose that's like HTMLUnknownElement acting like <span>?
heycam: what is described here is
similar to what HTML does.
... I do not think this proposal, or the current way, are completely free of what content is out there.
ed: I do not think this is a good
... I think that not showing anything is reasonnable.
... if you want so kind of fallback, we could do it some other way.
cl: this is related to the switch requirement later on.
ed: we resolved to fix the issues
... by saying the requiredFeatures on unknown elements is still looked at.
cyril: the use case is fallback
... 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.
cl: I have preference the
<switch> way to provide a fallback (rather than the
children way of HTML).
... I prefer the test statements that <switch> provides.
heycam: but people dislike feature strings
<ChrisL> as long as the tests work, which is not really the case with feature strings
heycam: I slightly hesitate to change the behavior, but I do not mind to mind.
ds: I can see both ways.
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 that are the alternates.
ds: has it become an anti-pattern.
cl: it has become an anti-pattern.
ds: I do not think it is an anti-pattern. New elements are just treated that way in HTML5.
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.
ds: I do not understand your point.
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.
cl: iin CSS, the default styling for unknown elements is display: inline,which works ok for text
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.
... in HTML, if you have something that is replacement content, it make a box around itself. In SVG, it is just rendered.
heycam: I think it is plausible to create fallback content that renders fine.
cc: I do not know how to explain differently. We are talking about elements in the SVG namespace?
cl: what happens with an HTML parsing? Isn't it going back to HTML?
cmc: I think it stays in SVG.
cc: if the elements are metadata, we do not want that to be rendered.
ds: you could put display:none, or put it in a <defs> element.
<ChrisL> what about <newFooElement><title>text</title><desc>blah blah</desc> .... </newFooElement>
cmc: in this example, <title> and <desc> do not get rendered.
ds: if we did not have <textPath> and added your proposal, and then we added <textPath> then the text under it would display.
cmc: I just tested the HTML5 parser, the unknown element gets put in the SVG namespace.
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>
ds: I see what you are saying, but is that a reason to keep the current behavior.
cc: I can go either way.
... is there content outside that relies on unknown element not being rendered?
cl: we encouraged people to put
elements in their own namespace. In practice, people did not do
... I suspect we would find usage of that.
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
... it is not clear if it is beneficial for all UA. From SVG2, we could use that extensibility mechnism.
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?
ds: you would have to do a short script.
ed: but you could do a scirpt to do what you want.
<TabAtkins> Note that, for most authors, the only UAs that matter are browsers.
ds: I think that script would be short lived (3-5 years). As opposed to 'everything in the future"
ed: I do not know how much would break.
cmc: we could resolve for it under the provision that it does not break existing content.
cl: it is tied to the item on
<switch> and not using feature string.
... 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.
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 casess.
... 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.
cc: we could put it in the spec. and see if people think it will break their content. We could mark it at risk.
cmc: may be we can mark features that we are not entirely sure about.
ed: it would be nice to have more examples that show how it might be used.
cl: it would be find as a paragraph in the extensibility chapter.
ed: it would be good to get this to work especially in the SVG in HTML context.
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.
cc: let's not argue anymore. We have a consensus.
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 because you'd need to modify the DOM structure to get it to render, and that might affect other things too
cl: we should find out how hard it woudl be for shims to work.
ed: I would like to see a
fallback script to understand how hard it would be.
... we could write a fallback script right now to see how it works.
... I think we could investigate it and accept if there are not issues.
<ChrisL> vh: torn on it, can see dougs point butits not a high priority item
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.
<scribe> ACTION: Doug to write scripts showing how a shim could bridge the old and new behaviors for content under unknown elements. [recorded in http://www.w3.org/2012/01/13-svg-minutes.html#action03]
<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].
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
... the Windows one is a string. The Mac one is saying that SVG is both an image an xml.
<ChrisL> Macintosh Universal Type Identifier code:
<ChrisL> org.w3c.svg conforms to public.image and to public.xml
cl: is this somethign the
platform needs to do.
... if pasting into an editor, you could do useful things with it.
... it is not fully specify, but there is something there.
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.
vhardy: I think that most clipboards allow you to copy in multiple formats.
... 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).
... I think it is fine to make recommendations, but I do nto think we should have a hard MUST requirement.
<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.
cmc: I do not think we should be
requiring special UA behavior for how content is
... there is a clipboard API spec, and there is a way to put things in the clipboard with type and content.
cmc: this clipboard API allows
you to say 'copy this string to the clipboard and interpret it
... I think someone should look into the existing API to see if we need to specify anything additional.
... it may be outside of our scope to add anything. We may need to suggest rasterization.
... I am happy with the requirement saying how applications should behave if pasting SVG content in them.
cl: yes, but it should be more guidance.
RESOLUTION: Accept the requirement on how SVG graphics and text are copy/pasted for the SVG2 specification, considering both non-normative and script API related requirements.
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.
cl: for widht/height is put 'no'
in the document because the box model needs the values. There
is no automagic sizing.
... 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.
... the request is to have them not specified, and have that does not work.
cmc: isn't there shrink wrapping on absolutely positioned elements?
cmc: couldn't we have the same behavior for <foreignObject>?
cl: I guess we could.
... yeah, we could specify it that way.
cmc: ed has an ACTION to propose something.
ed: I think it would be nice to have that behavior.
cmc: if you want to include HTML content and you do not know how big it would be, that would be useful.
cl: if we want to rely on the shrink-wrap behavior, then that is fine.
cmc: I would be surprised if content rely on the widht/height in foreignObject defaulting to zero and not displaying if zero.
cl: it needs to be more speced out, but more tractable than I originally thought.
ed: I think we should accept the requirement.
cmc: I agree.
RESOLUTION: Accept the requirement to remove the requirement to have @widht and @height on foreignObject.
cl: we definitely need to do
this. We changed the syntax twice.
... last time changed in SVG 1.1 2nd edition.
... I think <switch> is fine, but the feature strings need to be totally reworked.
RESOLUTION: Accept the requirement ot consider the future of feature strings and the switch element
<trackbot> ISSUE-2422 -- Define switch to work with unknown elements and processing behaviour for audio elements etc -- raised
<trackbot> ISSUE-2422 -- Define switch to work with unknown elements and processing behaviour for audio elements etc -- raised
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.
cmc: I am wondering if there is a css property to set the volume.
<TabAtkins> There is not, but there could be.
<TabAtkins> We could either yoke this to Speech (probably not a good idea) or make a new one.
cl: there was in the aural CSS but there is not in the new work on text to speech done by Daniel Weck.
<ChrisL> tab, prefer the newone
<ChrisL> and in tiny..2 we had an audio-level property
cmc: we need to define how we turn audio off. I am not ready to accept any specific proposal yet.
RESOLUTION: SVG2 will provide a way to control audio level and playback.
cmc: this is a way to get better positions out of MouseEvents, and I think we all agree.
RESOLUTION: SVG 2 will provide positioning information in MouseEvents.
cmc: this relates to the scripting api for animation and we should deal with this as part of the Web animations work.
cl: I am not clear on what is asked.
cmc: he is asking to get the
... I would be in favor of exposing more information than we do currently about animation.
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.
cmc: I was wondering how to address the requirement to turn a bit of SVG to PNG.
<cyril> Scribe: cyril
<scribe> ScribeNick: 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
VH: a couple of months ago, it didnt work in webkit
CM: in the recent builds, it works
ED: you cant have anything external
VH: why does it have to be a data url
CM: because drawImage takes an
HTML image element and that can only reference an entire
... there was a recent fix in FF
... regardless of whether that works, if you want to do it by script, you'd want to serialize the current state
<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/
CM: including the computed style of every property and the animated value of every attribute
VH: didn't we talk about XML serialization before
ED: it doesn't give the animation state
CC: you could use getPresentationTrait
CM: yes or using animVal, it shouln't be difficult
VH: CanVG was parsing the SVG and making rendering calls, because that wouldnt make the canvas dirty
CM: I would say no to the req because it's not hard to do in a script
RESOLUTION: SVG 2 will not add an API for saving and restoring the SVG state
<vhardy> ScribeNick: vhardy
cl: we already resolved to accept this requirement in Seattle and I got an ACTION which I completed.
cl: this is in CSS image value
spec. which we agreed to review.
... we also agreed to depend on that specification.
cmc: where is the list of CSS modules that we will depend on?
cl: we went though this before.
RESOLUTION: SVG 2 will work with CSS image-fit.
cl: we talked about it earlier and agreed it was useful.
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.
cl: because of our earlier decision on auto size images, this will work.
cmc: it is easier in HTML because the DOM is better.
cl: this should be addressed with our DOM work.
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.
--- LUNCH BREAK ---
<cabanier11> scribenick: cabanier
<scribe> scribenick: cabanier
cm: we did say that we want to make it easy to get to zoom and pan
ed: might be good to pull those
... get the two requirement together
cm: that was in the mapping discussion of the first day
ed: it might be nice. How difficult is it?
cm: viewbox is not exposed as a
... currentscale/currenttranslate provides one that is seperate from the viewbox
does it make sense to keep distinction between zoom/pan and the viewbox
cm: what would these new methods
... we can accept the requirement to say something to make it easier to get to zoom/pan
resolution: svg2 will make it easier to write a zoom/pan widget. possibly by adding convenience method to get scale/transfer
(discussion on panning and zooming)
bb: is up to the browser to optimize the behavior?
... suspendredraw is not good for situations where you only want to redraw a certain region
<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
<stakagi> Please give the comment to this subject.
<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
cm: at some point it is up to the
browser to optimize the movements of shape
... 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
ed: this is work we did last
... this is a press release talking how we optimized the browser
cm: file a bug with the browser if you find a case that is slow
bb: we did some optimizations too
resolution: we already did that
cl: it would need to be an update to the rfc that defines the data URI
resolution: this is outside of our charter. out of scope for SVG2
cl: I can see it but they are not
quite the same
... we should go with what CSS is doing
cm: I agree.
cl: I want to get rid of it
resolution: we will deprecate baseline shift and use vertical align instead in SVG2
cc: we already agreed to do that
... I don't like this because it makes it hard to overlay graphics on top of video
cm: why is that?
... are you restricted to the 3 types of track?
cm: there are 5 kinds
cc: but they are text tracks
ed: this is for a different group
cc: right now you have to use webvvt but it doesn't support xml/svg
bb: subtitles are often colored and animated in Japan
vh: this is why I thought that
you could do this with webvtt
... what can we ask?
cc: I sent an email to create a
more generic track interface
... people think webvtt should only be text
resolution: SVG2 will allow video elements to have captions, tracks, etc
<trackbot> ISSUE-2354 -- Consider adding a 'inverse' value to clip-rule -- raised
cl: you do need to know what the outside is
cm: it is convenient to write it that why
rc: this seems to be what mask is for
vh: this would requires us to do
all the geometry
... we can take the requirement
... but you can use the mask
cc: ask Tav why they implemented
this in inkscape
... inkscape has a use case for it
resolution: since it easy to do in masks and difficult to do in geometry, we will not make it part of SVG2
<cyril> s/why they implemented/how they would implement/
<trackbot> ISSUE-2355 -- Consider allowing the 'clip' property to reference any element, not just 'clipPath' -- raised
cm: did we already talk about that?
rc: this would be handy to have
cm: people might think that the stroke is part of the mask
rc: that is true
cm: it would indeed be handy
resolution: we should allow
<g> inside of a clip path
... we will allow clip to point to regular elements
<heycam> s/clip to/clip-path, mask and similar properties/
<heycam> s/regular/to regular/
<trackbot> ISSUE-2356 -- Consider adding renderedWidth/renderHeight properties to SVG root -- raised
cm: I don't know if we need
... I think you already have the information you need
cl: eventually have a rendered size. How do you get to that?
cm: viewport should give you that size
rc: why would you want to know this?
bb: it is useful
bb: for laying out ui elements
resolution: no, we already have it (see link)
<trackbot> ISSUE-2357 -- Consider adding a fixed-stroke property -- raised
cl: how is this different from non-scaling stroke?
cm: i agree
... maybe if you're inside a scaled iframe?
... what would be the use case for this?
... do we want something that counteracts the outside transformation?
vh: isn't this how we originally specified this?
cl: yes. but it raised many issues
<ChrisL> its asking for a min-stroke-width I think
vh: current non-scaling stroke would still scale if the svg element itself is scaled
rc: this seems wrong when you're doing inline svg since you only have one document
vh: checking the document, it seems that the scale of the SVG document does not affect non-scaling strokes
resolution: the current non-scaling stroke already defines this behavior
<trackbot> ISSUE-2359 -- Consider allowing geometry to be defined using properties -- raised
cm: no, Patrick already came up with a list
resolution: we will support the properties from Patrick's proposal
<trackbot> ISSUE-2362 -- Consider adding a 'key()' keyword for animation triggers -- raised
bb: you can also use script
... in any case where you can receive event you can also use script
... this is not critical.
ed: most interesting case require script anyway
vh: I don't agree with that. How would you start an animation with a mouse event?
cc: I think we should declarative
animations using keys
... I know that people are using that certain application
<cyril> for instance in electronic program guids
<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.
cm: can we resolve this as part of the animation spec
ed: it is part of animation so it makes sense
vh: Brian, can you add that to requirements spec?
bb: it is hard since browsers use different modifiers
vh: the proposal is to tie it do regular dom events
bb: this seems like a major security issue
vh: can you explain this
... if scripts are allowed, can't I get all events anyway?
bb: that is true
<scribe> ACTION: Brian to create wiki for web animations [recorded in http://www.w3.org/2012/01/13-svg-minutes.html#action04]
<trackbot> Created ACTION-3226 - Create wiki for web animations [on Brian Birtles - due 2012-01-21].
resolution: we will decide this in the animation spec
cm: that is the SVG tiny 1.2 one
we will address this in a bit
<trackbot> ISSUE-2378 -- Consider adding a property for autoscaling -- raised
cl: I read the proposal
cm: what does it mean?
cc: we discussed this before
cl: authoring tools are designed
for printing so they always have a width and height
... we have spent a lot of time on this on the CSS working group
cc: this could create confusion
resolution: no. This is not really necessary.
<trackbot> ISSUE-2379 -- Consider adding advanced font metrics interface -- raised
ed: didn't we already resolve this?
cm: not really
... this would be very useful
vh: this seems like a fx issue
everyone: that's right
resolution: yes, but we need a more concrete proposal and go through the fx group. Everyone agrees that it is needed
ed: make local SVGZ files open
cl: nothing is stopping that
ed: the spec says it is disallowed
cm: the spec says it has to be xml
cl: the summary is that systems
that look at the mime type and the content encoding
... systems that don't that (such as the file system), have to look at the file extension or the first bytes of the file
vh: this should just be a spec clarification?
resolution: SVG2 will clarify that SVGZ files should be treated the same as SVG
resolution: We already have currentColor for allowing CSS 'color' property to apply to 'fill'
vh: this seems very useful in other contexts such as canvas
<krit> Make sure that the outline may differ between implementations please
resolution: add a DOM method to convert a <text> element to outline path data and possible migrate to fx
bb: I like it
<krit> What does that mean?
cl: needs a more flexible proposal
<krit> Animation between different paths and different segments?
<ChrisL> krit - we are not sure actually what the request is
resolution: svg2 will try to introduce simpler path interpolation
vh: can we have a 2 day svg
meeting and 1 day of fx?
... otherwise I have 6 days of meetings
vh: 2 days of svg, 1 day break
and then 1 joint meeting
... meet 6-7 for svg, 8 is break and fx is on 9
cl: css is 10-11
bb + ed: can we not meet on sunday?
vh: OK. let's meet on 7-8 and have fx on the 9
<ed> ACTION: ed to create registration questionaire for Hamburg 2012 f2f [recorded in http://www.w3.org/2012/01/13-svg-minutes.html#action05]
<trackbot> Created ACTION-3227 - Create registration questionaire for Hamburg 2012 f2f [on Erik Dahlström - due 2012-01-21].
cl: sept 11-14 is svg open in Zurich
cl: do we want to meet then?
cc: I prefer after
<ChrisL> css meetings? http://wiki.csswg.org/planning
resolution: we will meet 7-8 for SVG and 9 for FX in Hamburg
cl: tpac is in November in Lyon
vh: where do we meet after
... ah, let's meet at SVG Open and then at TPAC
<ChrisL> 29 October - 2 November 2012 Lyon, France
cl: I'm sure we can find a room
... if we ask early
ed: let's also meet in July
... working draft is supposed to be ready then
<krit> That will be a meeting every two month
<ed> the schedule is rather aggressive, see http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page
<ChrisL> i think the plan is to not meet at svg open as its too close to tpac, butto meet in july instead
<ChrisL> so seattle in July could be good (Adobe or Microsoft could host)
resolution: let's meet in July 25-27 in Seattle and TPAC in November
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/repeatCOunt/repeatCount/ Succeeded: s/ find baseVal more useful/ find baseVal more useful because you can read and write to it, unlike with animVal which is readonly/ Succeeded: s/ed: SVG UI/topic: SVG UI/ Succeeded: s/provide/provides/ Succeeded: s/featureString/feature strings/ Succeeded: s/taht/that/ Succeeded: 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/ Succeeded: s/cc: we should find out/cl: we should find out/ Succeeded: 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/ Succeeded: s/find/fine/ Succeeded: s/SVG 2.0/SVG2/g WARNING: Bad s/// command: 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/ FAILED: s/transfer/translate/ FAILED: s/why they implemented/how they would implement/ FAILED: s/clip to/clip-path, mask and similar properties/ FAILED: s/regular/to regular/ Succeeded: s/case/cases/ Succeeded: s/certain/in certain/ FAILED: s/flexible/fleshed-out/ WARNING: No scribe lines found matching ScribeNick pattern: <cyril> ... Found ScribeNick: heycam Found ScribeNick: vhardy Found Scribe: cyril Inferring ScribeNick: cyril Found ScribeNick: cyril Found ScribeNick: vhardy Found ScribeNick: cabanier Found ScribeNick: cabanier ScribeNicks: heycam, vhardy, cyril, cabanier WARNING: No "Present: ... " found! Possibly Present: ChrisL Cyril RC TabAtkins VH bb birtles cabanier cabanier11 cc cl cm cmc ds ed everyone heycam krit scribenick shepazu stakagi trackbot vhardy You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda Got date from IRC log name: 13 Jan 2012 Guessing minutes URL: http://www.w3.org/2012/01/13-svg-minutes.html People with action items: brian doug ed[End of scribe.perl diagnostic output]