minutes, SVG WG Sydney 2012 F2F day 4 from Erik Dahlstrom on 2012-01-14 (public-svg-wg@w3.org from January to March 2012)

From: Erik Dahlstrom <ed@opera.com>
Date: Sat, 14 Jan 2012 16:38:15 +1100
To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Message-ID: <op.v71691j0geuyw5@mbp-2.local>

http://www.w3.org/2012/01/13-svg-minutes.html

and below as text:

[1]W3C

[1] http://www.w3.org/

- DRAFT -

SVG WG Sydney 2012 F2F day 4

13 Jan 2012

[2]Agenda

[2] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda

See also: [3]IRC log

[3] http://www.w3.org/2012/01/13-svg-irc

Attendees

Present
Regrets
Chair
Erik

Scribe
cyril

Contents

* [4]Topics
1. [5]Web Animations
2. [6]moar SVG2 Requirements
3. [7]SVG UI enhancements
4. [8]unknown elements treated as <g>
5. [9]SVG copy/paste
6. [10]Specify how SVG graphics and text are copy/pasted.
7. [11]consider removing the requirement for @widht and
@height for <foreignObject>
8. [12]Consider the future of feature strings and the switch
element.
9. [13]consider treating audio separately to graphics.
10. [14]Consider adding new interface for easier use of
positional property.
11. [15]Consider adding method to return array of declarative
timeline
12. [16]Consider adding API for saving and restoring SVG state.
13. [17]CSS3 Color syntax in SVG
14. [18]Align with CSS WG preserveAspectRatio
15. [19]Should be possible to determine intrinsic size of an
image
16. [20]Consider adding convenience methods for
currentScale/currentTranslate
17. [21]addconvenience methods for
currentScale/currentTranslate
18. [22]Align with CSS Value and Units
19. [23]Gzip-compressed svg in data URIs
20. [24]Deprecate baseline-shift and use vertical-align instead
21. [25]Media elements in SVG need ability to associate
captions and description
22. [26]Consider adding a 'inverse' value to clip-rule
23. [27]Consider allowing the 'clip' property to reference any
element, not just 'clipPath'
24. [28]Consider adding renderedWidth/renderHeight properties
to SVG root
25. [29]Consider adding a fixed-stroke property
26. [30]Consider allowing geometry to be defined using
properties
27. [31]Consider adding a 'key()' keyword for animation
triggers
28. [32]Consider adding scrolling to editable text
29. [33]Consider adding a property for autoscaling
30. [34]Consider adding advanced font metrics interface
31. [35]Consider making svgz files just as valid and useful as
svg files
32. [36]Consider allowing CSS 'color' property to apply to
'fill'
33. [37]Consider adding a DOM method to convert a <text>
element to outline path data
34. [38]Simpler interpolation between two paths for animations
35. [39]next f2f meeting
* [40]Summary of Action Items
_________________________________________________________

<heycam> ScribeNick: heycam

Web Animations

<birtles>
[41]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/An
imations/WebAnimations

[41]
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>
[42]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/An
imations/WebAnimations

[42]
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
[43]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> [44]http://wam.inrialpes.fr/timesheets/

[44] 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
[45]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:
[46]http://brian.sol1.net/svg/demo/button.svg)

[46] http://brian.sol1.net/svg/demo/button.svg)

<ed>
[47]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#L
ook_at_making_paced_animation_easier

[47]
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> [48]http://www.w3.org/Graphics/SVG/WG/track/issues/2281

[48] 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>
[49]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#B
asic_SVG_UI_enhancements

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

[50]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#S
pecify_that_unknown_elements_are_treated_as_.3Cg.3E_elements_for_the
_purpose_of_rendering

[50]
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>
[51]http://livedom.validator.nu/?%3C!DOCTYPE%20html%3E%0A%3Csvg%3E%0
A%20%20%3Cunknown%3E%3C%2Funknown%3E%0A%3C%2Fsvg%3E%0A%3Cscript%3Edo
cument.write(document.getElementsByTagName(%22unknown%22)%5B0%5D.nam
espaceURI)%3C%2Fscript%3E

[51]
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
[52]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

[53]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#S
pecify_how_SVG_graphics_and_text_are_copy.2Fpasted

[53]
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> [54]http://www.w3.org/TR/SVG/mimereg.html

[54] 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> [55]http://dev.w3.org/2006/webapi/clipops/

[55] 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>

[56]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#C
onsider_removing_the_requirement_for_.40width_and_.40height_for_.3Cf
oreignObject.3E

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

[57]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#C
onsider_the_future_of_feature_strings_and_the_switch_element

[57]
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> [58]http://www.w3.org/Graphics/SVG/WG/track/issues/2422

[58] 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> [59]http://www.w3.org/Graphics/SVG/WG/track/issues/2422

[59] http://www.w3.org/Graphics/SVG/WG/track/issues/2422

consider treating audio separately to graphics.

[60]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#C
onsider_treating_audio_separately_to_graphics

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

[61]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#C
onsider_adding_new_interface_for_easier_use_of_positional_properties

[61]
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

[62]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#C
onsider_adding_method_to_return_array_of_declarative_timeline

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

[63]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#C
onsider_adding_API_for_saving_and_restoring_SVG_state

[63]
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

