SVG Working Group Teleconference -- 17 Sep 2012

<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

<heycam> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Csvg%3E%3Clink%3E%3Cscript%3Ew(document.getElementsByTagName(%27link%27)%5B0%5D.namespaceURI)%3C%2Fscript%3E

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

<ed> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Csvg%3E%3Clink%20rel%3Dstylesheet%20href%3D%22data%3Atext%2Fcss%2Ccircle%20%7Bfill%3Agreen%7D%22%20type%3D%22text%2Fcss%22%20%2F%3E%3Ccircle%20cx%3D50%20cy%3D50%20r%3D20%20fill%3Dred%20%2F%3E

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 http://www.w3.org/2012/09/17-svg-minutes.html#action01]

<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 2012-09-24].

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 values?
... like there's a single variable underneath but there's 2 properties

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 properties
... 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 http://www.w3.org/2012/09/17-svg-minutes.html#action02]

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

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> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feUnsharpMaskElement

<krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feDiffuseSpecularElement

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 shorthands

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

<krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterFunction

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 version
... the question is do we freeze what we have now?

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

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 http://www.w3.org/2012/09/17-svg-minutes.html#action03]

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

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 screen

heycam: I remember people objecting to that in some other context

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

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 units

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 shouldn't
... switch should be transparent

heycam: I think you should be able to do multiple title elements
... 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 attributes

<ed> just playing a bit with the systemLanguage: 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 then
... but that's actually useful
... the problem is, what happens if you do

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

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 also)
... 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 element?
... 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 internationalisation

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 title

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 done.
... 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 http://www.w3.org/2012/09/17-svg-minutes.html#action04]

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

<andreas> http://www.quirksmode.org/blog/archives/2012/06/devicepixelrati.html

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 ratio

<ed> scribeNick: ed

passing path object to svg path

<krit> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#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 svgdom
... 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 normalization

CM: i don't like it

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

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 beziers

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 inherit
... 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 anyway
... 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 command

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 normalized
... but if we put it on the svgpathseglist then i'd expect non-normalized

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 better

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 directly

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 moveto?
... 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, closepath
... 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 points

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

TabAtkins: arcTo is a little more interesting...
... it does a straight line segment but it provides C1 continuity
... 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 commands
... 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 "arcTo"
... 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 line

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 names

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 resolution

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 terms
... 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 http://www.w3.org/2012/09/17-svg-minutes.html#action05]

<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 http://www.w3.org/2012/09/17-svg-minutes.html#action06]

<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 http://www.w3.org/2012/09/17-svg-minutes.html#action07]

<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 http://www.w3.org/2012/09/17-svg-minutes.html#action08]

<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 transforms
... 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 coordinates
... 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 rotations

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

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

(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 box
... 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 that

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 gradients

(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

s/maskign/masking/

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

scribe: if you want it to repeat, put it in a pattern and use that
... 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 http://www.w3.org/2012/09/17-svg-minutes.html#action09]

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

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.

<nikos> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#ShorthandEquivalents

<krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterFunction

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> http://www.eng.utah.edu/~cs6965/papers/noise.pdf

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

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> https://github.com/ashima/webgl-noise/wiki glsl implementation of Perlin and simplex noise

<ed> here's an example using a bit of turbulence: http://dahlström.net/svg/presentations/svgopen2012/presentation/introimage-static-grain-toothpaste.svg

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 http://alteredqualia.com/three/examples/webgl_shader_copper.html

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

s/TabAtkins__/krit/

<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: https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterCSSImageValue

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

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 generation

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

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

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

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 case

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

<ed> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feTurbulenceStitchTilesAttribute

krit: primitives are always clipped to the filter region

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

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 http://www.w3.org/2012/09/17-svg-minutes.html#action10]

<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 http://www.w3.org/2012/09/17-svg-minutes.html#action11]

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

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

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 4

… 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> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-type

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 attributes

… 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 / property?

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>

s/ahve/have/

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

<shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Path_toJSON

- DRAFT -

SVG Working Group Teleconference

17 Sep 2012

Attendees

Contents

Pass Path object to SVG path

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

enable-background naming in relation to compositing and blending

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

Filter Functions

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

How to internationalize "title"?

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

passing path object to svg path

new arc command

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

color interpolation filters for shorthands

Perlin noise

Need a new filter shorthand for noise?

Masking issues

Summary of Action Items

Scribe.perl diagnostic output