Minutes, Rigi-Kaltbad F2F 2012 - Day 1

As html:


as text:


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

                                  - DRAFT -

                       SVG Working Group Teleconference

17 Sep 2012


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

      See also: [3]IRC log

         [3] http://www.w3.org/2012/09/17-svg-irc



             nikos, ed, birtles, TabAtkins__, heycam


        * [4]Topics
            1. [5]Pass Path object to SVG path
            2. [6]Linking to external style sheets — should we have
            3. [7]enable-background naming in relation to compositing
               and blending
            4. [8]Filter Effects - keep new fe*elements that lack
               description ATM?
            5. [9]Filter Functions
            6. [10]Removing pixelUnitToMillimeter{X,Y} and
            7. [11]How to internationalize "title"?
            8. [12]Removing pixelUnitToMillimeter{X,Y} and
            9. [13]passing path object to svg path
           10. [14]new arc command
           11. [15]<image> as paint server for SVG (already resolved
               to have <gradient>)
           12. [16]color interpolation filters for shorthands
           13. [17]Perlin noise
           14. [18]Need a new filter shorthand for noise?
           15. [19]Masking issues
        * [20]Summary of Action Items

      <trackbot> Date: 17 September 2012

      <heycam> Meeting: SVG WG Switzerland F2F Day 1

      <nikos> scribenick: nikos

Pass Path object to SVG path

      krit: It would be better to discuss this when Tab is here

      Topic moved