[64]http://www.w3.org/Graphics/SVG/WG/wiki/index.php?title=SVG2_Requ
irements_Input&section=117

[64]
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

[65]http://www.w3.org/Graphics/SVG/WG/wiki/index.php?title=SVG2_Requ
irements_Input&section=118

[65]
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> [66]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Resolutions

[66] 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>
[67]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Resolutions#CSS_Spec
_dependencies

[67]
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

[68]http://www.w3.org/Graphics/SVG/WG/wiki/index.php?title=SVG2_Requ
irements_Input&section=119

[68]
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

[69]http://www.w3.org/Graphics/SVG/WG/wiki/index.php?title=SVG2_Requ
irements_Input&section=120

[69]
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
[70]http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#
API_for_smooth_transition_action_of_zooming.2Cpannning.2Crotating

[70]
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:
[71]http://www.newdesignworld.com/press/story/470436
... this is a press release talking how we optimized the browser

[71] http://www.newdesignworld.com/press/story/470436

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>
[72]http://www.whatwg.org/specs/web-apps/current-work/multipage/the-
video-element.html#the-track-element

[72]
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>
[73]http://lists.w3.org/Archives/Public/public-web-and-tv/2011Aug/

[73] 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> [74]http://www.w3.org/Graphics/SVG/WG/track/issues/2354

[74] 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> [75]http://www.w3.org/Graphics/SVG/WG/track/issues/2355

[75] 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> [76]http://www.w3.org/Graphics/SVG/WG/track/issues/2356

[76] 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>
[77]http://www.w3.org/TR/SVG11/struct.html#__svg__SVGSVGElement__vie
wport

[77]
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> [78]http://www.w3.org/Graphics/SVG/WG/track/issues/2357

[78] 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>
[79]http://www.w3.org/TR/SVGTiny12/painting.html#NonScalingStroke

[79] 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> [80]http://www.w3.org/Graphics/SVG/WG/track/issues/2359

[80] 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> [81]http://www.w3.org/Graphics/SVG/WG/track/issues/2362

[81] http://www.w3.org/Graphics/SVG/WG/track/issues/2362

<vhardy>
[82]http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0168.ht
ml

[82]
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 [83]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>
[84]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#C
onsider_adding_scrolling_to_editable_text

[84]
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>
[85]http://www.w3.org/TR/SVGTiny12/svgudom.html#KeyIdentifiersSet

[85] http://www.w3.org/TR/SVGTiny12/svgudom.html#KeyIdentifiersSet

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

[86] 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> [87]http://www.w3.org/Graphics/SVG/WG/track/issues/2378

[87] 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> [88]http://www.w3.org/Graphics/SVG/WG/track/issues/2379

[88] 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> [89]http://dl.acm.org/citation.cfm?id=256162

[89] 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> [90]http://www.w3.org/Graphics/SVG/WG/wiki/F2F_Hamburg_2012

[90] 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
[91]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> [92]http://svgopen.org/2012/

[92] http://svgopen.org/2012/

cl: do we want to meet then?

cc: I prefer after

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

[93] http://wiki.csswg.org/planning

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

[94] 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> [95]http://www.w3.org/2012/10/TPAC/

[95] 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
[96]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page

[96] 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

Summary of Action Items

[NEW] ACTION: Brian to create wiki for web animations [recorded in
[97]http://www.w3.org/2012/01/13-svg-minutes.html#action04]
[NEW] 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
[98]http://www.w3.org/2012/01/13-svg-minutes.html#action01]
[NEW] ACTION: Brian to work on the Web Animation spec proposal for
the May FXTF meeting [recorded in
[99]http://www.w3.org/2012/01/13-svg-minutes.html#action02]
[NEW] ACTION: Doug to write scripts showing how a shim could bridge
the old and new behaviors for content under unknown elements.
[recorded in
[100]http://www.w3.org/2012/01/13-svg-minutes.html#action03]
[NEW] ACTION: ed to create registration questionaire for Hamburg
2012 f2f [recorded in
[101]http://www.w3.org/2012/01/13-svg-minutes.html#action05]

[End of minutes]
_________________________________________________________

Minutes formatted by David Booth's [102]scribe.perl version 1.136
([103]CVS log)
$Date: 2012/01/14 05:35:44 $
_________________________________________________________

[102] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[103] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43
Check for newer version at [104]http://dev.w3.org/cvsweb/~checkout~/200
2/scribe/

[104] 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 becaus
e 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 h
ave any external references AFAIK, so if you wanted to draw <svg><image
xlink:href="foo.png"/></svg> into a canvas element then it would proba
bly 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 caba
nier11 cc cl cm cmc ds ed everyone heycam krit scribenick shepazu staka
gi trackbot vhardy
You can indicate people for the Present list like this:
<dbooth> Present: dbooth jonathan mary
<dbooth> Present+ amy

Agenda: [105]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Age
nda
Got date from IRC log name: 13 Jan 2012
Guessing minutes URL: [106]http://www.w3.org/2012/01/13-svg-minutes.htm
l
People with action items: brian doug ed

[105] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda
[106] http://www.w3.org/2012/01/13-svg-minutes.html

End of [107]scribe.perl diagnostic output]

[107] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Saturday, 14 January 2012 05:39:20 UTC