W3C home > Mailing lists > Public > www-svg@w3.org > February 2013

minutes, SVG F2F Pyrmont, Sydney day 3 (07/01/2013)

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 07 Feb 2013 17:16:50 +1100
Message-ID: <511346D2.2080600@mcc.id.au>
To: "www-svg@w3.org" <www-svg@w3.org>

And text below:


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

                                - DRAFT -

                     SVG Working Group Teleconference

06 Feb 2013

    See also: [2]IRC log

       [2] http://www.w3.org/2013/02/06-svg-irc



           birtles, heycam, cabanier


      * [3]Topics
          1. [4]border brushes
          2. [5]variable width stroke
          3. [6]Media fragments and SVG stacks
          4. [7]SVG/CSS Matrix harmonisation
          5. [8]Changes to Filter Effects and Custom Filters
          6. [9]CSS OM and SVG DOM improvements; exposing calc
          7. [10]Web Animations
          8. [11]Web Animations continued
          9. [12]Requirements reevaluation continued
      * [13]Summary of Action Items

    <trackbot> Date: 06 February 2013

    <heycam> Meeting: SVG WG F2F Sydney 2013 Day 4

    <birtles> scribenick: birtles

border brushes

    cabanier: in CSS you have the border-image property
    ... where you can slice up an image
    ... and tile the sides
    ... you can stretch them and after a point they start
    duplicating themselves

    <cabanier> link:


    cabanier: we have the same features in Illustrator
    ... and you can define a side and a corner and it does the
    stacking for you
    ... instead of just a png
    ... if you do a google search you can see many places where
    people use this
    ... on the wiki there are several examples

    krit: you could use svg

    cabanier: but that's kind of hard because you have to define
    where the border is

    dino: do the two images orient along the edge

    cabanier: yes
    ... when there's a curve the artwork needs to bend along the
    ... so you might need to add some limitations
    ... e.g. if there was a gradient then you'd need to morph the

    birtles: so is this for just SVG

    cabanier: this is the SVG counterpart to what's in CSS

    AlexD: this would have to be an adaptive dashing style thing
    ... so you have an exact integer number of repeats
    ... like we talked about for dashing where you try to make the
    dash array end on exact integers

    cabanier: you'd use this brush like a stroke
    ... so it also is effected by the stroke-width
    ... e.g. a stroke width of 2 would make it scale by two
    ... there's an e.g. with dashes
    ... so each dash would be one of the images

    heycam: so, theses dashes here, some of them are squashed when
    they're small
    ... but in the non-dashing examples they maintain their aspect

    cabanier: I think in dashing examples they either squash or
    ... when you apply the corners...
    ... I think for now we only want this on polygons
    ... because how do you work out the corner of a path?
    ... even for rects you know where the corners are

    heycam: but you have examples of using this on a path

    cabanier: yes, I just drew these in Illustrator
    ... in the star it uses the corner on the outside but not in
    the inside
    ... I think it is a special case for stars

    <shepazu> (this corners question applies to the "rounded
    corners" proposal from Rigi-Kaltbad, too)

    dino: are you sure?

    cabanier: oh, I think you're right

    krit: it looks like the engine looks for the smallest angle
    ... and orients to that angle

    cabanier: I think the syntax for this would be fairly easy
    ... for rounded corners it doesn't use the corner piece
    ... that's just how Illustrator implemented it

    heycam: is it warping the corner pieces?

    cabanier: yes

    ed: so if you had a sharp corner in the last example with the
    squiggly line
    ... would it get the corner piece?

    cabanier: no

    dino: so you'd only use it for basic shapes?

    cabanier: right

    dino: even if you drew the star as a path you wouldn't get the
    corner piece?

    cabanier: yes
    ... otherwise you have to define what is a corner

    dino: seems like there would be a lot of work in describing how
    you walk a rectangular object...

    cabanier: it would be a lot of implementation work but not so
    much spec work
    ... I don't think the warping would be defined in the spec

    dino: I think how the control points are warped should be
    defined in the spec
    ... if you want it to be interoperable

    heycam: I think you could have a high-level description
    regarding how points along the bezier are mapped

    cabanier: I'm not saying we don't have to do it.. but do we do
    that elsewhere in the spec?

    ed: yes, we do

    <ed> [16]http://www.w3.org/TR/SVG11/text.html#TextPathElement

      [16] http://www.w3.org/TR/SVG11/text.html#TextPathElement

    ed: the method attribute
    ... when you set that to stretch
    ... it says something about how its done but it's not very

    dmitry: I checked and Illustrator does apply the corner pieces
    to custom paths with sharp corners

    cabanier: so it does, you're right

    ed: if you make a star with a path you probably want it

    krit: there's more calculation to determine if the corner
    between two curves is a sharp corner or not

    ed: where is the cut-off point

    krit: maybe it does it on all sharp corners?
    ... these are fairly detailed discussions...


      [17] https://svgwg.org/svg2-draft/painting.html#TermLineJoinShape

    heycam: the new wording about computing the shape of a stroke
    has the kinds of descriptions you would want for the warping
    ... it's a high-level description of taking points on a path
    and turning them into shapes or different points

    <dmitry> Screenshot of the corner processing in Illustrator:

      [18] http://cl.ly/image/0h3l0u0D3r1B

    cabanier: so this would effect getStrokeBBox too right?

    heycam: if some of the tiling pattern didn't fill out the whole
    tiling space or overflow it, would that effect the stroke bbox?

    cabanier: there was some discussion of this in the mailing list
    ... at least it's easier than other brushes like the bristle
    ... I think this is pretty easy and would be nice to have in
    CSS too
    ... in CSS you would just use it like border-image
    ... and if you applied it to a CSS box you wouldn't have the
    deformed beziers
    ... do you think this is useful?

    krit: I think this should not go into SVG2

    birtles: I agree

    krit: so should we continue at all, and if so how should we

    dmitry: Illustrator lets you define two different corner pieces
    (inside and outside corner)

    heycam and cabanier: agree it should not be in SVG2

    <dmitry> Screenshot of two types of corners:

      [19] http://cl.ly/image/1S3B3i1l0E0e

    krit: so do we want the feature?

    heycam: I think we want the feature

    krit: do we want to have a module for this or in SVG.next?

    heycam: I think it could be a separate spec

    ed: sure

    <heycam> dino,


    RESOLUTION: We will continue developing border brushes in a
    separate specification

    <scribe> ACTION: Rik to create a module to define SVG border
    brushes [recorded in

    <trackbot> Created ACTION-3440 - Create a module to define SVG
    border brushes [on Rik Cabanier - due 2013-02-13].

variable width stroke



    cabanier: so this is not going to be for SVG2

    heycam: but we had the requirement to represent InkML traces in
    ... we said we'd enable InkML to be rendered
    ... so we *could* consider it for SVG2

    cabanier: defining it is pretty easy
    ... not sure how hard it is to do in the graphic libraries

    heycam: can't be harder than these border brushes

    cabanier: at any rate, defining it should be very easy
    ... you just say that along these paths we have these points
    and at each point you say, e.g. the stroke should be 200%
    ... and then you draw a catmull-rom curve along the points

    AlexD: why would you do that, when it involves tension

    heycam: I'm thinking we could just extend stroke-width itself
    ... e.g. stroke-width="10px 15px"

    cabanier: I think you want to use percentages
    ... e.g. to represent pressure on the pen
    ... or if you pick up a bigger pen you want to just say 200%

    heycam: (e.g. on the board)
    ... stroke-width="10px" stroke-width-variation="0px 100%, 100px
    100%, 150px 50%"

    birtles: (use case from previous discussion) I want this
    feature to be able to do finger-drawing on a tablet where the
    stroke width varies with touch pressure

    cabanier: I think I prefer stroke-width-varation="0% 100%, 66%
    100%, 10% 50%"

    krit: do you want to be able to specify different widths for
    each side (left/right)

    cabanier: I think that might get complicated because it might
    not always be obvious which side is which

    heycam: I think it is ok

    dmitry: I think if you really want that you can just change the

    heycam: if the widths could be a repeating pattern you could do
    spaghetti lines
    ... I don't think it's much more work

    cabanier: yes, I agree

    heycam: I think you could automatically tile it, especially if
    your offsets are absolute lengths
    ... I would actually be ok with different left-right sides
    ... since I think the implementation difficulty would be the
    ... but what if the two intersected?

    cabanier: they can't since the percentage is always positive

    birtles: is it worth adding the features in stages?
    ... I think the primary use cases would be data from tablets
    and calligraphy
    ... where you probably don't need repeating patterns or
    asymmetric variations

    ed: I think it would be nice to have a spread-method like
    ... where it just repeats
    ... I think you might want to use variable-stroke width for
    custom line cap
    ... where the end tapers off

    dmitry: you could use markers for that
    ... but it doesn't always work

    cabanier: like if you have a gradient on the stroke
    ... the marker would have a separate gradient

    dino: who do we expect to use this?
    ... hand authors? tools to export?
    ... I think this kind of feature is complex to hand author

    cabanier: I think it's not so hard

    krit: of course, you can already export this from Illsutrator

    cabanier: but strokes become a series of paths

    AlexD: cartographers have been asking for this

    dmitry: and if the export from Illustrator loses the original
    path then you can't modify it in script

    birtles: and I think there are many uses cases where you
    create/modify paths from script

    Cyril: does this affect markers

    heycam: yes
    ... because markers can be scaled in size depending on the
    stroke width
    ... but that's probably what you want

    ed: I think there are cases where you don't

    cabanier: I think you want the original stroke-width

    Cyril: in d3 examples, where you have flows of data
    ... and you have arrows where you want the arrow to grow or

    ed: so how should we proceed?

    heycam: if someone is keen to do the work, someone could
    specify the minimum set of features
    ... symmetric stroke width variation with no repeating

    krit: can stroke-width-variation be a shorthand

    heycam: not sure about the naming

    cabanier: it could be

    Cyril: this would be a presentation attribute?

    heycam: as I've written it, yes

    cabanier: can you define a URI somewhere

    heycam: so you can re-use the definition?
    ... inheritance works so that might be enough
    ... at first I'd like to avoid element syntax and just have the
    ... if we need a pre-defined thing we can add it later
    ... it's currently assigned to Doug in the requirements

    (item 20)

    cabanier: I can talk to Doug about it

    <shepazu> (I'm happy to defer to someone else for this,

    <scribe> ACTION: Rik to specify variable width stroking in SVG2
    [recorded in

    <trackbot> Created ACTION-3441 - Specify variable width
    stroking in SVG2 [on Rik Cabanier - due 2013-02-13].

    <shepazu> (also happy to discuss it and give feedback)

    <ed> -- 15min break --

    -- break, 15min --

    <heycam> ScribeNick: heycam

Media fragments and SVG stacks

    krit: I'm not sure on the status of media fragments on the
    <image> element

    … especially for xlink:href

    … I don't think it's specified in SVG

    … should it be combined together with media fragments? allow
    #xywh there as well? seems to be useful, but it's not specified

    … how would that affect our SVG Stacks hack?

    ed: I don't think it would affect it that much

    … unless you pick that particular ID

    krit: there are more fragments that SVG supports that aren't
    supported in Media Fragments

    … choosing the viewport e.g.

    … should we talk to the Media Fragments WG people?

    <silvia> [24]http://www.w3.org/TR/media-frags/

      [24] http://www.w3.org/TR/media-frags/

    silvia: what are the other things you're missing?

    <silvia> spatial dimensions:

      [25] http://www.w3.org/TR/media-frags/#naming-space


      [26] https://svgwg.org/svg2-draft/linking.html#LinksIntoSVG

    ed: you can pass transforms, a viewBox

    Cyril: I don't understand how this depends on xlink:href=""

    krit: Media Fragments conflicts with SVG in some cases

    Cyril: I don't see the problem with XLink href

    … media fragments are defined by the MIME type

    … if you use it in xlink:href="" or src="", it shouldn't matter

    krit: we need to reference Media Fragments

    ed: I don't think they're in very much conflict with each other

    … we should reference Media Fragments

    silvia: are you using Media Fragments with SVG resources yet?

    ed: no

    silvia: SVG resources define how their ID fragments get
    interpreted, if you don't adopted the Media Fragment spec for
    that resource type then there's no conflict

    Cyril: but it makes sense to support Media Fragments, xywh, or
    timing as well

    silvia: you just need to extend the fragment specification for

    Cyril: so t and xywh should be reserved?

    heycam: just reserve "t=" and "xywh="

    Cyril: in Media Fragments you have four dimensions. how does ID

    silvia: nobody has implemented that

    … the way we envision it is that some containers define names
    for sections, it's like imagine having a WebVTT chapter file in
    a webm file, and you have names for sections of the video file

    … and you can use the chapter name to address the chapter

    Cyril: what's the syntax?

    silvia: id=string

    Cyril: so it's not "#<string>" it's "#id=<string>"

    silvia: yes

    krit: for SVG would it be a difference to support #<element>
    compared to #id=<element>?

    Cyril: the question is how to combine them

    … once you start using a freeform name, you can't use an "&"
    and follow it with another dimension

    silvia: we wanted to be able to support multiple dimensions;
    choose this one video segment (temporal), and then choose a
    spatial area

    … that's why we defined the parsing for these media fragments

    … if you don't do that from the start it's difficult to
    post-fit it

    … your selectors are functions?

    … you could do something like "#mediafrag(xywh=…)" to be

    Cyril: you'd have to treat SVG differently then

    … sometimes you don't know what the type of the resource is

    krit: do all media fragments require an equals sign?

    silvia: yes

    krit: then it's probably fine

    … we shouldn't need to have #mediafrag

    Cyril: we could disallow ampersand in SVG IDs, then it combines
    well here

    krit: media fragments in HTML, if you have <img
    src="blah#xywh=…"> you would have the same problem yes?

    silvia: on HTML pages it's difficult, since HTML has specified
    the way a fragment is interpreted

    … often you have a custom web site, e.g. in YouTube you can
    have similar time offsets with fragments

    … but that's not what we've standardised for

    … we've done this only for media files

    … HTML is a different media type

    krit: depends on the MIME type of the document you reference?

    silvia: yes

    … that's how the URL specification has defined fragments to

    krit: so we need to specify how SVG's fragments are interpreted
    ... the timing fragments are useful in SVG too yes/

    ed: we should define how that works

    birtles: we've said for Web Animations we want this to work

    … would be good if this worked for HTML containing documents
    with animations as well as SVG

    Cyril, [27]http://www.w3.org/TR/2006/REC-xml-20060816/#NT-Name

      [27] http://www.w3.org/TR/2006/REC-xml-20060816/#NT-Name

    dino: Cyril is asking how you distinguish #t=… from normal ID
    references in HTML

    Cyril: if HTML doesn't use the same solution as us, disallowing
    "&" and "=", it wouldn't be good

    krit: same problem with SVG in HTML, the MIME type is
    text/html, and the fragments would work differently

    silvia: the HTML MIME type does not support media fragments

    Cyril: yet?

    silvia: I think it's unlikely

    ed: but if we have Web Animations it might be useful

    silvia: we discussed xywh for HTML, it might be an interesting
    feature, but the HTML WG should discuss that

    Cyril: so should we aim for alignining with other media-like
    resources, or what HTML supports?

    silvia: I'd go with both strategies

    … I would want to be as much compatible with that spec as
    possible, and when SVG goes forward have its MIME type define
    how media fragments work, it's a bigger argument for HTML to
    support it

    … I don't think this will break SVG documents, but with HTML it
    could well break pages

    … people might have used #t= to mean something different on
    HTML pages

    … I would orient myself towards that problem, but rather being
    compatible with other media files

    krit: so Media Fragments defines how xywh are parsed, why do we
    need to define that in SVG?

    Cyril: we just need to say image/svg+xml follows media

    silvia: right

    … the Media Fragments working group was bound by the URL

    … fragments are defined interpreted based on the mime type

    … we didn't want to have to deal with all of the mime types
    around, just video

    krit: SVG is still based on IRI, which should allow more

    silvia: it's not a problem; we wrote the spec to be based on

    … the only place where it really mattered was the chapter
    names, named references

    heycam: I think the URL Standard is meant to supersede IRIs

    Cyril: I think I'm fine with the group saying we adopt media
    fragments, and we restrict our IDs not to include xywh=,
    ampersands, etc.

    … and then later can coordinate with HTML WG to see if it's
    possible for them to support this too

    silvia: one part of the Media Fragments spec has been included
    in HTML; it defines how time offsets in videos are interpreted

    Cyril: if you put t=15 does the document timeline start at 0?

    birtles: it does a seek

    … then we need to add automatic pausing

    RESOLUTION: SVG 2 will use Media Fragments.

    <scribe> ACTION: Cyril to add Media Fragments support to SVG 2.
    [recorded in

    <trackbot> Created ACTION-3442 - Add Media Fragments support to
    SVG 2. [on Cyril Concolato - due 2013-02-14].

    Cyril: is #svgView(viewBox()) the same thing as #xywh?

    ed: not quite

    <scribe> ACTION: Brian to define how #t= is interpeted in Web
    Animations. [recorded in

    <trackbot> Created ACTION-3443 - Define how #t= is interpeted
    in Web Animations. [on Brian Birtles - due 2013-02-14].

    … percentages will be different

    krit: for #xywh these reference the original viewport

SVG/CSS Matrix harmonisation

    krit: we have a new function that gets the transform between
    two elements

    … I think this will be harder with CSS transforms

    … since they have 3d transforms

    … and it's not really possible to get a transformation matrix
    over this flattening

    … the question is how do we want to solve this

    … and second, it returns an SVGMatrix which is 2D

    … it's not applicable for this

    … it should return something that can represent 3D matrices

    … I spoke with Dean about flattening

    … we think that it should either give you an exception, a null
    matrix back...

    … somethign that indicates it's not possible to get the

    … something to be resolved is the return type

    … we would need to specify a new matrix

    … CSS Transforms had a spec for it

    … which needed to be removed, since it uses CSS OM

    … Dean proposed Matrix4x4

    … we didn't know at this time where it should live -- maybe in

    … on the window object

    … what does it look like?



    krit: there were some discusisons about whether it should work
    with Euler coordinates

    dino: there was some discussion that day in the SVG meeting
    about this

    … which I never followed up on

    … I think it was about whether to use radians or degrees

    … we have methods on here for both modifying the matrix and
    returning a new one

    … the other big discussion was someone suggested it should
    really be an ECMAScript type

    … someone else discussing whether it shouldn't have all those
    exposed as attributes, it should be a typed array with a
    wrapper of some sort

    krit: they wanted to use it with WebGL as well

    … which needs to be fast

    dino: that's why I have copyIntoFloat32Array

    … but you might not want to call this function each time

    heycam: I don't think there's a concept of live typed arrays is

    dino: I think the suggestion was to have the typed array
    backing the matrix

    … there would be an attribute to access that matrix backing
    data directly

    … in WebGL it would just be a matter of getting that out,
    instead of constantly creating new typed arrays

    … we didn't really have strong drive to get this happening

    … but I think we do now, now that the spec is closer to

    heycam: makes you think well then why not about Points, etc.

    dino: I think that's why it wouldn't make sense to send it to

    … if we just have Matrix

    dino: there is still more work to do with improving SVG DOM

    … should we add something now to expose 4x4 matrices

    … or have conversion functions separate from the SVG DOM

    heycam: could we not replace SVGMatrix with Matrix4x4?

    dino: that was the idea

    krit: we got everything from SVGMatrix on Matrix4x4, then we
    make SVGMatrix inherit from this one

    … there are some things that need to be in SVGMatrix


      [31] http://www.w3.org/TR/SVG/coords.html#InterfaceSVGMatrix

    krit: there are SVGExceptions being thrown

    heycam: that's gone in SVG2

    dmitry: nobody uses skews

    cabanier: why does this issue keep coming up then?

    krit: Mozilla found some pages that did use skew

    dino: people use it for horrible fake 3d, isometric

    dmitry: we should encourage them to not do this by not having
    it in the specification

    cabanier: I know people use skew a lot in animations for fake

    krit: we could strongly ask people not to use it...

    dmitry: it should be easier to make beautiful things, not just
    easier to make ugly things too

    krit: we could have them be deprecated but browsers still
    implement it

    dino: I don't think we can remove skews from transform syntax
    any more

    … do we need to expose them in this interface?

    krit: yes

    dino: sounds like we do if we want to replace SVGMatrix with

    ed: so do we need to fix this in SVG2?

    krit: do we want to go with this new interface? I think yes

    … if it should live in ECMA we can worry about that later

    … whether it should go on window I asked the CSS group for

    heycam: I think just leave it not [NoInterfaceObject]

    krit: which spec should it live in? a new one?

    cabanier: Canvas references SVGMatrix, would be nice to
    reference this instead

    krit: what happens if you have a 3D transform on canvas?

    heycam: who should write this Matrix4x4 spec?

    krit: have to ask first, but I will probably do it

    dino: what about the name Matrix4x4?

    heycam: eh...

    dino: GL calls them matrix4, vec3, etc.

    krit: i prefer Matrix to Matrix4x4

    heycam: should Matrix replace SVGMatrix, or SVGMatrix inherit?

    ed: I don't think it's common for people to rely on "[object
    SVGMatrix]" being the actual object type

    krit: ok, just replace SVGMatrix with the new Matrix then

    ed: as long as we have the same method names I think it should
    be fine

    RESOLUTION: SVG 2 will reference the new Matrix specification
    and replace SVGMatrix with Matrix, once that spec is ready.

    <scribe> ACTION: krit to write up a spec for Matrix [recorded
    in [32]http://www.w3.org/2013/02/06-svg-minutes.html#action05]

    <trackbot> Error finding 'krit'. You can review and register
    nicknames at

      [33] http://www.w3.org/Graphics/SVG/WG/track/users%3E.

    <scribe> ACTION: dirk to write up a spec for Matrix [recorded
    in [34]http://www.w3.org/2013/02/06-svg-minutes.html#action06]

    <trackbot> Created ACTION-3444 - Write up a spec for Matrix [on
    Dirk Schulze - due 2013-02-14].

    ACTION-3444: Also update SVG 2 to reference the spec when it's

    <trackbot> Notes added to ACTION-3444 Write up a spec for

Changes to Filter Effects and Custom Filters



    krit: custom filters are used with CSS shaders

    … so that you can apply some distortion/modification to the

    … in the old specification, the syntax was
    "custom(url('vertexshader') mix(url('fragmentshader') multiply
    src-over), 4 4 attached, param1 value1, param2 value2)"

    … it's very long, hard to read, and only supports GLSL

    … MS asked us to make it more generic to support other shader

    … one idea is "custom()" references an at-rule

    … @filter f1 { … }

    … but this does not support animations

    dino: you could have @filter f2 { … } and animate between f1
    and f2

    krit: we wanted to try to keep it simple

    … the @filter rule tries to emulate @font-face

    … so it has a 'src' attribute, and you can provide a type

    … src: url(…) format("x-shader/x-vertex")

    heycam: these are just hints not to download, like @font-face?

    krit: no it's different from font-face

    … you need all of these resources

    … there's also "geometry: grid(4,4);"

    … and "margin: …;" like a filter primitive margin

    … and "parameters: …;" for the parameters to the shader

    … so what happens with different shader formats.

    … the @filter defines a generic primitive, so this is not
    limited to CSS Shaders

    … if you don't support GLSL, we'd suggest a new media query

    … @media (filter: glsl) { … }

    … so other browser could define new properties on the at rule

    ed: what is the point of the format() yet?

    krit: in case there is a new shader type under GLSL

    dino: WebGL defines a restricted version of GLSL

    … it's not strictly GLSL

    krit: maybe this keyword could be "WebGL" then

    … we can think about that later

    ed: so you have src with format()s in case you support more
    shader types later?

    krit: also you could reference an SVG filter here

    <filter id="f2">

    <feOffset dx="var(x1)" dy="var(x2)"/>


    … something like SVG Parameters or CSS Variables

    … the custom() function would then reference a filter at-rule
    that references the SVG filter

    @filter g2 { src: url(#f2) format('svg'); parameters: x1 30, x2
    30; }

    filter: custom(g2, x1 20, x2 20);

    ed: what is the var() syntax there? is that defined somewhere?

    krit: we're not going to put that in the first version of the

    … since it's not clear how Parameters / CSS Variables is
    working in SVG yet

    … but this is how custom SVG filters can be animated in the

    ed: it might be useful to be able to pass in the document time
    into the filter

    krit: we can think about that for v2

    heycam: I find it a bit strange that format() in src works
    differently from in @font-face

    krit: what if we rename "src" to "filter-src"?

    heycam: maybe… it might be the combination of "src" and
    "format()" that looks to me like formats are hints to avoid

    … why require format() at all given you can look at the actual
    served Content-Type?

    krit: servers might not set that correctly

    dino: there's not even a standardised extension for these files

    … what if you reference from the local file system

    heycam: what is the advantage of 'src' having the same format
    across different shading language @filter rules?

    dino: the source language format is the thing most likely to

    … geometric, margin, parameters make sense with other shader
    languages too

    krit: so are people happy with @filter rule?

    heycam: I like it more than stuffing everything in to the

    … what about the src descriptor, people want a different name?

    Cyril: you plan to have different mime types for vertex vs
    fragment shaders?

    krit: it's the case already

    … that's defined by WebGL

    Cyril: is the mime type registered?

    dino: x-shader/* is not registered, but someone would have
    written something down somewhere

    heycam: for me, you don't need to rename src for now…

    RESOLUTION: Filter Effects changes to use @filter.

    -- lunch break one hour --

    <cabanier> scribenick: cabanier

    heycam: filter media query feels different from other media

    …since those are properties of the device

    ed: maybe @supports?

    heycam: so you could write '@support filter(glsl)'

    … the syntax is extended but not implement

    krit: yes, that seems better
    ... I'm OK with that

    heycam: at some point there will be @supports for @-rules

    krit: inside the rule?

    heycam: you could then have:

    … atrule(filter, src:… format('x-shader')

    … the normal properties just check if they parse correctly

    … so maybe it's not quite right, but I'd be happy

    … Maybe email www-style

    <scribe> ACTION: Dirk to email www-style about at-supports
    filter function [recorded in

    <trackbot> Created ACTION-3445 - Email www-style about
    at-supports filter function [on Dirk Schulze - due 2013-02-14].

    krit: is @filter-rule fine?

    ed: are there other possibilities

    … is everything of the previous syntax possible

    krit: yes

    cabanier: even animations:

    heycam: that's for the @media part not the rule

    krit: do we need a new RESOLUTION?

    heycam: can you do the same as before?

    krit: yes

    RESOLUTION: accept proposed descriptors for at-filter rule

CSS OM and SVG DOM improvements; exposing calc values

    heycam: the question is if we support css lenght and how we
    reflect that in svg

    … Dirk, did you add it already?

    krit: yes. as unknown because we don't want to extend SVG DOM
    at this time

    heycam: so, there are a few new unit types such as rem, vw, vh,
    ch, etc

    ….rem is default font size

    shanestephens_: it's to do layout based on the font

    heycam: for instance to do margins

    shanestephens_: MDN has a good description

    heycam: we want to support all of those

    … my question was that we want to add accessors for all of

    krit: should make it so that it becomes more extensible

    heycam: you could use named properties

    … that makes it open ended. But you'd have to update the spec

    ed: that makes it more clear that the spec is going to be

    … having a group of names makes that more clear

    … the spec refer to the group of supported unit types in CSS

    heycam: named properties would require slightly different

    … but I like them to be visible in IDL

    ed: as long as the spec is clear that they can be updated, it's
    fine by me

    heycam: I think we want an accessor so you can set it by string

    … .x.? to get the string value

    … to write or read the string

    … .value ?

    shanestephens_: I like that

    … value would be a strange name for a unit

    RESOLUTION: add a 'value' attribute to read or write the CSS
    serialization of a unit length

    heycam: there are values like 'calc' and 'attr'

    krit: x = attr('x')

    heycam: that would work

    krit: that depends on the css syntax so it would not fail

    heycam: no. that would not be a problem.

    … you can have a property to looks at attr(style) and that
    would fail to parse

    … do we want calc and attr and var to work in SVG?

    krit: yes

    heycam: and have them work on x and y to work on CSS

    shanestephens_: if something is a calc?

    heycam: you can still look at 'px'

    … should there be an accessor to get the calc value?

    shanestephens_: we have a lot of experience with polyfill and
    we spend a lot of javascript mimicing value parsing

    … web animations has a calc in javascript parser

    heycam: the other half is how this is reflect in SVG length

    … and follow Dirk's example to reflect them as unknown values

    ed: yes, that is the only reasonable value

    <scribe> ACTION: heycam add a string accessor on SVG animated
    length and to make 'calc', 'attr' and 'var' work [recorded in

    <trackbot> Created ACTION-3446 - Add a string accessor on SVG
    animated length and to make 'calc', 'attr' and 'var' work [on
    Cameron McCormack - due 2013-02-14].

    heycam: I changed the spec that if there is a list, you just
    set the first value

    … if there is no value, we add one

    ed: sounds reasonable

    heycam: I didn't add anything to SVGAnimatedAngle

    … since noone is really using that one

    … everyone uses the length one

    cabanier: maybe better to be consistent

    heycam: OK

    <scribe> ACTION: heycam to update SVGAnimatedAngle as well
    [recorded in

    <trackbot> Created ACTION-3447 - Update SVGAnimatedAngle as
    well [on Cameron McCormack - due 2013-02-14].

Web Animations


      [39] https://dvcs.w3.org/hg/FXTF/raw-file/default/web-anim/index.html

    birtles: there are 3 documents

    … the link is the core spec and the intent is to have 2 more
    document to map SVG and CSS features

    … Is Tab's work available yet?

    shanestephens_: it's not quite ready, but I'll provide a link

    <shanestephens_> This is a copy of the CSS integration
    document, but it does rely on features that are not yet firmed
    up in the core specification:


    birtles: we have f2f next week

    shanestephens_: there's a few reasons that the spec is so big

    … we need to provide IDLs and Brian added a lot of diagrams

    … and complete descriptions of processes

    … Also we have a fairly complete polyfill that is only using
    1700 lines of code

    krit: does the polyfill do synchronisation?

    shanestephens_: yes, but it doesn't integrate with CSS and SVG

    … but it works with other libraries

    <shanestephens_> here is the polyfill:

      [41] https://github.com/web-animations/web-animations-js

    birtles: there's a skeleton for the SVG integration

    … but don't even look at that

    … I want to talk about scheduling

    <shanestephens_> (actually it's now about 2200 lines)

    … next week we have a f2f to fix remaining issues

    … and then request FPWD

    … there are 3 contentious features

    shanestephens_: except for video, the main thrust of the doc is

    birtles: the FX taskforce will be asked to review so we can
    publish it

    … and we hope to do that at the end of next week

    shanestephens_: the review will be 2 ways. People will either
    like it or there will be a lot of contentious issues

    cabanier: probably have to ask each group for resolution

    birtles: yes

    dino: It would like to know what changed since I provided

    … a declarative form is more important and it's not in the

    … I notice that the template is taken so that's good

    shanestephens_: for declarative, we would like to CSS
    animation, transition and SVG all work the same under the hood

    dino: yes

    shanestephens_: so that in future version we can push more
    declarative markup in the spec

    dino: OK. Then I have no problem with the model and it does a
    good job of describing what an animation engine does in a

    … my concern is with the really big javascript API

    … CSS transitions became popular because they're powerful
    without being complex

    … people are hesitant for massive APIs

    Cyril: authoring tools are missing

    shanestephens_: it's a lot smaller than SMIL

    … the shim that we built is really quite small

    … another things is that it provides a declarative view

    … It's really very similar to CSS

    … I understand that that doesn't address your concerns

    … the polyfill is mostly for testing


    krit: in theory SVG and CSS animations should have the same
    model under the hood

    … the most important part is that this provides an animation
    model that is currently lacking in CSS

    birtles: there's an appendix


    dino: that's still really big

    birtles: we can talk about things that shouldn't be exposed

    dino: A lot of this stuff is needed

    … an author wants to provide timing to a document

    … he wants things to happen at certain times

    … for example, read long books

    … where we want something to happen at a certain time

    … just that alone, is requested a lot more than low level
    access to an animation

    … scrubbing animation, querying animations, etc

    … but we get almost no request for something like this

    shanestephens_: In Google we could use this a lot

    dino: but most people want simple features

    shanestephens_: chaining animations is low level?

    dino: it would be great to have that.

    … We're on the fence about that one

    … I'm not saying not to provide this

    … having such a massive API as step 1 seems too much

    shanestephens_: Are you suggesting not to provide a JS API?

    dino: no, put more emphasis on the integration specs

    … step 1, describe the timing mode and the next step is to
    provide the integration spec

    shanestephens_: we think that the most important thing is CSS
    and SVG animations use the same model

    … so we agree with you

    dino: I would like to solve of an author that want to make an
    animated page

    … and this API is not a solution for that

    birtles: yes, this is not for authors

    dino: that is why I want those specs at the same time

    shanestephens_: should we have the spec ready at FPWD time?

    dino: yes, but not have such an extensive API

    krit: CSS animations and transitions need a model now

    AlexD: maybe we need to split the APIs into a separate document

    dino: ???

    birtles: there is a way to split things up in 2 parts

    dino: yes, the timing object would allow you to write your

    birtles: that concept is already there

    shanestephens_: that sounds exciting

    … do you think the CSS WG would go for that

    dino: if you have a class '::timeactive'

    … and have a CSS animation in there

    … that would be very powerful

    birtles: we can do a timesheet

    … and I would love to do that

    shanestephens_: so we should split the IDL off and into 2

    Cyril: yes, the size is an issue

    … maybe splitting the spec in separate documents

    birtles: I don't know how that would help

    Cyril: setting time in a document is useful by itself with no

    … media elements could be hooked to that

    birtles: those use cases are already met

    … you can have a media element

    Cyril: you can't have frame accuracy today

    … so maybe one step is solve this problem

    birtles: it's hard to prioritize

    … I'm happy to split the API up

    … with regards to the size, we can work on that

    … but our problem is that we want to harmonize CSS and SVG

    … and we're cutting out a bunch from SMIL already

    … so, it will always be big

    Cyril: how can you integrate inconsistent models?

    … if you map the models, will it break anything?

    birtles: no

    shanestephens_: CSS is underspecified

    birtles: and inconsistently implemented

    <birtles> (that is, some details of SVG are inconsistently

    shanestephens_: would it be OK to delay ::timeactive?

    … or should we do that now

    dino: I would like to have that now and can write something up

    … it would be very useful to a lot of people without exposing a
    large API

    … I would like to reimplement CSS animations in WebKit with
    your spec

    … take canvas for instance that took 8 years and only 2 classes

    <Cyril> ack

    silvia: introducing a big new feature using CSS, SVG and even
    HTML, how much overlap is there with HTML?

    … also when you're introducing this big thing, it's not enough
    and too much. Since people come with their own angles

    … for an HTML person it's not enough but the spec is too big

    … splitting it into more document will help

    … also providing examples and summaries is very helpful since
    it's too hard to digest

    birtles: there are no changes to HTML

    … just additions to document and element interfaces

    silvia: how about animateColor. That is in the spec

    birtles: that's surprising

    shanestephens_: it's tricky

    … people say it's too much but want more features

    … we should stick to the brief that we want to unify CSS and
    SVG animation model

    silvia: the minute you introduce the API you can animate an
    HMTL page

    Cyril: I want to make sure that we can integrate with media

    silvia: you can touch the HTML spec if it's needed

    … there's an interface that will be needed

    dino: <par> and <seq> would be nice to have in the document

    … and it's simpler than javascript

    … I would like to style animation

    shanestephens_: what is the next step?

    … we're working on this full time

    … and a lot of engineering time to make this happen

    dino: where do we want to be in order to make a first draft

    … I think the integration document is the most useful

    birtles: how can you have that without a model?

    ed: yes, I would like the integration specs first

    silvia: I would like to see the markup to see what you're
    trying to do

    shanestephens_: this doesn't really apply here

    … providing examples in markup will not do

    krit1: it seems like we're going in circles

    Cyril: everyone agrees that there should be a unified model

    … at a minimum we should have the model and integration with

    krit1: are timesheets important?

    dino: I would like to

    … I think those are more important

    birtles: I think we can already do that

    Cyril: I would like to integrate with media elements

    <ed> -- 15min break --

    <heycam> ScribeNick: heycam

Web Animations continued

    shanestephens_: I had a suggestion that we could keep the parts
    of the IDL that expose the behaviour of animations generated by
    CSS and SVG, and remove parts of the IDL that let you create
    content through js

    … so we can test the CSS and SVG are in the same model and are
    the same thing

    … and then cyril can go forward with animations in HTML

    … and dean can go forward with timesheets

    … and we can look at completing the js api

    … I think Brian is interested in adding functionality to SVG

    birtles: I'll work on SVG integration

    shanestephens_: v1 of the document can be the model, CSS
    integration, SVG integration, and just enough IDL to confirm
    that all of the timing parameters of the model are working

    Cyril: a browser will be compliant to the standard if it
    exposes the right objects with the right values at the right

    shanestephens_: that's pretty much all we care about.
    functionally that the two specs are aligned.

    birtles: I don't really like exposing a read only model like
    that. I think we should split the API into a separate spec.

    shanestephens_: it wouldn't have to be read only, but you'd
    need to leave out things like play()
    ... the only problem I have with splitting out the API is that
    it leaves nothing testable

    … and if it's not testable, it can't be a spec

    birtles: maybe that's OK

    … and we publish the API later and test that

    dino: a NOTE can go onto the REC track

    birtles: I think we can still work on the API spec, it's not

    … I think we're going to implement it anyway, just pref it off

    … just having a read only API doesn't meet those use cases

    shanestephens_: why do we want to get it to FPWD?

    birtles: I think we want to get rid of the animations stuff
    from SVG and point to this thing

    … that's where this whole discussion is going in terms of FPWD

    … is this going to be a problem for SVG?

    … SVG is moving along, and this one is slowing down

    … we've got to work out how to solve that

    shanestephens_: if we make it a NOTE would that work?

    birtles: we still have the SVG integration document and that
    will be referenced by SVG 2

    shanestephens_: the CSS integration document will only allow
    you to test that CSS transitions

    birtles: what's the whole point of having a unified model, to
    think out loud?

    silvia: from what I'm hearing, you can't have a unified model
    without the JS API?

    shanestephens_: you can't test that it exists without a handle
    on it

    … another way forward would be as part of the spec, specify
    some interoperability primitives between SVG and CSS

    … so have some SVG animations using CSS key frames for example,
    and vv

    … but that's getting in to new features

    heycam: you could test how CSS and SVG animations interact

    shanestephens_: so a model document that says how CSS and SVG
    animations exist in the model and how they interact

    … then you can test the results of that

    birtles: this is not testing much of the animation model

    shanestephens_: can we just expose TimedItem?

    birtles: it's almost more meaningful to allow CSS animations to
    have an absolute start time

    … in terms of unifying the two

    … then at least you know they're working off the same clock

    shanestephens_: that doesn't make them interoperable at all
    ... exposing TimedItem as a r/w object...

    birtles: we could think about that next week

    … if you do that I think you might draw in the rest pretty

    Cyril: you might want to see if people agree with the model by
    implementing something

    heycam: I think it would be fine to go along the REC track,
    perhaps with conformance classes on other specifications using
    the model spec

    … you don't need a test suite to pass CR

    … though you could just wait until you have feedback from
    implementors that they are happy with re-jigging their
    animation implementations in terms of the model

    shanestephens_: you could point to the API spec and suggest
    that as a way for them to test it internally

    silvia: people won't be excited about a model spec

    shanestephens_: I think we're pushing the model faster so that
    it can be normatively referenced

    … the API can still stay as an ED next to it and publicise it

    … brian, dean and I are the people likely to implement in 3/5
    browsers, so it's not like the people who need to see this
    aren't seeing it

    Cyril: will MS start implementing this now that there's a
    unified model?

    dino: wonder if a polyfill running in IE is enough to count as
    an implementation

Requirements reevaluation continued

    [$1\47] Have unknown elements treated as <g> for the purpose of

    AlexD: useful for globalCoordinateSystem

    heycam: I've never been entirely comfortable with changing the
    behaviour here

    ed: I don't like it at all

    shanestephens_: Web Components is like a subset of unknown

    … is that going to end up in SVG as well?

    heycam: they rely on unknown elements being rendered?

    shanestephens_: we'd need to look at exactly what they rely on

    … it's only a subset of unknown elements <x-blah>



    heycam: it would be nice to have explicit wording about exactly
    what is required of unknown elements

    ed: I don't know if it makes sense to separate elements found
    outside of <text> from text content elements

    … that's what you typically get from unknown/fallback

    Cyril: in previous minutes we said it could be a fallback for

    … a new implementation will implement connectors, and a
    previous one would ignore it

    krit: do we have something in mind that we want to add new
    graphical elements in the future?

    … if we wanted introduce a <brush> element as a new resource,
    this wouldn't work as expected

    … for browsers who implement this unknown element, they would
    render the <brush> contents

    … but those who do implement it would not render it

    ed: I think it makes more sense to ignore / not draw unknown

    krit: I think it will harm more than solve problems

    RESOLUTION: We will drop the unknown-elements-are-rendered
    requirement from SVG 2.

    <scribe> ACTION: Cameron to clarify the behaviour of unknown
    elements in SVG 2. [recorded in

    <trackbot> Created ACTION-3448 - Clarify the behaviour of
    unknown elements in SVG 2. [on Cameron McCormack - due

    [$1\47] Remove the requirement to have @width and @height on

    <shepazu> (I think this was a mischaracterization of the
    "unknown elements" proposal)

    heycam: this was to make foreignObject sized by shrink wrapping
    based on its contents

    dino: the width will be based on the viewport in HTML

    … doesn't make sense for it to be wider than that

    krit: once width and height are properties, we have the auto

    … but we should keep the 0 width/height defaults

    heycam: it's not something I feel strongly about

    ed: I'm fine with not doing anything for this one

    RESOLUTION: We will drop the "foreignObject can be
    automatically sized" requirement for SVG 2.

    [$1\47] Improve the fallback mechanism using switch

    Cyril: is this similar to allowReorder?

    ed: this is how you treat unknown elements

    … if you want to switch on something that is a new element,
    then you won't check the conditional processing attributes

    … that's the issue

    … let's say we introduce a new <foo> element in SVG, in old
    user agents you'd still like to see if the new feature string
    is there, and do something special

    … <foo requiredFeatures="blah">

    heycam: you could just wrap it in a <g>

    ed: that's the workaround

    … maybe in some cases you don't want to have some wrapper

    krit: if unknown elements are ignored, then you cannot
    reference it

    ed: render it

    heycam: I say just look at those conditional processing
    attributes if the element is in the SVG namespace

    ed: currently a <switch> would always pick an unknown element,
    since it is considered not to have any conditional processing
    attributes, and therefore passes the tests

    Cyril: you should never pick the element you don't know, what's
    the sense in that?

    ed: either you check the attributes you already know on SVG
    elements, or you just ignore them

    Cyril: so just remove it for the purpose of switch processing

    ed: the only way you can get what you want is to wrap it in a
    known SVG element

    <scribe> ACTION: Erik to do the "Improve the fallback mechanism
    using switch" requirement. [recorded in

    <trackbot> Created ACTION-3449 - Do the "Improve the fallback
    mechanism using switch" requirement. [on Erik Dahlstrφm - due

    RESOLUTION: Keep the "Improve the fallback mechanism using
    switch" requirement in SVG 2.

    [$1\47] Provide a way to control audio level and playback

    heycam: sounds like we should get this behaviour from the
    HTMLAudioElement interface

    … so I don't think SVG needs anything specific

    ed: the previous discussions didn't include <audio>, but I
    think they should be

    ACTION-3432: Should also add <audio>.

    <trackbot> Notes added to ACTION-3432 Edit SVG 2 to add the
    iframe, canvas, video elements.

    RESOLUTION: The "Provide a way to control audio level and
    playback" SVG 2 requirement does not need any action, as we
    will get this functionality from HTMLAudioElement.

    [$1\47] Provide positioning information in MouseEvents

    AlexD: returning a user space position

    heycam: I thought I had a proposal on SVGPoint to get the
    UIEvent's position in a given element's coordinate space

    krit: I'd like to not encourage SVGPoint but rather a more
    general Point that's being discussed in CSS

    heycam: the problem is UIEvent is not really defined by us
    ... I'll take the requirement

    RESOLUTION: We will keep the "Provide positioning information
    in MouseEvents" requirement in SVG 2.

    <scribe> ACTION: Cameron to do the "Provide positioning
    information in MouseEvents" SVG 2 requirement. [recorded in

    <trackbot> Created ACTION-3450 - Do the "Provide positioning
    information in MouseEvents" SVG 2 requirement. [on Cameron
    McCormack - due 2013-02-14].

    [$1\47] Support CSS3 Color syntax

    ed: this one already done

    [$1\47] Support CSS3 image-fit

    ed: got renamed to object-fit
    ... I'll keep that, if I have the time to do it

    <scribe> ACTION: Erik to do the "Support CSS3 image-fit" SVG 2
    requirement. [recorded in

    <trackbot> Created ACTION-3451 - Do the "Support CSS3
    image-fit" SVG 2 requirement. [on Erik Dahlstrφm - due

    RESOLUTION: We will keep the "Support CSS3 image-fit" SVG 2

    [$1\47] Make it easier to write a zoom/pan widget, possibly by
    adding convenience method to get scale/transfer

    heycam: so we discussed in zurich possibly extending CSS
    overflow and tying zoom/pan to that

    … Tab was interested in this

    … but it does not exist as a proposal yet

    … and needs more thought

    … I say defer unless there is a concrete proposal

    ed: yep

    RESOLUTION: We will defer the "Make it easier to write a
    zoom/pan widget" SVG 2 requirement unless a concrete proposal
    is forthcoming.

    [$1\47] Align with CSS Value and Units

    heycam: I'd like to take that one

    <scribe> ACTION: Cameron to align SVG 2 with css3-values.
    [recorded in

    <trackbot> Created ACTION-3452 - Align SVG 2 with css3-values.
    [on Cameron McCormack - due 2013-02-14].

    RESOLUTION: We will keep the "Align with CSS Value and Units"
    SVG 2 requirement.

    [$1\47] Deprecate baseline-shift and use vertical-align

    heycam: contingent on me rewriting the whole Text chapter

    … I will keep it

    RESOLUTION: We will keep the "Deprecate baseline-shift and use
    vertical-align" SVG 2 requirement.

    [$1\47] Allow video elements to have captions, tracks, etc

    krit: I don't know why I put my name there

    heycam: should be part of Takagi-san's action, given he is
    adding <video>

    krit: so <track> and <source> would both be SVG elements as

    ACTION-3432: Should also add <track> and <source>.

    <trackbot> Notes added to ACTION-3432 Edit SVG 2 to add the
    iframe, canvas, video elements.

    RESOLUTION: We will keep the "Allow video elements to have
    captions, tracks, etc" SVG 2 requirement.

    [$1\47] Allow clip to reference any element

    heycam: Chris' name is on that currently

    krit: the problem is you have a <g> with a <rect>, why should
    that not clip while a plain <rect> would clip?

    … I don't think this would be a huge problem for anyone to

    heycam: if you have an existing shape, you don't want to
    duplicate it to put it in a <clipPath>

    krit: I'm not against it but I am not interested in doing the
    spec work

    cabanier: I will take it

    birtles: we already have a resolution to allow a <g> in a

    <scribe> ACTION: Rik to allow the clip-path property to
    reference non-<clipPath> elements in SVG 2, and to allow <g> in
    a <clipPath>. [recorded in

    <trackbot> Created ACTION-3453 - Allow the clip-path property
    to reference non-<clipPath> elements in SVG 2, and to allow <g>
    in a <clipPath>. [on Rik Cabanier - due 2013-02-14].

    <birtles> [50]http://www.w3.org/2012/01/13-svg-irc#T03-58-11

      [50] http://www.w3.org/2012/01/13-svg-irc#T03-58-11

    RESOLUTION: We will keep the "Allow clip to reference any
    element" SVG 2 requirement.

    [$1\47] Promote some attributes to properties

    krit: so this is just allowing auto for lengths etc.?

    heycam: this is the whole property promotion change

    … unless somebody puts their hand up, defer

    krit: leave it in the list and see if we have time for it later
    ... I just know I won't have the time in the next few months to
    look at this, maybe after it

    heycam: how about I put your name next to it

    krit: ok

    <scribe> ACTION: Dirk to do the "Promote some attributes to
    properties" SVG 2 requirement. [recorded in

    <trackbot> Created ACTION-3454 - Do the "Promote some
    attributes to properties" SVG 2 requirement. [on Dirk Schulze -
    due 2013-02-14].

    RESOLUTION: We will keep the "Promote some attributes to
    properties" SVG 2 requirement for now, and hope Dirk gets time
    to do it.

    [$1\47] Have an advance font metrics interface

    heycam: seems deferable to me

    dino: what does this mean? isn't there a measureText API in

    ed: that's usable for SVG as well
    ... if we don't have to do anything that's good too

    cabanier: I'm not sure if people are happy with that API

    dino: if you can defer something to another group, and they're
    actually going to do it...

    ed: what kind of things does it give you?

    dino: the descender lengths, ...

    cabanier: font bounding boxes, widths

    RESOLUTION: We will defer the "Have an advance font metrics
    interface" to the canvas spec.

    <scribe> ACTION: Rik to investgate making the canvas font
    metrics interface without needing a <canvas> element. [recorded
    in [52]http://www.w3.org/2013/02/06-svg-minutes.html#action17]

    <trackbot> Created ACTION-3455 - Investgate making the canvas
    font metrics interface without needing a <canvas> element. [on
    Rik Cabanier - due 2013-02-14].

    ACTION-3455: Maybe by making TextMetrics take a constructor
    with a text string, element context for style.

    <trackbot> Notes added to ACTION-3455 Investgate making the
    canvas font metrics interface without needing a <canvas>

    -- finish --

Summary of Action Items

    [NEW] ACTION: Brian to define how #t= is interpeted in Web
    Animations. [recorded in
    [NEW] ACTION: Cameron to align SVG 2 with css3-values.
    [recorded in
    [NEW] ACTION: Cameron to clarify the behaviour of unknown
    elements in SVG 2. [recorded in
    [NEW] ACTION: Cameron to do the "Provide positioning
    information in MouseEvents" SVG 2 requirement. [recorded in
    [NEW] ACTION: Cyril to add Media Fragments support to SVG 2.
    [recorded in
    [NEW] ACTION: Dirk to do the "Promote some attributes to
    properties" SVG 2 requirement. [recorded in
    [NEW] ACTION: Dirk to email www-style about at-supports filter
    function [recorded in
    [NEW] ACTION: dirk to write up a spec for Matrix [recorded in
    [NEW] ACTION: Erik to do the "Improve the fallback mechanism
    using switch" requirement. [recorded in
    [NEW] ACTION: Erik to do the "Support CSS3 image-fit" SVG 2
    requirement. [recorded in
    [NEW] ACTION: heycam add a string accessor on SVG animated
    length and to make 'calc', 'attr' and 'var' work [recorded in
    [NEW] ACTION: heycam to update SVGAnimatedAngle as well
    [recorded in
    [NEW] ACTION: krit to write up a spec for Matrix [recorded in
    [NEW] ACTION: Rik to allow the clip-path property to reference
    non-<clipPath> elements in SVG 2, and to allow <g> in a
    <clipPath>. [recorded in
    [NEW] ACTION: Rik to create a module to define SVG border
    brushes [recorded in
    [NEW] ACTION: Rik to investgate making the canvas font metrics
    interface without needing a <canvas> element. [recorded in
    [NEW] ACTION: Rik to specify variable width stroking in SVG2
    [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [70]scribe.perl version
     1.137 ([71]CVS log)
     $Date: 2013-02-07 06:14:08 $
Received on Thursday, 7 February 2013 06:17:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:31 UTC