Linking to external style sheets — should we have <link>?

      heycam: I was wondering, in the spec at the moment (1.1), it
      says if you want to reference external stylesheets you should
      use xml processing instruction
      ... we should have another way as well
      ... we at least need to say @import works
      ... referencing css should get that for free

      krit: Is it not possible currently?

      heycam: You can't
      ... you can't use the xml stylesheet processing instruction in
      html so we should decide what is the prefered way to link to
      external stylesheets
      ... one option is to have link in svg, just like in html

      birtles: yes

      ed: What would happen if you copy pasted svg with link element
      into html5
      ... link is current an html element so if you pasted svg that
      is using it into html would it go back to html?
      ... you can create it with the dom or put it in a foreignObject

      heycam: it seems to work in firefox
      ... I was testing whether the parser breaks out into html



      shepazu: Isn't there a white listing of svg elements? or is
      that just for changing case?

      heycam: Yes, just changing case

      krit: what happens if you move the node in the DOM?

      heycam: I think the link element in the html namespace doesn't
      have any effect at the moment
      ... if you try and reference some stylesheet would it work?
      ... it looks like the way it behaves is - you can have it
      anywhere in the document
      ... if we want it to work we specify it the same way except
      it's in the svg namespace
      ... I think we are eventually going to have a bunch of these
      elements that either share or that can work in both svg and
      html namespaces

      krit: I'm just testing safari, if you put a link elements it's
      in the svg namespace

      heycam: what do you think of the idea dirk?

      krit: I like it but I'm wondering what happens when you move
      nodes in the DOM
      ... I'm a bit afraid the namespace won't change if you move it
      in the DOM

      heycam: nothing changes automatically when you move it

      krit: and is that ok?

      shepazu: henri will complain about changes to the parser - are
      there any?

      heycam: not for this because it's already in the svg namespace
      ... maybe it would be a problem if it broke out

      krit: I wish to have the link element

      heycam: it gets put in the html namespace
      ... you can't declare namespaces explicitly but the dom nodes
      get created in the namespace

      shepazu: I think the reason for doing it this way is to allow
      authors to do it without thinking about it - they already know
      how to do it in html

      heycam: I think it would work nice and obviously

      cabanier: it works in Chrome

      shepazu: if that's true, we should match that user agent

      heycam: I couldn't get it work in Chrome

      cabanier: I know it loads the sheet (can see it in the
      debugger) but I don't know if it applies it
      ... so it's like half implemented



      heycam: anyone think it's bad idea

      all: no

      shepazu: we should ask the html working group

      heycam: we should ask them if there is anything we haven't
      thought of

      Resolution: We will add a link element to SVG that behaves in
      the same way as HTML

      <scribe> ACTION: Cameron to email the HTML and WhatWG working
      groups to ask if there any problems related to adding the HTML
      link element into SVG [recorded in

      <trackbot> Created ACTION-3351 - Email the HTML and WhatWG
      working groups to ask if there any problems related to adding
      the HTML link element into SVG [on Cameron McCormack - due

enable-background naming in relation to compositing and blending

      cabanier: The name is a bit confusing
      ... it doesn't match what users are familiar
      ... in the compositing spec it was replaced with isolation
      ... so we have the existing enable-background keyword, we can't
      get rid of it or it will break content
      ... we were thinking of having it shadow
      ... like an alias

      krit: css wg tries to define shadowing properly
      ... they have the same problem for some text properties

      nikos: we are thinking that the property should apply to
      compositing and blending and filter effects
      ... you shouldn't be able to specify different modes for each

      heycam: so there's 2 issues really, having the property apply
      to both and the naming
      ... do you have an example of css shadowing?

      krit: not yet, we don't have a specification, but the css wg
      have expressed an interest in the idea

      heycam: what about if you use the css om to look up property
      ... like there's a single variable underneath but there's 2

      krit: the question is which takes effect if both are specified

      cabanier: I think the last one wins
      ... what happens currently if you say 'opacity=1 opacity=0.5'?

      heycam: what happens currently for prefixed and not when you
      support them both?

      krit: they are both in the style declaration as far as I know

      heycam: with one underlying variable?

      krit: I'll have to check

      heycam: I assume the css working group wants to define how this
      works and not us

      cabanier: so are we ok combining them?

      heycam: I think so - as long as enable-background works for
      existing things
      ... so enable-background has numbers when you specify new? or
      did we get rid of that

      krit: we got rid of that
      ... looking at the source code - we treat them as different
      ... for box-shadow and webkit-box-shadow we have two different
      style declarations
      ... you can set box-shadow and webkit-box-shadow and they can
      be different
      ... when rendering one will win but I'm not sure which

      heycam: I think that as long as it is worked out then I'm ok
      with it

      cabanier: do we know who is working on the shadowing?

      krit: no, we'll have to ask

      Resolution: We want isolation property to shadow
      enable-background and we will ask the CSS working group about
      the details

      <scribe> ACTION: Rik to ask CSS WG about how shadowing will
      work for enable-background [recorded in

      <trackbot> Created ACTION-3352 - Ask CSS WG about how shadowing
      will work for enable-background [on Rik Cabanier - due

      krit: I think we will put both properties in Filter Effects and
      mark one as preferable

      nikos: So is it ok for one property to control both
      filter-effects and compositing and blending?

      all: yes that's ok

      Resolution: The enable-background/isolation will apply to both
      Filter Effects and Compositing and Blending

Filter Effects - keep new fe*elements that lack description ATM?





      krit: We have different filter effects that lack definition and
      I would like to know if we want to keep them and add
      description or is it not neccesary?
      ... I'm just talking about filter primitives and not the

      cabanier: does anybody implement these?

      krit: no
      ... we are about to implement feCustom

      heycam: who wanted them ?

      ed: diffuse specular was meant to be an optimisation to give
      better performance
      ... I'm not sure if it's really needed as the implementation
      can analyze the filter chain and do the same optimisation

      heycam: would it make it better for authors?

      ed: probably not

      heycam: I say get rid of them then

      ed: I don't mind removing them if they don't seem to be useful
      ... you could do feUnsharpMaskElement with scripting and other
      filter effects
      ... but we don't have a shorthand for it

      Resolution: Remove feUnsharp and feDiffuseSpecular from Filter
      Effects specification for now - may be added again in future



Filter Functions

      are other shorthands needed?

      krit: The question is do we put in a bug report on Safari for
      functions that are not implemented?
      ... I had suggestions for other filter functions that we could
      have, but I have not had any feedback
      ... so I'm wondering if we can remove the issue

      heycam: it doesn't hurt to keep it in, but if you're wanting to
      finalise and go to last call then you can remove it

      krit: there's no problem adding new shorthands in the later
      ... the question is do we freeze what we have now?

      heycam: I think the set that is there currently is a reasonable

      Resolution: Remove filter function suggestions (issue 5) from
      Filter Effects spec

      <scribe> ACTION: Dirk to file a bug and track filter functions
      (issue 5) removed from Filter Effects spec [recorded in

      <trackbot> Created ACTION-3353 - File a bug and track filter
      functions (issue 5) removed from Filter Effects spec [on Dirk
      Schulze - due 2012-09-24].

Removing pixelUnitToMillimeter{X,Y} and screenPixelToMillimeter{X,Y}

      heycam: I didn't know this existed and I'm not sure anyone
      would use these API functions

      krit: Is anyone using them?

      heycam: I'm not sure, I can check.

      andreas: is there an alternative way to get at the pixel size?

      heycam: I think not but I think it's been discussed in the CSS
      WG whether you should access the real DPI and do something
      based on that

      cabanier: you mean the HD stuff?

      heycam: I'm not sure

      krit: so why do you want to remove it?

      heycam: our implementation returns a constant value assuming 96

      cabanier: what does webkit do?

      krit: the same thing

      cabanier: it could be implemented to not be constant in the
      future - for HD devices

      krit: the idea is that we want to know how many mm it is on the

      heycam: I remember people objecting to that in some other

      cabanier: how do you know what the screen size is?

      krit: Firefox used to expose that information in an API but
      removed it.

      heycam: now everyone has converged on CSS units being a fixed
      number of pixels

      krit: the problem is that some platforms don't give you the
      exact DPI, so it could not be implemented on some platforms

      heycam: I think one of the problems with physical units is you
      want to know it for different reasons - like touch events
      (finger size) and font size (but how far away are they from the

      krit: I don't know how they would be used

      shepazu: you'd be surprised - some people implement for one
      browser and if it's implemented in one browser it gets used

      ed: Opera is hard coded also
      ... I think it's the same value as other implementations

      krit: the css working group is looking into ways to get screen
      pixels per CSS pixel.

      heycam: but it doesn't tell you the physical size

      cabanier: are you going to remove pixels per inch as well?

      heycam: yep there's not 4 methods

      cabanier: I think somebody somewhere is using them

      ed: I'd be surprised to see them used

      heycam: I just googled screenPixelToMillimeterX and got no hits
      ... with svg file types

      cabanier: I wonder if they will become more useful
      ... in future

      heycam: I would like to ask the CSS WG what they think about

      krit: the question is how to get the physical size, but I don't
      think the CSS WG is working on that

      heycam: the topic about mm not being real mm anymore comes up
      often and I'd like to know the details
      ... is it because it's probably not what authors want

      krit: if I say 2cm but then project it on the wall I don't want
      it to be 2 cm

      heycam: I'll ask Chris

How to internationalize "title"?

      Tav: This came up at SVG open. Someone was asking whether it
      could be done.

      heycam: My first suggestion would be to allow system language
      on the title element.

      ed: that's already done isn't it ?

      heycam: I'll look
      ... The question is how to internationalise the title

      shepazu: how about we use switch?

      Tav: how would it work?

      shepazu: you would have the switch element with different
      copies of the titles

      heycam: what is switch a child of ?

      shepazu: how about we change switch to allow text content ( if
      it doesn't already)
      ... I think switch only works at an element level now and not
      at a text level
      ... I think we should change it to text
      ... then you would switch on the actual text content rather
      than on the element
      ... title would be a child element

      krit: can you change paragraphs in HTML to change content based
      on the language?

      shepazu: there is no mechanism for doing that
      ... since we are changing switch anyway, we could add something
      like a span that is basically meaningless? We have tspan - it's
      not a child of title
      ... we have a few options
      ... we can change switch to have text content, but what is the
      child element of the switch
      ... we can change title apply to the parent of the switch
      ... if title is encased in a switch element it jumps up one
      level - the switch is transparent in regards to the title

      Tav: what about the desc element?

      shepazu: or tooltip, or whatever
      ... they'd be the same

      heycam: on switch you can have all the group attributes.

      shepazu: people shouldn't use switch for that - you can but you
      ... switch should be transparent

      heycam: I think you should be able to do multiple title
      ... like <rect><title systemLanguage="..." />
      ... or have language tags which are subsets
      ... we could resolve that the first title element that matches
      the conditional processing attributes is used
      ... if you want a fallback you have a title without conditional

      <ed> just playing a bit with the systemLanguage:

        [29] http://jsfiddle.net/YueKQ/

      heycam: and resolve that only one title applies to an element

      shepazu: that's good. So we'd be getting rid of the switch
      element for this case
      ... we should tell people, for legacy reasons, always put the
      default first

      krit: and instead of systemLanguage can we just use lang?

      shepazu: it might not be the system language it might just be
      the language of preference, so that sounds like a good idea
      ... we can change it in switch as well
      ... anything camel cased needs to die, die, die, die, die!
      ... I agree with something short but we'd be overloading lang
      ... but that's actually useful
      ... the problem is, what happens if you do

      <text> <tspan lang="de">Hallo</tspan><tspan lang="en">he

      heycam: I would be fine with allowing lang on title as a
      special thing

      shepazu: it seems strange

      krit: in general you can just display one title

      shepazu: are we going to generalise this and get rid of the
      switch element in other circumstances?

      heycam: I don't think it would work in other cases

      shepazu: ok I'm fine with it for any meta element (description
      ... we are giving special characteristics to title with respect
      to what the language is

      heycam: I'm ok with that
      ... I think systemLanguage makes more sense with the current
      functionality but lang looks nicer

      shepazu: lets leave lang as a special meta data thing that is a
      special case of switch

      ed: for title it works not sure about desc

      Tav: how is title as an attribute different from title as an
      ... do the browsers treat it differently?

      shepazu: We just hint what you should do

      heycam: one of the arguments of having title as an element is
      good for languages which require disambiguation of direction
      ... svg doesn't have the elements to control that so I think
      it's a moot issue for us
      ... what about if we had title as a property?

      shepazu: that would promote poor practice for

      heycam: I don't know if you'd want to download a big file with
      lots of languages

      shepazu: I quite like using many languages in SVG. it wasn't
      designed to be text heavy.
      ... one thing we didn't talk about is - a common workflow for
      skins is to point to an external resource for the languages
      ... it looks up the value and inserts it. We could enable
      something like that for SVG
      ... people could point off to their text file that contains
      different languages

      heycam: I think you could already do that for text other than

      shepazu: we should define how that happens

      heycam: it's defined.

      shepazu: We should give examples of how it works to promote
      best practices
      ... it could be an href like tref and if it's defined you go
      and retrieve it and thats where all the switching stuff is
      ... if it doesn't get the file then it could use the default of
      what you put in the <text>
      ... I think it would allow people to customise these things
      more easily - it's just a proposal

      Tav: allowing lang on title solves the use case that was put to
      be at SVG open

      krit: so the first title doesn't need a lang but the rest do?

      heycam: current implementations look at the first title only,
      so if you are happy having that as a fallback that will always
      work you need to put it first

      and then you could still put lang on it if that's what you want
      for the default

      heycam: the issue is, I think, if you have the first title and
      it has an obscure language, you don't want that to be the
      default in the new system if other languages are provided

      krit: I don't agree,

      shepazu: for implementations that support this it will check
      every language and display the first match
      ... so it has the behaviour you want
      ... it's just for legacy purposes the default is the first

      krit: that's ok

      heycam: the only downside is the order checking is different
      from switch

      shepazu: it's not switch though it's something different

      Resolution: Add lang to title and desc

      <TabAtkins> Ugh, I slept straight through my alarm, wow. Where
      are we? Like, physically?

      <TabAtkins> kk

      <scribe> ACTION: Tav to add lang to tile and desc [recorded in

      <trackbot> Created ACTION-3354 - Add lang to tile and desc [on
      Tavmjong Bah - due 2012-09-24].

Removing pixelUnitToMillimeter{X,Y} and screenPixelToMillimeter{X,Y}

      andreas: I did some reasearch
      ... there's a property you can create in Javascript called
      ... Opera supports it but it has a different value than WebKit
      ... that's all I've really found that does that

      Tab: It's a proprietary webkit thing right now



      Tab: I think if they're use-less remove them but they could be
      useful since we have the possibility of non-square pixels

      nikos: would it be more useful to just get the ratio and not
      worry about the size?

      Tab: I think getting the X width is the most useful and then Y
      could either be an actual height or a ratio

      heycam: this seems to be a bit different since the SVG
      functions relate to a specific size on the screen rather than a

      <ed> scribeNick: ed

passing path object to svg path



      DS: in html canvas we have an interface to build a path object
      ... would be good if we could get the path and pass it to the
      ... to append to the svg path

      CM: can it serialize to the svg pathstring?

      DS: no, there are some differences
      ... arcto for example
      ... suggest we leave it up to the browser to normalize the path
      ... and not specify exactly how

      CM: i think it should be specified

      RC: if you draw a circle it stores a bunch of bezier curves
      ... so if you read the path out it looks ok, but it's no longer
      a circle

      doug: so if I do a circle in skia and a circle in cairo i would
      get the same result?

      DS: might be different, but should look the same

      doug: is this exposed to the user?

      TA: the UA would need to remember the original commands,
      doesn't do this atm

      DS: i'd prefer the first version to not specify the

      CM: i don't like it

      TA: if you're doing it in script you're going to have to do it

      BB: scripts handle one segments produces in one browser, that's
      how most authors work

      Doug: experienced that with freaky mouth example, didn't work
      in opera due to how path normalization worked there

      CM: we could require one or more beziers
      ... not knowing how many you get

      Doug: doesn't help the author at all

      CM: the predictable thing is that you'll get a number of

      doug: think about animation

      DS: we could specify how arc is normalized, as quadratic curves

      TA: all implementations support cubic beziers

      CM: why not have a configurable thing to store the original
      path commands?

      TA: we should specify how many beziers an arc gets turned into

      BB: is there a concrete usecase for this? or is this just about
      the procedural api for creating the path?

      TA: i think the api is a use-case

      BB: we could just support the canvas path api in svg

      TA: the path is a toplevel global api, so you can create the
      path object without having a canvas
      ... will break paper.js, but that's fine, will just shadow the
      native interface

      CM: there's an interface CanvasPathMethods that we could
      ... to have them directly on the <path> element

      DS: but then you can't use this to create a canvas path, and
      reuse the path object

      RC: you can contruct it with an svg path string

      TA: we could also make it serialize out to something that works
      in svg path@d attribute

      DS: like that idea
      ... but it doesn't make sense that it has to serialize and then
      reparsed by svg

      ED: agree

      Doug: element.addPath(obj) to append that path
      ... you might want to animate and reuse and so on

      CM: how would you get arcs?
      ... with the procedural api

      DS: you can't, you'd get cubics back

      Doug: everybody hates the arc syntax in svg
      ... with catmull-rom we thought to translate that into beziers
      ... you should be able to find out what it converted to

      <shepazu> shepazu: and you could chain commands

      CM: would like the native api to be able to create the native
      path commands, like arc, catmull-rom etc
      ... so if I create an arc with the API and put it into an svg
      <path> element that the arc is still an arc

      DS: but then the mapping isn't 1:1

      CM: you can't tweak everything afterwards if it's normalized
      ... but the arc syntax might be different betweent the api and
      the svg commands

      doug: there should be a way to get the non-normalized path out,
      you should be able to get both that and the normalized variant

      TA: we want to normalize (which needs to be specified)
      lineto,moveto, cubic beziers and close path

      CM: i want to be able to say .arc and have that turn into arc

      TA: why? the syntax is different

      CM: if we have the nicer path syntax in svg then we could have
      a direct mapping

      TA: so taking the path commands and adding it to svg, plus
      extending the api?

      CM: as long as it's possible procedural things and get the
      actual path commands

      (discussion on spec stability)

      TA: the path object stringifies to a normalized path string

      CM: how many beziers does an arc get turned into?

      TA: needs to be specified

      RESOLUTION: we want to add a stringifier on the path object
      that returns a string using normalized svg path syntax
      ... svg path elements gains a addPath method that appends path
      object to the path

      CM: does canvas paths need to start with a moveto?

      TA: not required, starts at 0,0
      ... some things start implicit subpaths
      ... e.g the rect command

      <heycam> String(new Path("M … A …"))

      <heycam> normalizes the path back to an SVG path segment list

      RESOLUTION: it will be possible to normalize explicitly and
      stringify the result

      <TabAtkins> (new Path().addPath("M... A...")+''

      <TabAtkins> (new Path()).addPath("M... A...")+''

      RESOLUTION: there will be a method that normalizes any svg
      shape into a path object

      BB: so adding the canvas api methods to the svgpathseglist

      TA: if we put it on the path element id' expect it to be
      ... but if we put it on the svgpathseglist then i'd expect

      CM: where you put the interface is just baout how much you want
      to help the authors

      TA: so seglists could be smarter

      CM: seems confusing

      BB: i do want a simple api, but avoiding duplication is maybe

      CM: e.d.arcTo(...)
      ... e.arcTo(...)
      ... think the second one is not necessary

      RC: if you do addPath it works

      CM: i'd like to be able to set the svg path from a string

      BB: think it should be on the seglist interface

      CM: so adding addPath to the svgpathseglist

      DS: i think it should be on the path element

      CM: think it makes sense to have all path manipulations on the
      svgpathseglist interface

      DS: what's on the svgpathseglist api now?

      TA: path manip methods

      DS: doesn't quite fit tehre IMO

      CM: BB thinks it'd be more useful to have retained pathseglists
      ... without having it attached to a path element
      ... so the worry is that we'll have two such path object
      representations (svgpathseglist and the path object)

      BB: who's going to revise the path apis in svg?

      CM: i think i have an action to do that

      <scribe> ... new SVGPathSegList(canvaspath)

      Andreas: does addPath start a new subpath?

      Doug: you can use clear to clear out the path so that you can
      have a blank canvas to draw on
      ... addPath will add a new moveto, but what if you want to add
      commands to that?
      ... to a existing path

      CM: you could stringify and strip out the movetos

      Doug: couldn't we just have addSegment to just append/continue
      the path?
      ... could we make addSegment strip out the implicit path API
      ... usecase: to append segments to an existing path

      TA: you don't know if the moveto was explicit or implicit
      ... due to normalization
      ... i want addPath and extendPath
      ... extendPath cuts off the first moveto

      RESOLUTION: add extendPath - which acts as addPath but trims
      off the initial moveto

      doug: so are we adding arcTo?
      ... and what do we do with catmull-rom?

      CM: these new commands should be on the canvas path api so both
      can use them?

      doug: yes, sounds useful for both

      RESOLUTION: add new procedural methods for catmull-rom and add
      canvas-like arc commands in svg path syntax

      CM: there are arc and arcto, and ellipse

      TA: arc and ellipse use startangle,endangle

      RESOLUTION: add a 'd' property to the svg path element for
      accessing the pathseglist

      BB: allow svgpathseglists to be created independent of the svg
      path element
      ... allow assigning a pathseglist object ot the path element
      (pathelm.d = seglist)

      doug: should have a json serialization of the path, in addition
      to the stringification

      CM: someone has requested toJSON for passing objects around,
      e.g for web workers

      BB: to be able to set and get an array of floats
      ... you already have normalization for moveto, lineto,
      ... faster with float arrays than to use pathseglist

      CM: so, stringifier, jsonifier, and pointifier?

      BB: there are a number of ways you could do this
      ... there are libs that work on arrays of points directly
      ... you're really working on arrays of arrays

      CM: for subpaths you could flag it somehow

      TA: boolean at the end?

      BB: needs to be there when you set it back again

      CM: alternative is to have a function isSubpathClosed, and pass
      in the subpath

      BB: that's a bit less flexible
      ... want to just read out the point array, manipulate and set
      it back

      TA: so you have an array of points per subpath

      BB: and you have array of subpaths, which each haven array of

      TA: so defer until we get some feedback on this, on the list?

      CM: the json thing then...

      TA: not quite ready to resolve on that yet, but similar to the
      array one, should probably be discussed on the list

      -- 1h break for lunch --

      <birtles> scribenick: birtles

new arc command

      heycam: problem is the existing arc is unintuitive and you
      often want to animate the angles of arc rather than the
      ... it's really hard with declarative animation
      ... you have to do all the trig yourself
      ... which of the canvas arc commands let you specify the angle?

      TabAtkins: arc and ellipse are basically the same...
      ... arc(x, y, radius, startAngle, endAngle, acw)
      ... coordinates are absolute
      ... ellipse is the same but the radius has x and y and a
      rotation argument
      ... arcTo is a separate command that takes...

      heycam: is the implicit start point on the circle?

      cabanier: no, it automatically draws a line to the start of the

      TabAtkins: arcTo is a little more interesting...
      ... it does a straight line segment but it provides C1
      ... arcTo(x1, y2, x2, y2, radius)
      ... (draws a diagram explaining how arcTo works)

      shepazu: I'd like to add a rounding algorithm to SVG based on
      this mechanism

      TabAtkins: there is no rounded rect, you just use four arcTo
      ... there are the two arc commands in canvas

      krit: but are we running over the letters in the alphabet in
      the SVG path syntax?

      TabAtkins: but we could allow identifiers that are more than a
      single letter

      shepazu: we could just say "arc"

      heycam: is it useful to have both?

      everyone: yes

      TabAtkins: we could just have "arc" and "arcTo"?

      heycam: are you sure we don't want to use single letters?
      ... what about "e"?

      krit: that conflicts with scientific notation

      (which is now in CSS by the way)

      TabAtkins: I don't think we can continue with single letters

      heycam: what about leading punctuation?

      ChrisL: we've talked about having longhand before

      shepazu: it's also better for compression

      (talking about using expanded elements for path commands)

      heycam: so use "arc" and "arcTo" as the commands?

      TabAtkins: I'd be inclined to call them "circle", "ellipse" and
      ... so that we can use "arc" later as a longform for the
      existing arc command

      heycam: it might be more important to match the command name
      with the method
      ... rather than accommodating the existing arc command
      ... we could give it some other name in the future

      ChrisL: do we want to deprecate the existing arc command?

      TabAtkins: no, it's sometimes useful

      ChrisL: ok

      TabAtkins: ok, let's keep consistency with the canvas method
      names for now

      ChrisL: we should have a resolution about whether we want the
      longhand form or not

      TabAtkins: need to decide priorities (when you have both)

      heycam: it seems like a lot of duplication when sometimes it's
      probably easier just to separate out paths of the path string,
      rather than having 10 new elements

      ed: like having a fragment of the path as a separate element

      ChrisL: I think we'll probably have that too
      ... but we've often been asked for the verbose form
      ... the two big advantages are (a) better compression, (b)
      adding IDs / event handlers to specific parts

      (discussion about whether we could stroke sections differently)

      krit: what about adding length (units) to the path data

      ChrisL: when we originally considered that there was feedback
      that said that was really difficult

      heycam: what about percentages?

      krit: percentages are difficult, just lengths would be enough

      heycam: percentages would be useful

      TabAtkins: what measure do you resolve against for a diagonal

      heycam: depends which coordinate of the command
      ... if it's the y coord it is resolved against the height
      ... since unit identifiers are currently more than one letter
      there shouldn't be clashes with the path commands?

      shepazu: using units in paths has often been requested
      ... sometimes this is because people don't understand how to
      set units at the root
      ... but percentages are often valid

      krit: when are percentages are resolved?

      TabAtkins: if it's created in JS, what do you resolve the
      percentages against?

      heycam: it's similar to creating SVGLength objects
      ... what do they get resolved against?
      ... using createSVGLength
      ... we never really resolved how that should work

      RESOLUTION: We will add arc, ellipse, and two forms of arcTo to
      the SVG path syntax based on the canvas methods of the same

      TabAtkins: the only remaining command on canvas that's not
      available with the d attribute is "rect"

      ChrisL: what do we need to spec out with regards to that

      heycam: DOM API etc.

      TabAtkins: it would be nice to make the "d" attribute of the
      SVGPathElement return a sane version of SVGPathSegList
      ... (and not just an alias of pathSegList)

      krit: does this work for repeated commands?
      ... since the number of arguments to arcTo varies

      TabAtkins: arcTo comes in a 5 arg and a 7 arg version

      ChrisL: we could solve it by giving them different names
      ... or just say you have to repeat the command

      TabAtkins: what if we have ellipseTo

      ChrisL: and just document what ellipseTo equates to in canvas
      ... then you wouldn't have to have an exception where these
      commands can't be repeated

      heycam: we should look into adding ellipseTo to canvas (as an
      alias to the equivalent arcTo command)

      TabAtkins: I'll propose it

      <scribe> ACTION: Tab to propose to the HTML WG that the 7
      argument form of arcTo be replaced with an ellipseTo method
      [recorded in

      <trackbot> Created ACTION-3355 - Propose to the HTML WG that
      the 7 argument form of arcTo be replaced with an ellipseTo
      method [on Tab Atkins Jr. - due 2012-09-24].

      (this is because the elliptical version of arcTo is not
      implemented anywhere so we are still free to change the name)

      heycam: I'll try to write this up in the spec since my name is
      down next to this item in the requirements list

      ChrisL: what about lengths and percentages in paths?

      krit: I'm still not sure about how you resolve percentages

      TabAtkins: let's defer percentages to further discussion on the
      list and just stick to lengths for now

      heycam: em units still need a context

      TabAtkins: you can resolve against a default font size

      heycam: what about calc?

      TabAtkins: it's not problematic by itself
      ... only if one of its components is a length we can't resolve

      heycam: more discussion is needed on lengths
      ... particularly for what to do when you don't have a context
      for resolving against
      ... what about points on a polyline?

      krit: yes, since we have that for shapes in CSS

      <scribe> ACTION: Dirk to tell the CSS WG that we changed the
      SVG path syntax [recorded in

      <trackbot> Created ACTION-3356 - Tell the CSS WG that we
      changed the SVG path syntax [on Dirk Schulze - due 2012-09-24].

      <scribe> ACTION: Dirk to prepare a proposal for supporting
      lengths/percentages in paths and polylines [recorded in

      <trackbot> Created ACTION-3357 - Prepare a proposal for
      supporting lengths/percentages in paths and polylines [on Dirk
      Schulze - due 2012-09-24].

      ChrisL: what about element syntax for paths?

      TabAtkins: I think it's useful

      <scribe> ACTION: Chris to produce a proposal for expanded
      element syntax for paths (including finding the results of
      testing improved compression ratios with the expanded syntax)
      [recorded in

      <trackbot> Created ACTION-3358 - Produce a proposal for
      expanded element syntax for paths (including finding the
      results of testing improved compression ratios with the
      expanded syntax) [on Chris Lilley - due 2012-09-24].

      cyril: I think it's good to be able to break paths into
      fragments but not necessarily an element per point

      ChrisL: it wouldn't be per point but per command

      heycam: sometimes you don't want to go down to individual
      commands but just fragments
      ... it would be nice to use the same mechanism for that

      shepazu: it would be nice to refer to segments and include them
      reversed etc.

      ChrisL: if you have multiple paths and you want to combine
      those to make one path you sometimes need to reverse a segment

      shepazu: it would be nice to be able to get the geometry of the
      reversed version

      cyril: if we have elements for each command, you'd end up with
      a lot of DOM nodes
      ... is it worth having the parse collapse them?

      TabAtkins: no, you don't want the parser doing that kind of
      special magic

      everyone: no magic

      andreas: what about polar coordinates?

      heycam: we rejected the request for polar coordinates in
      ... in place of that we have proposed the turtle graphics which
      solves many of the cases but not all

      ChrisL: it reminds me of the syntax used in Raphael which
      provides a SVG path-like syntax for describing transforms

      krit: polar coordinates are definitely useful...
      ... but then the whole coordinate system should be in polar
      ... otherwise you have to map them

      andreas: sometimes you have a series of survey results that are
      best described using polar coordinates, like a cave
      ... everything is relative to the last position
      ... it's typically a series of straight line segments and

      heycam: that should be possible using the turtle graphics
      ... but polar coordinates in general are difficult and we
      rejected that requirement

      (description of turtle graphics proposal, the 'r' and 'R'

      (now talking about Catmull-Rom curves)

      shepazu: adding a segment affects the previous segment
      ... and you need two endpoints
      ... so if you start with a P command (the Catmull-Rom command)
      you can't draw the curve until you get a second point

      ChrisL: with regards to the issue of segments affecting the
      previous segment, if you duplicate the points of the last
      segment (i.e. a zero-length segment which degenerates to a
      straight line segment) it won't affect the previous segment

<image> as paint server for SVG (already resolved to have <gradient>)

      krit: we already allow <gradient>
      ... and we resolved how it applies to path elements
      ... and it's not limited to gradient box (as defined in CSS)

      TabAtkins: in CSS gradients are infinite
      ... but they get chopped to their box
      ... but SVG can define gradients so that extend to infinity
      ... but other image types can't be trivially extended in the
      same way

      ChrisL: in SVG 2 we could also have a painted bounding box (aka
      decorated bounding box)
      ... we could use that instead

      shepazu: i.e. use that instead of the gradient bounding box

      cyril: but with an image you can say that it only fills 50% of
      the box
      ... how do you fill the rest of the object?

      krit: not at all

      ChrisL: transparent black

      TabAtkins: CSS lets you specify repetition etc.
      ... if we wanted to do that in SVG we'd have to make fill etc.
      a shorthand
      ... or we could specify those properties when specifying a
      paint server (e.g. a pattern)

      ChrisL: there's another consequence of this painted bounding
      ... previously if you had a gradient on a horizontal line you'd
      end up with nothing unless you special case it
      ... but if you use the painted bounding box you can get around

      krit: what if you have a rectangle that you stroke
      ... you stroke it with an image
      ... if you use the geometric bounding box only half the stroke
      gets painted

      TabAtkins: what about backwards compatibility about using the
      painted bounding box

      shepazu: you'd use the geometric bounding box for existing SVG
      gradient elements, and the painted bounding box for CSS

      (discussion about providing a new keyword like
      objectBoundingBox when defining an SVG gradient so it can use
      the painted bounding box)

      TabAtkins: that's important since we also want to be able to
      use SVG gradients in CSS

      (discussion about the definition of the decorated bounding box)

      TabAtkins: when using a CSS gradient function in SVG, do we
      want stroke to use the painted bounding box and the fill to use
      the geometric?

      ChrisL: I'd like to have the flexibility to use both

      TabAtkins: I think fill should default to geometric and stroke
      to painted
      ... in summary, we want to expose the ability to switch between
      geometric and painted bounding boxes
      ... we will add an optional keyword to the fill/stroke
      properties to allow switching between the two
      ... with appropriate defaults for each (specifically fill =
      geometric, stroke = painted)

      heycam: what about markers?
      ... are they included in the calculation of the decorated
      bounding box (as they are in the DOM method)? it might be less
      useful when stroking to include markers
      ... it needs more thought

      TabAtkins: for stroke, the default is the painted bounding box
      ... but when referring to an SVG gradient element it will defer
      to an attribute on the gradient specifying which bounding box
      to use
      ... and *that* will default to the geometric bounding box for
      backwards compatibility
      ... just like we're doing with maskign


      scribe: for the more general issue of the CSS <image> type...
      ... if you draw a gradient using the geometric bounding box
      ... it will size itself using the inner bounding box but it
      still can extend beyond that box
      ... the gradients are defined such that they extend infinitely
      ... then CSS just clips that result
      ... but SVG might not do that
      ... what do we do outside the box for other CSS image types
      ... do we just paint them as transparent black?

      (other CSS image types being all those other than gradient

      scribe: if you want it to repeat, put it in a pattern and use
      ... CSS just defines that outside the box you're transparent
      black unless you use background properties to repeat the image

      heycam: the alternative is to introduce background-repeat etc.
      into SVG
      ... and I'd rather not do that

      TabAtkins: me too, use patterns for repeating

      RESOLUTION: We will add a control to fill and stroke to
      determine which bounding box (geometric or decorated) to use
      for sizing paint servers

      <cyril> for sizing and positioning too

      RESOLUTION: We will add attribute to the existing paint servers
      in SVG defaulting to the geometric bounding box (like the
      maskType attribute)
      ... When using CSS image types that are finite in extent are
      expanded to infinity by using transparent black (not by
      repeating the result)

      s/extent are/extent, they are/

      <scribe> ACTION: Tab to amend the definition of fill,stroke in
      SVG to allow the CSS <image> type [recorded in

      <trackbot> Created ACTION-3359 - Amend the definition of
      fill,stroke in SVG to allow the CSS <image> type [on Tab Atkins
      Jr. - due 2012-09-24].

      heycam: is there a clash since fill,stroke already take a URL
      but so does the <image> type
      ... are the mechanics for how you interpret it different?

      TabAtkins: it should be ok

      birtles: it's the same for masks
      ... you have one behavior when you refer to a whole document
      (a.svg) vs an element within a document (a.svg#mask)

      <TabAtkins__> ScribeNick: TabAtkins__

color interpolation filters for shorthands

      krit: Currently we have the color-interpolation property for
      all filters.
      ... How do we apply it to the shorthand functions?

      heycam: Would you normally want to apply it to specific filter

      chrisl: In general you want to do linear, but there are cases
      where you want to stay in the sRGB as you pass values between,
      to avoid loss.

      krit: For shorthands, we're okay with just using the default
      colorspace. If you want different shorthands, use the SVG
      <filter> element.





      krit: [lists the shorthand functions]
      ... So, first question, are we okay with saying that the filter
      shorthands just use the default colorspace?

      RESOLUTION: Filter shorthands only use the default colorspace
      (*not* the current value of 'color-interpolation-filters' on
      the element, either).

      krit: Note, obviously, that you can use an SVG <filter> (with
      color-interpolation set on the <filter> element or the
      subfilters) and then reference it with url().

Perlin noise

      krit: Do we want to add a new type of noise function that is
      easier to hardware-accelerate?

      ChrisL: In addition to existing turbulence, or replacement?

      TabAtkins__: Addition - too much content already relying on it.

      <ChrisL> ok good

      ChrisL: Is there a definition for the algorithm that's free?

      krit: We need to decide on the new algorithm, with discussion
      or further research.

      ed: I think we discussed Simplex noise before.

      <ChrisL> [40]http://www.eng.utah.edu/~cs6965/papers/noise.pdf

        [40] http://www.eng.utah.edu/~cs6965/papers/noise.pdf

      <ChrisL> [41]http://reality.sgiweb.org/olano/s2002c36/ch02.pdf
      Noise Hardware - Ken Perlin

        [41] http://reality.sgiweb.org/olano/s2002c36/ch02.pdf

      RESOLUTION: Add a new type of noise algorithm to the filters
      spec, for easier hardware acceleration. (Further research for
      what type, possibly Simplex noise.)

Need a new filter shorthand for noise?

      krit: Often the noise functions are not used standalone -
      they're used with other filter primitives.

      <ChrisL> [42]https://github.com/ashima/webgl-noise/wiki glsl
      implementation of Perlin and simplex noise

        [42] https://github.com/ashima/webgl-noise/wiki

      <ed> here's an example using a bit of turbulence:

        [43] http://dahlstr/

      TabAtkins__: The use-case I care about is usually solved by
      taking an initial background-image or background-color, and
      layering a "noise image" on top to give it some irregularity.
      You cannot do this with the 'filter' property unless you define
      a <filter> element and refer to it.

      ChrisL: I've come across an impl of both classic and simplex
      noise in glsl, and it says explicitly that both algorithms can
      be done fine even on low-end (e.g. phone) GPUs.
      ... So why is this a problem that we need to solve?

      krit: Based on list discussion, Simplex is a smaller O()
      complexity, which is of concern with the often-large images
      that will be used in CSS.

      <ChrisL> ok

      <ChrisL> demo


      <heycam> ScribeNick: heycam

      <ed> the demo chrisl pasted demos 3d-perlin noise I believe

      TabAtkins__: the filter function in filter effects is of type
      CSS <image>


      <TabAtkins__> s/filter function/filter() function/

      TabAtkins__: so you can introduce a noise filter shorthand and
      then use it in the filter function

      <TabAtkins__> s/TabAtkins__/krit/

      TabAtkins__: my argument is that the filter function as written
      still takes an <image> as an argument

      krit: that would change

      TabAtkins__: if you make that optional it's less troublesome
      ... I think it's weird that we have no-input filters

      <cabanier> filter function:


      … I think that was a hack in the original SVG

      … and instead just said "these are not paint servers but some
      filter primitives"

      … I am somewhat opposed to extending that confusion into the
      CSS version of the syntax

      … if we are producing an image, I would want to produce an
      <image> directly

      krit: then you can put this <image> as input to the filter

      ed: if you want the same number of parameters that the SVG
      turbulence has?

      TabAtkins__: I don't know what's needed
      ... you would have "filter: noise(…) ..."

      krit: wouldn't the parser get confused?

      TabAtkins__: no

      … the filter function takes the first argument is an image, the
      next is filter list

      s/filter: noise(…) .../background-image: filter(noise(…), …)/

      krit: you could use this as an input to custom filter
      primitives too

      TabAtkins__: so this seems fine to me

      krit: do we still want to have a shorthand noise function?

      … and is that in Images or Filter Effects?

      TabAtkins__: I don't think we do, because it's only a

      … and we can't do tree-based filter chains in the filter

      … if we do do that, we can allow <image>s as well as inputs to
      compositing filters for example

      … I think making feTurbulence a filter primtiive and not a
      paint server was a mistake

      krit: in the end it probably doesn't matter, but yes where do
      we put it logically

      TabAtkins__: we should only allow pass through filters in the
      filter property

      krit: I agree

      ed: would we have a corresponding element in SVG filters?

      … we have feTurbulence

      krit: deprecate but not drop it

      TabAtkins__: for filters do we want to correct this historical

      … you can't just take a paint server directly, you need to
      specify bounds to fill

      krit: we could use feImage taking CSS <image> as well

      ed: I think it would be handy to have in SVG filters too
      ... I don't mind if it's a new primitive or an 'image'
      referenced from <feImage>
      ... a new in="" value?

      TabAtkins__: you just need to combine a paint server with a

      krit: in general, we need to redefine in and in2

      … to have CSS <image>s as input in there is fine

      TabAtkins__: you can't use colors in there
      ... because "blue" might be a name of a result

      … the <image> function in CSS can produce solid colors

      … image(blue)

      krit: feImage still has subregion clipping

      … you could use media fragments for selecting the region, but
      there's no way to do preserveAspectRatio

      krit: a question about the noise function, how do you define
      the size of it?

      TabAtkins__: I would do the same as gradients

      … it's sized into the box it's drawn into

      … it has no intrinsic size

      … in SVG's case, it can still do an extension out to infinite

      ed: one complication is having tiling

      … if you tile the noise function without stitchTiles you can
      see the tile edges

      TabAtkins__: any primitive tiling mechanisms will cause
      discontinuities at the edges of tiling

      … unless you tell the noise algorithm to stitch the edges

      ChrisL: we shouldn't be padding noise out, just which region we
      really want to cover



      krit: primitives are always clipped to the filter region

      … if you have feOffset you can reach the edge of the noise

      TabAtkins__: we should just generate noise at whichever pixels
      are going to be touched

      <scribe> ACTION: Dirk to look into allowing CSS <image> values
      in in="" and in2="" [recorded in

      <trackbot> Created ACTION-3360 - Look into allowing CSS <image>
      values in in="" and in2="" [on Dirk Schulze - due 2012-09-24].

      <scribe> ACTION: Tab to work with Dirk to spec out a noise()
      <image> value [recorded in

      <trackbot> Created ACTION-3361 - Work with Dirk to spec out a
      noise() <image> value [on Tab Atkins Jr. - due 2012-09-24].

      TabAtkins__: some things need the size you're drawing into

      … CSS gradients need to know how big their box is before

      … media fragments don't apply to most CSS <image>s, just url()

      ed: for SVG I would like to have 3D noise and to be able to
      connect the time domain to the third dimension

      … so you can have continuous effects

      … with feTurbulence it can move things in x and y, but you
      can't really have a fire/plasma effect

      krit: I'd suggest using shaders for that

      ed: you couldn't implement it that way

      …but it would be nice to have filter primitives for that

      krit: do we really want 3d noise? maybe, don't know.

      … is simpled 2d or 3d?

      ed: you can extend it to how many ever dimensions

      … I think that would be really nice to have

      … I want to allow that when we go with <image> generation, so
      we can animate the timing

      TabAtkins__: the CSS <image> type is now animatable, in Images

      … there's a generic animation type that does a cross-fade

      … but cross-fade and gradients animate argument-wise

      … so that's fine to have animation of noise()

      ed: Chris' link earlier shows the 3d noise animation

      shepazu: when we're talking about stitching, does this also
      apply to Tiling & Layering?

      TabAtkins__: just if you're using a noise function of a certain
      noise, or inside a pattern element that ends up being repeated,
      you need to tell the algorithm to make sure the edges tile well

Masking issues

      krit: we said we wanted to have attribute maskType for <mask>

      … that says you specifically want to use this mask with alpha
      or luminance

      … do we want to make this a presentation attribute

      ed: why would you want to?

      krit: we already define mask-type for CSS masking

      heycam: so this would just use the same attribute/property on
      both the <mask> and the thing being masked



      krit: yes
      ... second question is if you use maskType="" as we currently
      defined it, it's camel case

      … which HTML editors don't want, because they need to special
      case it for the parser

      … I have no problems if they need to special case it

      ChrisL: the reason we had camel case was we originally had
      hyphenation, and the DOM people requested camel casing

      shepazu: if I'm converting from a property name to a DOM name,
      removing the hyphen is trivial, adding the camel-cased letter
      is kind of trivial with regex, but...

      krit: still trivial

      … the only problem is HTML is not case sensitive

      shepazu: could we go to all lower case?

      TabAtkins__: you would need to define what happens if you
      accept both camel case and lower case
      ... I'm fine with all lower case or keeping camel case in

      … updating the list isn't a big deal

      … given every implementation just has a list of attribtues with
      cases, it's easy to update

      heycam: I'm slightly concerned that the case in the DOM changes
      after the parser is updated

      TabAtkins__: that's only a problem if people try to use the
      feature before implementations add the feature

      … you could define that with conflicting case names, just use
      the last one … that's what the HTML parser does

      TabAtkins__: maybe we should keep camel case, because when you
      are using the property with CSS, you use camel case in the DOM

      heycam: have the presentation attribute be camel case for a
      hyphenated property name?

      TabAtkins__: dashes are hard for the DOM, but we could accept
      hyphens too

      krit: it's easy in WebKit to have the dashed version of the
      presentation attribute

      …we just pass that to the CSS engine

      heycam: if it's going to become a presentation attribute, it
      should be mask-type not maskType

      krit: so do we want it to become a presentation attribute /

      TabAtkins__: I think we do

      birtles: just wondering when you'd want to set mask-type on
      <mask> with a style sheet

      TabAtkins__: you could set all <mask> elements to alpha with a
      style rule

      birtles: ok

      heycam: is it confusing that mask-type means slightly different
      thinks applied to <mask> and masked elements?

      TabAtkins__: we could merge in the "alpha" or "luminance" back
      into mask-image

      … instead of the separate mask-type

      … and just use mask-type to apply to <mask>

      birtles: I'd rather this

      TabAtkins__: and I think it's fine to think of the alpha-ness
      of luminance-ness as part of the image

      [discussion about changes to serizliation and computed values
      for -webkit-mask]

      RESOLUTION: mask-type now only applies to <mask>, and the [
      alpha | luminance | auto ] goes in the mask-image value

      krit: next problem is related

      … mask-image has syntax like background-image

      … so it clips to a region

      … we have a predefined clipping regions border-box, content-box
      and padding-box

      … I would suggest defining for SVG that border-box means
      painted rectangle

      heycam: what's the default?

      TabAtkins__: border-box

      ed: if you ahve an SVG inline in HTML, you might want the
      actual border-box of the outer <svg>

      TabAtkins__: yes it should mean that on the outer <svg>


      TabAtkins__: padding-box should map to normal bounding box

      krit: that's what it is currently

      RESOLUTION: {border-box, content-box, padding-box} should map
      to {painted bbox, normal bbox, normal bbox} for mask-clip

      ed: would you ever want to have a box that includes the
      filters? markers?

      krit: we need to discuss this

      … I'd rather no, because we would do this masking on the gpu

      heycam: markers are already included in border-box

      TabAtkins__: if you have a drop shadow applied to an element,
      then using mask-clip will clip that away

      krit: the old mask property still works the same way

      … the url() references <mask> and can still have
      x/y/width/height on it


        [50] http://www.w3.org/Graphics/SVG/WG/wiki/Path_toJSON

Summary of Action Items

      [NEW] ACTION: Cameron to email the HTML and WhatWG working
      groups to ask if there any problems related to adding the HTML
      link element into SVG [recorded in
      [NEW] ACTION: Chris to produce a proposal for expanded element
      syntax for paths (including finding the results of testing
      improved compression ratios with the expanded syntax) [recorded
      in [52]http://www.w3.org/2012/09/17-svg-minutes.html#action08]
      [NEW] ACTION: Dirk to file a bug and track filter functions
      (issue 5) removed from Filter Effects spec [recorded in
      [NEW] ACTION: Dirk to look into allowing CSS <image> values in
      in="" and in2="" [recorded in
      [NEW] ACTION: Dirk to prepare a proposal for supporting
      lengths/percentages in paths and polylines [recorded in
      [NEW] ACTION: Dirk to tell the CSS WG that we changed the SVG
      path syntax [recorded in
      [NEW] ACTION: Rik to ask CSS WG about how shadowing will work
      for enable-background [recorded in
      [NEW] ACTION: Tab to amend the definition of fill,stroke in SVG
      to allow the CSS <image> type [recorded in
      [NEW] ACTION: Tab to propose to the HTML WG that the 7 argument
      form of arcTo be replaced with an ellipseTo method [recorded in
      [NEW] ACTION: Tab to work with Dirk to spec out a noise()
      <image> value [recorded in
      [NEW] ACTION: Tav to add lang to tile and desc [recorded in

      [End of minutes]

       Minutes formatted by David Booth's [62]scribe.perl version
       1.136 ([63]CVS log)
       $Date: 2012/09/17 15:26:55 $

        [62] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
        [63] 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 [64]http://dev.w3.org/cvsweb/~checkout~/2002/

        [64] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/can/can't/
Succeeded: s/foreignObejct/foreignObject/
Succeeded: s/henry/henri/
Succeeded: s/filter chain does the optimisation/implementation can analy
ze the filter chain and do the same optimisation/
Succeeded: s/differnet/differently/
Succeeded: s/I think if they're useful remove them but they could be use
ful since we have the possibility of non-square pixels/I think if they'r
e use-less remove them but they could be useful since we have the possib
ility of non-square pixels/
Succeeded: s/commandas/commands/
Succeeded: s/appends path to the path/appends path object to the path/
Succeeded: s/svgpath elements/svgpathseglist/
Succeeded: s/arc2/arcTo/
FAILED: s/maskign/masking/
FAILED: s/extent are/extent, they are/
FAILED: s/TabAtkins__/krit/
FAILED: s/filter function/filter() function/
FAILED: s/TabAtkins__/krit/
FAILED: s/filter: noise(…) .../background-image: filter(noise(…), …)/
Succeeded: s/have a/have/
FAILED: s/ahve/have/
Found ScribeNick: nikos
Found ScribeNick: ed
Found ScribeNick: birtles
Found ScribeNick: TabAtkins__
Found ScribeNick: heycam
Inferring Scribes: nikos, ed, birtles, TabAtkins__, heycam
Scribes: nikos, ed, birtles, TabAtkins__, heycam
ScribeNicks: nikos, ed, birtles, TabAtkins__, heycam

WARNING: No "Present: ... " found!
Possibly Present: Andreas BB CM ChrisL Cyril DS RC TA Tab TabAtkins TabA
tkins__ Tav all birtles cabanier doug ed everyone glenn heycam https joi
ned konno konno_ krit nikos scribenick shepazu stakagi svg trackbot vict
You can indicate people for the Present list like this:
           <dbooth> Present: dbooth jonathan mary
           <dbooth> Present+ amy

Agenda: [65]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/Agen
Found Date: 17 Sep 2012
Guessing minutes URL: [66]http://www.w3.org/2012/09/17-svg-minutes.html
People with action items: cameron chris dirk rik tab tav

        [65] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/Agenda
        [66] http://www.w3.org/2012/09/17-svg-minutes.html

      End of [67]scribe.perl diagnostic output]

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

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Received on Monday, 17 September 2012 15:31:59 UTC