SVG WG Sydney 2012 F2F day 4 -- 13 Jan 2012

<heycam> ScribeNick: heycam

Web Animations

<birtles> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/Animations/WebAnimations

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

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/Animations/WebAnimations

… 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]

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?

BB: yes

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?

(or content?)

<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

<cyril> http://wam.inrialpes.fr/timesheets/

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].

moar SVG2 Requirements

<birtles> (for ChrisL: http://brian.sol1.net/svg/demo/button.svg)

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Look_at_making_paced_animation_easier

<ed> ISSUE-2281?

<trackbot> ISSUE-2281 -- Look at making paced animations easier -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2281

<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?

ED: yes

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 --

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Basic_SVG_UI_enhancements

<vhardy> ScribeNick: vhardy

SVG UI enhancements

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.

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

<ed> the layer UI, that's <g>, which already has UI if you use browser debugging tools, e.g dragonfly, firebug or whatever

unknown elements treated as <g>

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 idea.
... 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 with <switch>.
... by saying the requiredFeatures on unknown elements is still looked at.

cyril: the use case is fallback for connectors.
... 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.

<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

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 that.
... 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].

SVG copy/paste

http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Specify_how_SVG_graphics_and_text_are_copy.2Fpasted

Specify how SVG graphics and text are copy/pasted.

<ChrisL> http://www.w3.org/TR/SVG/mimereg.html

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.
... 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.

ed: right.
... 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 selected.
... there is a clipboard API spec, and there is a way to put things in the clipboard with type and content.

<heycam> http://dev.w3.org/2006/webapi/clipops/

cmc: this clipboard API allows you to say 'copy this string to the clipboard and interpret it as SVG'.
... 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.

consider removing the requirement for @widht and @height for <foreignObject>

http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_removing_the_requirement_for_.40width_and_.40height_for_.3CforeignObject.3E

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?

vh/cl: yes.

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.

Consider the future of feature strings and the switch element.

http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_the_future_of_feature_strings_and_the_switch_element

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

<ed> ISSUE-2422?

<trackbot> ISSUE-2422 -- Define switch to work with unknown elements and processing behaviour for audio elements etc -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2422

<ChrisL> issue-2422?

<trackbot> ISSUE-2422 -- Define switch to work with unknown elements and processing behaviour for audio elements etc -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2422

consider treating audio separately to graphics.

http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_treating_audio_separately_to_graphics

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.

Consider adding new interface for easier use of positional property.

http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_new_interface_for_easier_use_of_positional_properties

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.

Consider adding method to return array of declarative timeline

http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_method_to_return_array_of_declarative_timeline

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 timeline information.
... 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.

Consider adding API for saving and restoring SVG state.

http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_API_for_saving_and_restoring_SVG_state

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 document
... 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

CSS3 Color syntax in SVG

http://www.w3.org/Graphics/SVG/WG/wiki/index.php?title=SVG2_Requirements_Input&section=117

cl: we already resolved to accept this requirement in Seattle and I got an ACTION which I completed.

Align with CSS WG preserveAspectRatio

http://www.w3.org/Graphics/SVG/WG/wiki/index.php?title=SVG2_Requirements_Input&section=118

cl: this is in CSS image value spec. which we agreed to review.
... we also agreed to depend on that specification.

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Resolutions

cmc: where is the list of CSS modules that we will depend on?

cl: we went though this before.

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Resolutions#CSS_Spec_dependencies

RESOLUTION: SVG 2 will work with CSS image-fit.

Should be possible to determine intrinsic size of an image

http://www.w3.org/Graphics/SVG/WG/wiki/index.php?title=SVG2_Requirements_Input&section=119

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.

Consider adding convenience methods for currentScale/currentTranslate

http://www.w3.org/Graphics/SVG/WG/wiki/index.php?title=SVG2_Requirements_Input&section=120

--- LUNCH BREAK ---

<cabanier11> scribenick: cabanier

<scribe> scribenick: cabanier

addconvenience methods for currentScale/currentTranslate

cm: we did say that we want to make it easy to get to zoom and pan

ed: might be good to pull those together
... 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 matrix
... 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 affect?
... 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

<heycam> s/transfer/translate/

(discussion on panning and zooming)

bb: is up to the browser to optimize the behavior?

cm: yes
... 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

