minutes, SVG WG Sydney 2012 F2F day 4

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]

    <birtles> <animate animation-iteration-count=""
    animation-timing-function="" animation-delay="" ... />

    CM: I don't want to break the identity between presentation
    attribute names and property names

    BB: if we match the names exactly, it forces you to have the same
    behaviour and parsing

    VH: as the CSS properties?

    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:51 UTC