<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?

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 year: http://www.newdesignworld.com/press/story/470436
... 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

Align with CSS Value and Units

resolution: we already did that

Gzip-compressed svg in data URIs

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

Deprecate baseline-shift and use vertical-align instead

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

Media elements in SVG need ability to associate captions and description

cc: we already agreed to do that in HTML5
... 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?

<heycam> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#the-track-element

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

<cyril> http://lists.w3.org/Archives/Public/public-web-and-tv/2011Aug/

Consider adding a 'inverse' value to clip-rule

<ed> ISSUE-2354?

<trackbot> ISSUE-2354 -- Consider adding a 'inverse' value to clip-rule -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2354

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/

Consider allowing the 'clip' property to reference any element, not just 'clipPath'

<ed> ISSUE-2355?

<trackbot> ISSUE-2355 -- Consider allowing the 'clip' property to reference any element, not just 'clipPath' -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2355

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/

Consider adding renderedWidth/renderHeight properties to SVG root

<ed> ISSUE-2356?

<trackbot> ISSUE-2356 -- Consider adding renderedWidth/renderHeight properties to SVG root -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2356

cm: I don't know if we need this
... 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

<ed> http://www.w3.org/TR/SVG11/struct.html#__svg__SVGSVGElement__viewport

bb: for laying out ui elements

resolution: no, we already have it (see link)

Consider adding a fixed-stroke property

<ed> ISSUE-2357?

<trackbot> ISSUE-2357 -- Consider adding a fixed-stroke property -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2357

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

<ed> http://www.w3.org/TR/SVGTiny12/painting.html#NonScalingStroke

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

Consider allowing geometry to be defined using properties

<ed> ISSUE-2359?

<trackbot> ISSUE-2359 -- Consider allowing geometry to be defined using properties -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2359

cm: no, Patrick already came up with a list

resolution: we will support the properties from Patrick's proposal

Consider adding a 'key()' keyword for animation triggers

<ed> ISSUE-2362?

<trackbot> ISSUE-2362 -- Consider adding a 'key()' keyword for animation triggers -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2362

<vhardy> http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0168.html

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

<ed> the EPGs i've seen have all used javascript

<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 more?
... 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

Consider adding scrolling to editable text

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_scrolling_to_editable_text

cm: that is the SVG tiny 1.2 one

<cyril> http://www.w3.org/TR/SVGTiny12/svgudom.html#KeyIdentifiersSet

<cyril> http://www.w3.org/TR/SVGTiny12/animate.html#AccessKeyValueSyntax

we will address this in a bit

Consider adding a property for autoscaling

<ed> ISSUE-2378?

<trackbot> ISSUE-2378 -- Consider adding a property for autoscaling -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2378

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.

Consider adding advanced font metrics interface

<ed> ISSUE-2379?

<trackbot> ISSUE-2379 -- Consider adding advanced font metrics interface -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2379

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

Consider making svgz files just as valid and useful as svg files

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

Consider allowing CSS 'color' property to apply to 'fill'

resolution: We already have currentColor for allowing CSS 'color' property to apply to 'fill'

Consider adding a DOM method to convert a <text> element to outline path data

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

Simpler interpolation between two paths for animations

bb: I like it

<krit> What does that mean?

cl: needs a more flexible proposal

<ChrisL> s/flexible/fleshed-out/

<krit> Animation between different paths and different segments?

<ChrisL> krit - we are not sure actually what the request is

<cyril> http://dl.acm.org/citation.cfm?id=256162

resolution: svg2 will try to introduce simpler path interpolation

next f2f meeting

vh: can we have a 2 day svg meeting and 1 day of fx?
... otherwise I have 6 days of meetings

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F_Hamburg_2012

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

<ed> http://svgopen.org/2012/

cl: do we want to meet then?

cc: I prefer after

<ChrisL> css meetings? http://wiki.csswg.org/planning

<vhardy> http://wiki.csswg.org/planning/2012

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 May?
... ah, let's meet at SVG Open and then at TPAC

<ChrisL> 29 October - 2 November 2012 Lyon, France

<ChrisL> http://www.w3.org/2012/10/TPAC/

cl: I'm sure we can find a room in Zurich
... 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

- DRAFT -

SVG WG Sydney 2012 F2F day 4

13 Jan 2012

Attendees

Contents