<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

superpath

<cyril> http://moissinac.github.io/SuperPath/

cyril: my colleague has been working on this superpath prototype
... the idea is that in many graphics, you need to share paths or pieces of paths among bigger paths
... for example you need to share them if you have regions in a map, share them sometimes in direct order, sometimes in reverse order
... so the idea is to reuse a piece of a path in another path
... benefits in reducing file size, but also more semantically correct content. not duplicating information when not needed.
... viewers could do better antialiasing on that path, it's only present once
... it could be rendered seamless
... last time we talked about it, I exposed the fact that we wanted to have a path with an ID attribute, then another path referencing that initial path
... after some investigation we realised that it's very hard to extract a piece of a path and make it a separate path alone
... because what command would you put at the front
... the geometry of the path often depends on the point before or the point after
... so we changed our idea here ab it
... nikos suggested instead of having the reusable path a separate path, define it while using it in the first place
... so you have the full context
... you have the previous point if you want to reuse it in reverse order, or the next point if you are reusing in direct order

Tav: that's clear, but not sure if it's necessary

cyril: you can see some examples on this page
... don't pay much attention to the syntax yet
... my colleague is happy to change the syntax, it's just a prototype

<cyril> d="M 90,190 220,90 330,150 (p1|L330,150 280,230 L330,310 280,400)L120,375 z"

cyril: this is an example of syntax; the path you will be reusing is between parens
... the ID is the thing after the open paren, and it ends with the bar
... when you want to reuse it

<cyril> d="M 500,385 390,460 280,400!p1|L450,50 565,81 z"

cyril: that's a reverse use
... and I think the prototype uses # for forward use

<cyril> http://moissinac.github.io/SuperPath/Samples/piece01withExternalScript.svg

cyril: there's a more complex example with a map

<cyril> http://moissinac.github.io/SuperPath/Samples/bretagneSuperPath.svg

cyril: this is a region of france with three subregions
... the blue path for the sea
... as I said, the syntax is probably not the best
... but the big change is the path is defined inline
... when it's first used
... to have the full context
... what is preserved is the geometry
... what he does is any path used is converted to a path that has relative commands, so it's easier to reverse
... then the reversed relative commands are applied
... the next step for us is to fix the syntax, then have it run on many examples
... JC is writing a program to analyse existing content and replace duplicated paths with this
... when the content has been authored and the paths don't exactly match, e.g. with slightly different floating point values

Tav: in inkscape you can output in relative or absolute
... I want to talk about auto closing a path
... with a rounded segment
... so you'd leave out the first point, then put the first point in the path

nikos: it wasn't to do with smooth curve final segments was it?

Tav: it helps with positioning the marker

heycam: so that's a mid marker

Tav: and makes the orientation expected

cyril: what does the group think of defining the reusable path name in the path data?

krit: how do we handle compatibility?

cyril: for the path that defines the reusable path, it you could skip the ID then it could render
... the path that reuses it you couldn't really do anything

Tav: now you define a country, as one path, and a region in that would be the path that you share?

cyril: the country would be a single path element, but the d attribute would be divided into many subpaths, each having an ID for example
... then you define a region with an external border with the country, when you define the path data for that region you reuse the subpath defines in the country border

Tav: I find that conceptually more complicated than defining each subpath separately

nikos: you could define all the subpaths in defs
... and then you only need to reference it because you want to fill it

cyril: if you don't care that the path segment between the previous point and the first point of the reused path, then doing what you suggest is good

ed: can you get a continuous curve with reused subpaths?

cyril: yes

ed: it's a similar problem to the autoclosing command
... also wondering with this proposed syntax, is it possible to have nested reusable subpaths?

cyril: I haven't tested that, I guess the prototype doesn't accept that
... but in theory it could work
... one of the difficult things in the current impl is that the path is converted to relative, and if the path you are defining is at the end of a big path, and the big path uses another path, you need to resolve that one first
... there's a possibiltiy you need to process the whole file before doing anything
... there's also the possibility of doing loops

Tav: don't we have some rules for dealing with that already

ed: yes for ID cycles

cyril: so that would need to be specified

heycam: bit uneasy about defining the names in the path data
... seems odd

birtles: if I add the get-path-data-as-floats API, how would this work?

cyril: it would return the expanded path
... animation is also an open issue
... I don't know how it can be implemented in browsers
... polyfilling is easy

heycam: we wouldn't do the seamless rendering first, that would need lots of graphics library rewriting

cyril: I don't think I need a resolution or an action, but if anyone is willing to help/test
... e.g. prototype in inkscape

Tav: I'd like to but have enough other prototypes to work on for now

<scribe> ACTION: jean-claude to further develop the protoype including with animation support [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action01]

<trackbot> Created ACTION-3734 - Further develop the protoype including with animation support [on Jean-Claude Moissinac - due 2015-02-19].

optimizing for machine generation

jet: I wanted to talk to the group about some implementation experience that I've had
... recently and in the past
... at Mozilla we recently implemented a flash player in JS
... and just deployed it in nightly Firefox builds
... previously I worked at Adobe on the flash player
... before that at Macromedia on the flash authoring tool
... at Macromedia, Adobe was building their LiveMotion authoring tool
... I wanted to share with the group some of why flash got the ubiquity it did and Adobe's SVG didn't
... it wasn't so much that the technology was better, but that we did things at Macromedia so that it would defeat SVG at the time
... I think there's an opportunity to get past that after all this years
... and move interactive animations on the web in a way that SVG could not at the time
... the things that made it get over that hump at the time, weren't the things you'd expect
... Adobe's authoring tool was good, had a reputation for quality software, plugin worked in many places
... but when we would evanglize Flash over SVG, we'd demo with the worst browsers with SVG, and the best browser with Flash
... one company in particular the Flash developers went to at the time was Disney
... experts in animation, decided to use Flash on the front page of their site
... at the time, if you wanted to use animation you'd use GIF89, and there wasn't really anything else
... this is the era of 9600 baud modems and 386 computers
... today, the hardware is better, but similar network issues
... the things that made Flash successful was bug compatibility across browsers, and performance characteristics that were consistent across browsers
... for example Flash had retained mode API, binary file format
... small, fast, compiled
... after a while, the workflow would be that you'd take the authoring file format, .fla (which is a zip with xml resources, not quite svg)
... what I'm getting at is that SVG is an excellent authoring format, but a poor runtime format
... not because of XML vs binary is better or worse, but that we're unable to offer the consistent runtime/rendering experience because of what the format offers
... an example: coons patches, flash doesn't support that; nor gradient meshes
... but you can build a gradient mesh in the authoring tool and it spits out a bitmap under the covers
... there are things like that which make SVG very expressive, but which on a phone rendering a coons patch for your logo is less practical
... so what I'd like to get from the SVG group to see if there's an appetite to fix that
... is there a way for the implementors here to think about using SVG in a way that we can start with a subset that is normative for a runtime implementation
... not enough that we'd say you have to implement a coons patch for SVG, but that you could render a subset of SVG and have bug compatibility if possible

krit: it sounds a bit like the Basic SVG Profile

jet: SVG is one facet of it
... vector art and animation, and interactivity
... the part that made Flash also be ubiquitous is that its OM was very contained and strict
... you wouldn't expect that the HTML hosting your Flash file could mess with the Flash OM
... so maybe a basic profile of SVG?
... today, we implemented flash in /canvas
... something similar to the React Canvas
... implementing flash in JS/canvas
... SVG is so rich and powerful that I think it's better suited as an authoring format than a runtime one
... if we could design a subset that is a subset that has clear DOM semantics
... that the runtime can then make decisions about rasterising etc.
... that's the spiel, don't have concrete ideas

heycam: are you coming from the perspective of trying to implement Flash in SVG, and the performance wasn't there?

jet: not all performance, but also different rendering model
... we also have an ad use case
... flash can bundle things up in a package neatly

ChrisL: sounds like you're asking for a package format
... which travels in one unit
... or can play without being unpacked

jet: yes, that's one way. maybe it is a zip container.
... there are things that made flash as a tagged binary file format, in the order of use
... you know before you use an element that you would've pushed it through the network
... the packaged file fromat like jar files, you have to get the whole blob before you can start

cyril: the work I presented yesterday uses mp4 container rather than zip
... which can be used for streaming
... to come back to the earlier statement, I agree that design of Flash was very different
... authoring format, and publication format
... SVG is completely different in that the authoring format is the publication format
... so the tradeoffs are different
... performance and compact model is not the same
... that's a benefit but also a problem for optimisation
... looking at converting cartoons to SVG, there are thousands of ways of doing it
... so it's hard to optimise
... there are so many ways to do the same thing

jet: for an authoring format, that's great
... flash was an authoring tool before it was a runtime format
... the compile-to-runtime was an artifact of having to send things over slow networks
... the answer I get to asking people why they're still writing flash, games/ads/etc., is both (a) these issues and (b) tooling
... so this is a problem we could solve, if we agree that we can start with a subset today that is available across all implementations

Rossen: I heard you mention a few times offering a subset
... and also guaranteeing interop
... I think we can all agree on how to spec a subset
... I don't know about guaranteeing interop
... it's what we all try to do
... but how do you guarantee it?

jet: I think that opens us up to the same disadvantages

Rossen: here's one way to go
... if this is something that we expose a number of APIs to the web platform, that you can implement SVG as one library, and that library is circulated and used
... that's the only way I can see that it's interoperable always
... going back for a second, you're mentioning a subset
... do you have an idea?

jet: I say subset just so it would be surmountable problem
... if we say basic shapes are required and then pixel perfect requirements
... because that's a simple problem

ChrisL: last meeting we tried to decide "is a geometry coordinate at the top/left of a pixel, or middle of a pixel"
... and we couldn't agree, because different graphics libraries are different
... one reason Flash was successul was that there was one implementation (that mattered)
... and that the implementation is basically the spec

jet: so we implemented Flash using JS/canvas
... that it was possible is somethign taht got me thinking
... if we can render it today, why couldn't we all do the same thing? why can we not do it for a format other than swf?
... firefox is going to pre-ship with the JS flash implementation, but it's not feasible to make all cartoon authors have to ship this library
... couldn't we polyfill a format other than flash, perhaps a subset of svg?
... I'd like to build on things already in the web platform

cyril: there is history to that. SVG Tiny 1.2 was that; an attempt to make a subset of SVG that was more efficient for mobile devices

krit: we could do that right now with specifications that exist. you could use web components to make your own vector format, if you have the right primitives

cyril: I doubt you'd have good performance there though

Rossen: I'm still thinking you're talking about two different things here
... one is packaging, plus maybe additional step of standardising extension API where a platform piece can be delivered or hosted on CDNs and have lifetimes/updates and implementations will download them periodically
... so that they become part of the native packaged platform

ChrisL: [tooling]
... the other reason I have Flash installed on my machine is that I like to watch video

krit: content protection

jet: we're solving the video problems another way, I think we'll get there
... the use cases are the ones I'd like to cover are ads, 2D games
... the people who makes those games/ads in Flash, is that SVG implementations are fragile
... can we make it so that it's less fragile across implementaitons, by saying that there's a subset that has to be normative across the board

Rossen: I think everything that we publish is normative
... in order to get interop you either have to converge on a single implementation, or just pray

cyril: if you subset SVG, in some sense you don't have 10 ways to do the same thing
... you can optimise that

Rossen: example?

krit: asm.js

cyril: how do you frame based animation in SVG?

Rossen: what is it today?

cyril: you can use display, visibility, opacity
... Brian just exposed yesterday all the challenges if you want to optimise your animation
... there are several ways, will-change, transfromZ

Rossen: let's go back to SVG
... from the SVG spec, tell me what is exposed is ambiguous and can be implemented in many ways
... if we're saying we're going to converge on one single technology that covers the entire web platform, I don't think this is the right forum
... I'd still like to figure out the problem for SVG

ChrisL: I'd like to see detail on what they find is fragile

roc: do people demand exact rasterisation consistency on all targets? or are they more concerned about performance consistency?
... or other things?

jet: it was consistency across targets

roc: rasterisation consistency?

jet: that, performance, ...
... we built a Flash renderer in JS, could this be a SVG renderer

Rossen: what does versioning look like in this case?
... I think we are falling down to some basic software engineering problems where the answer is either scaling down to one implementation, or you pray
... there's always a first to market, and others following
... are you going to hold everything back so that nobody jumps the gun and releases a feature?
... I think we build new features so that you have graceful progression
... and that comes back to the single implementation

roc: are you implicitly saying that you find that canvas has sufficient rastiersation consistency to satisfy these people, and that builindg something on canvas would help these people?

cyril: I can't speak for Google, talking to the people who work on swiffy, they said exactly that. they started with SVG, and moved to canvas

roc: they're finding canvas more consistent then
... you could have authoring tools produce canvas and JS
... and compile down to that level
... if you do that I think everyone gets what they want

jet: there's something amiss there, then you have to implement the playback engine

roc: you can customise that engine right down to exactly what the ad needs
... you won't need most of the features that Shumway has
... I don't know how small we can make that, but I think for a lot of ads we can make it pretty small

jet: is that something we could standardise?

roc: we wouldn't need to, which is why it'd be a great solution
... in standards, we could look at making canvas rendering consistent
... as canvas is more focused than svg is

cyril: what's the scalability of canvas?

ChrisL: well it's immediate mode

roc: that's a problem that canvas-using apps already have
... there's a couple of pieces to solving that
... we have consensus on solving that; there's an event that first when canvas needs to be re-rendered
... and an application listens for that event and rerender
... and we need a way for the app to size the backing store to device pixels
... which is a renderedWidth/Height property on the canvas

jet: then maybe all we have missing is the packaging side

roc: you might be able to design your ad such that --- well you have image assets etc.
... there have been several proposals for zip-like but streamable bundles
... (you can make zip streamable if you format it correctly iirc)
... I'm not sure why they didn't go anyway
... maybe the use cases weren't compelling enough?
... some people were trying to do it as a performance thing in a single HTTP transaction
... but then SPDY came along
... so for speeding up website loading that solved it
... but for this problem of content traversing multiple networks was not really thought of as a use case
... technically it's not a mysterious problem

cyril: you should look at the SVG streaming spec; it's still a draft, but it might help you

heycam: marcos will know about packaging

roc: if we could re-use this new app packaging format that might be a solution

cyril: my recollection is that it wasn't streamable

<Tav> http://tavmjong.free.fr/SVG/MITER_LIMIT/index.html

Miter line join

<cyril> https://github.com/w3ctag/packaging-on-the-web

jet ^ (packaging)

Tav: people were asking for a different type of miter
... instead of clipping at a certain point, when you reach the limit, you get a uniform clipping

ChrisL: the existing one is discontinuous

krit: in canvas, what do we do there?
... do we do the second one?

Tav: the guy from nvidia (not neil) said that half graphics engines do it one way, half do the other
... the lower one is existing behaviour in some engines?

roc: we just use the underlying graphics libraries
... so I'm sure it would be different on different platforms

<krit> https://developer.mozilla.org/samples/canvas-tutorial/4_8_canvas_miterlimit.html

krit: I think different platforms do align

Tav the proposal is to have a fourth (well, we have 'arcs')

Tav so if you're already doing something to implement arcs (i.e. not solely relying on existing libraries), then implementing this proposal is trivial

ChrisL: a new value would be good

Tav: I've played with the cairo line join code
... and doing this is trivial

krit: does it work cross platform? cairo uses CoreGraphics on OS X.

roc: so the image rasteriser, not the other backends

<roc> cyril: in what way is http://w3ctag.github.io/packaging-on-the-web/#streamable-package-format not streamable?

<roc> shepazu: can you hear us?

ed: the proposal is?

krit: a new value that has this behaviour

Rossen: are you proposing an interpolation function that goes between these things?

<cyril> roc: it depends on the definition of streamable. My definition includes timing/synchronization. This packaging format is progressively processable, not streamable. Not seekable for instance.

Tav: no just clip the miter rather than fall back to the other point

<roc> ah

<roc> cyril: OK. When Jet was talking about the Flash format being streamable, for the purposes of ad delivery, I think he meant "progressively processable"

<cyril> roc: there are use cases for adaptive streaming of ads as well

ChrisL: so you're using a line cap which never triggers miter-limit
... the numerical value for miter-limit wouldn't affect it?

Tav: it would

ChrisL: you're looking for a line-join keyword?

<cyril> roc: mp4 being ubiquitous in all browser, I think it's a candidate that shouldn't be dropped without investigation

<roc> cyril: maybe, but I think you can't have adaptive streaming and a single inviolable package.

ChrisL: miter-clip

<cyril> cyril: still controlled/timed delivery of big packages is interesting too

<cyril> roc: still controlled/timed delivery of big packages is interesting too

RESOLUTION: We will add line-join:miter-clip in SVG 2.

<scribe> ACTION: Tav to add line-join:miter-clip to SVG 2. [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action02]

<trackbot> Created ACTION-3735 - Add line-join:miter-clip to svg 2. [on Tavmjong Bah - due 2015-02-19].

-- 15 min break --

auto closing path closing

<Tav> http://tavmjong.free.fr/SVG/AUTO_PATH_CLOSING/index.html

Tav: there are problems when you have a curved segment at the begin/end of a path
... in that in order to close the path you have to have a 0-length z
... that causes problems with how markers are rendered
... there are inconsistencies with how browsers handle them
... if you paste that link in 2 different browsers, compare the rendering, you'll see that they're inconsistent
... due to rounding errors, if you use relative path segments by the time you get to the end your last point may not match up with the first point
... would be nice to have a way that specifies they should match up
... some possible solutions on how to do that
... one possibility is new commands
... the Z command is essentially an L command, where the point is the first point
... so you could extend that, but I don't think it's good to extend Z_a or whatever
... you could use a non-numerical parameter
... which means "use the first point"
... you could use a Z to indicate that you should replace a missing point with the first point in the path
... so either the second or third solution would be a way of doing it

heycam: would you accept this special symbol anywhere in the path?

Tav: maybe but it wouldn't be as useful

heycam: makes me wonder if you would want to go back to any point, not just the first point

Tav: it reminds me of a different problem, if 2 points are on top of each other, say a handle is on top of the start, how is direction determined for markers?

heycam: I think we covered the marker direction issue a couple of weeks ago

cyril: the whole problem comes from rounding errors, right?

Tav: yes

nikos: even ignoring precision issues, having a Z command that closes a bezier is useful anyway
... you could expand the meaning of Z to mean "close a path and create a segment if it needs to"

heycam: that's the third option

nikos: what if in an arc command you omitted the flag values and put a z there

heycam: I think just make that invalid

RESOLUTION: We will allow a Z to fill in any final coordinate pairs missing from the previous command.

<scribe> ACTION: Tav to add the new Z behaviour. [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action03]

<trackbot> Created ACTION-3736 - Add the new z behaviour. [on Tavmjong Bah - due 2015-02-20].

<Tav> http://tavmjong.free.fr/SVG/TEXT_ON_A_SHAPE/index.html

Text on a shape

Tav: inkscape originally drew ellipses/circles with paths
... some people noticed they could no longer put text along a circle
... because it's a common thing to do, it was proposed that we allow text on shapes
... in inkscape this is easy to do, because at the time we disply we've already converted the shape to a path
... the major issues have already been solved, such as the start point on a circle, because we had to define that using markers

heycam: and dashing

Tav: there are a couple of challenges
... if you put text on a circle it might make sense to use a negative startOffset
... how do you put text on the other side
... we could have a flag to say which way the text goes

heycam: sounds fine
... what about the flag?

ChrisL: what would the names be? inside/outside? left/right?

Tav: left/right

ChrisL: as long as you have a good definition

roc: clockwise/anticlockwise?
... mapping people use "true left" of a river, left when moving downstream

Tav: how about negative startOffset?

heycam: negative startOffset is already allowed, but we probably don't define what happens with closed subpaths

RESOLUTION: We will allow <textPath> to reference shapes and a flag to say which side of the path the text is put.

<scribe> ACTION: Tav to update textPath for text on a shape. [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action04]

<trackbot> Created ACTION-3737 - Update textpath for text on a shape. [on Tavmjong Bah - due 2015-02-20].

x/y/width/height on <symbol>

Tav: this is an issue I came across

<Tav> http://tavmjong.free.fr/SVG/viewport.svg

Tav: Opera Presto and Inkscape you see no red boxes

ChrisL: and red is bad right?

Tav: it means x/y/width/height are being interpreted when the spec says they shouldn't be

cyril: Firefox/Chrome behave the same

<ChrisL> IE11 is correct

Tav: Batik does it wrong, and probably everyone assumed Batik does it right
... so I don't think following those attributes is useful
... I think the spec should be followed in this case

roc: I suspect those attributes got cloned onto the <svg> and they're being interpreted in place
... so maybe we should add them for consistency with referencing <svg>?

ChrisL: is it fully defined what it means, if we removed that rule from the spec?
... given that nested <svg>s already allow this

Rossen: I don't want to change

ChrisL: the reason I changed was that we added x/y to <svg>, and now referencing it is different from referencing <symbol>

roc: if the issue is what I think it is, I think it would be easy to fix. but consistency between <svg> and <symbol> would be good.

krit: does <symbol> have viewBox?

Tav: yes

krit: then I'm starting to agree with roc

<shepazu> +1 to roc's proposal... we should do the same for <marker>, etc.

ed: if you have width/height on the <use> it will override the ones on the cloned tree

Rossen: and that makes sense

roc: this is not an argument for making symbol behave differently though

Tav: it's only used by a <use> element

ed: I think you'll still get the same behaviour if you default width/height on <symbol> to 100%
... so if we did that I'd be fine with it

krit: what happens now that x/y are properties?

Rossen: what is the main use case here that would be broken if we don't do this?

Tav: if someone has incorrectly put x/y/width/height
... some browsers have ignored it, others have not

Rossen: what would be the expected behaviour or use that comes out from tooling?
... what would be more natual for tooling to output for this?
... when you're using <use>, I would expect tooling would probably define x/y/width/height on the <use>

heycam: so I agree that x/y on <symbol> is not useful
... but the argument would be consistency with referencing <svg>

krit: it's an edge case, I don't think content would be relying on this behaviour

Rossen: what would be the most natural thing from the author's point of view?
... in either case the code change would be straightfowrard
... I want to know what the effect for users would be

krit: <symbol width height> and <use x y> without width/height, that would be useful to avoid duplicating width/height all the time
... I think there is an argument to simplify the code
... by treating these the same
... the user could live with specifying width/height on <use>

dmitry: it looks more to be a bug in the spec rather than the browsers
... as an author, I would expect x/y/width/height to be available on <symbol>
... it's not a big deal

ChrisL: the underlying model when this was designed is that <use> positions a new thing, and that referenced thing has its centre of its coord system would pin it
... it does mean sometimes you need to display all four quadrants
... and there are some issues with clipping
... some people would rather specify the middle rather than 0,0

Tav: well we now have refX/refY on symbol, to match marker

Rossen: what would users want/say

roc: I don't think users are necessarily going to use this
... do we change the spec to make things things more consistent

<pdr__> cyril asked me to confirm that swiffy has indeed switched to canvas

ed: send a mail to www-svg asking for feedback, wait two weeks, decide then?

Rossen: sounds reasonable

<scribe> ACTION: Tav to mail www-svg about the symbol x/y/width/height issue and report back in two weeks [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action05]

<trackbot> Created ACTION-3738 - Mail www-svg about the symbol x/y/width/height issue and report back in two weeks [on Tavmjong Bah - due 2015-02-20].

<ed> scribeNick: ed

svg2 issues

<heycam> https://svgwg.org/svg2-draft/layout.html

heycam: this is the chapter for x,y,cx,cy and so on properties

<ChrisL> botie, tell cyril he was mean to zakim

<botie> ChrisL: excuse me?

heycam: issue 1: need to check the initial values for all of them

krit: r has different initial values for gradients and circle
... propose to make it 'auto'
... to make it work out the correct value depending on element

heycam: is this done with UA styles?

TabAtkins: auto is more for when auto is going to affect the results
... if you're just doing based on the element you should use UA styleaheets

krit: next issue, rx and ry should use zero as initial value
... something that's not there is fx and fy
... on radial gradient
... the descirption is complicated, by default uses values from cx and cy...
... we could set them to auto and make them do the same thing

heycam: it's a strange feature

krit: it doesn't define specialcasing for fx,fy

heycam: we did decide to make fx and fy properties, right?

krit: yes

heycam: did we only do this because we did the other gradient attributes?

krit: I think so

heycam: we should focus on the basic shapes
... don't do this for the gradient elements, even with cx, cy on gradients

ChrisL: but you can put presentation attributes on any element

ed: can't we just make them presentation attributes on particular elements?

heycam: if it's easier since presentation attributes work on any element (?)

krit: in webkit we didn't turn cx cy to properties on radialgradient

heycam: i'd prefer not making them presattrs in this case

RESOLUTION: don't make the layout properties into presentation attributes on the gradient elements

heycam: issue 2, what to do about x and y on text elements?

Tav: we also have them on tspan right?

heycam: yes
... the issue is that they're list of values
... either we could allow list of values in the property, but only use the first value
... or the attribute has some special processing
... one option is to not make x y presentation attributes on any of the text elements

krit: I like that, or alternatively make xy presattr on text, but map them to other properties
... don't quite like the second idea though

heycam: we already decided that the x,y lists are bad due to font issues
... so don't think we should allow the second one

krit: another way might be to apply the xy property to text elements, but also apply the positoning fromthe xy attributes also
... that would allow positioning from css

heycam: that'd be a little bit confusing
... but might be the best solution

Tav: so discourage use of the x,y,dx,dy?

heycam: I think we should try it out

krit: ok, so spec that and await feedback from implementations?

Tav: ok

RESOLUTION: add a new keyword value to the x and y properties that means use-the-list-of-lengths in the attributes, and set that with the UA stylesheet

<scribe> ACTION: krit to add a new keyword value to the x and y properties that means use-the-list-of-lengths in the attributes, and set that with the UA stylesheet and add a note to say that it's still an open issue [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action06]

<trackbot> Created ACTION-3739 - Add a new keyword value to the x and y properties that means use-the-list-of-lengths in the attributes, and set that with the ua stylesheet and add a note to say that it's still an open issue [on Dirk Schulze - due 2015-02-20].

<heycam> https://svgwg.org/svg2-draft/coords.html

heycam: next chapter, coordinates
... issue 2, are there any more up-to-date defs for sizing? (i haven't checked)
... prob needs some closer review by somebody
... someone should take an action to look at this?

<scribe> ACTION: krit to review the svg2 coordinate chapter [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action07]

<trackbot> Created ACTION-3740 - Review the svg2 coordinate chapter [on Dirk Schulze - due 2015-02-20].

heycam: issue 9, about pAR

<heycam> https://svgwg.org/svg2-draft/coords.html#PreserveAspectRatioAttribute

heycam: do ppl use 'defer' or can we drop it?

ChrisL: is this somehting new?

heycam: I think it's from the original 1.0 spec

krit: don't think webkit implements this

heycam: we have some tests for defer, but doesn't mean that ppl are using it
... would be happy to try removing it

ed: I'm fine with removing it

heycam: firefox at least supports parsing it

Tav: inkscape doesn't support it

krit: webkit parses it but ignores it

ed: so does that imply that we should allow it but say in the spec that it must be ignored?

heycam: would prefer just to remove it (don't think there's much content using it)

krit: think we should parse it but ignore it

heycam: I'd prefer removing it

RESOLUTION: make defer do nothing (and investigate removing it later)

<scribe> ACTION: krit to make defer be ignored in pAR [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action08]

<trackbot> Created ACTION-3741 - Make defer be ignored in par [on Dirk Schulze - due 2015-02-20].

heycam: next, issue 15

<heycam> https://svgwg.org/svg2-draft/coords.html#BoundingBoxes

heycam: in the bbox section
... bbox of text with the widht/height set on it
... should it be the box that it's laid out in, or the union of the glyph cells?

Tav: the text would just be the content area, can be reduced due to padding/margin

krit: we should handle it like normal block elements in html

heycam: so what should getBbox return?

Tav: there are different bboxes in css

<text x=10 y=10 width=100>A</text>

heycam: sometimes you have content that can't wrap

Rossen: inline elements don't have width in css
... this is closer to block
... the blockrelated properties is what should apply to svg here

heycam: we don't need to make getbbox does like getboundingclientrect
... if we ignore the width feature
... we might return the size of A

Rossen: with the width today if you specify it

<shepazu> (SVG also has different bboxes... geometric bbox, decorated bbox, etc.)

Rossen: you can say it's the bbox or that it's the union of the two, or just the text inside

Tav: depends on how much text you put in

heycam: it's a run of glyphs
... we can do pre-formatted text
... we can union the bboxes
... i think we shouldn't return the rect area defined by width/height for text

Tav: if you've wrapped text, some text sticks out further than the others, you should make that affect the bbox
... you'd have to look at all the lines to figure out the exact bbox

nikos: if we say width(height is always returned from getbbox you could just check the attribute

Rossen: the information for size of each line is available internally
... you might want each line separately

ed: multiline text is new in svg2, do we want to allow fetching the size of each line?

krit: cssom defines that getclientrects maps to getbbox (?)

roc: maybe think of it as shrinkwrapped
... the intrinsic preferred width

heycam: problem is tht dx dy influences the bbox

krit: we could disable them for the case of having width/height

heycam: the options
... 1) look just a the glyphs, take bbox of each and then union the bboxes
... 2) if you have width attribute then bbox has that exact width and height be multiple of lineheight
... 3) union of option 1 and 2

TabAtkins: option 2 is closest to what css is doing today

Rossen: what do we do for negative margin on inline boxes?

TabAtkins: doesn't count

Rossen: not sure it translates well to svg

(draws on whiteboard)

Rossen: think that we want two ways, if you want getclientrects (the content) you get only the text - you can do union, intersection or whatever you want

heycam: if we want options we have a param for getBBox that we can use

Rossen: so list of text content boxes, or the parent box that's the union essentially

heycam: we can always add a way to get the other one

Rossen: right, because we don't have any way to get the lineboxes

heycam: the only downside is that it's inconsistent with non-areabased text
... where we're using css to layout the text
... but shrinkwrapping the text

Rossen: that's fine though, the bbox is defined by the text content in that case

Tav: think we should not consider dx, dy and rotate in the textarea case
... for the bbox

heycam: I think the block level element in css should provide the bbox (positioned)

Rossen: when width is auto one of the three possible ways to size the box
... one is dependency on parent, in percentage
... other is that it's fixed
... third is that it's attached to the text content

-- break for lunch --

<nikos> scribe: Nikos

<scribe> scribenick: nikos

Text bounding box

heycam: we discussed over lunch
... when you call getBBox on a text element that has % or px or specified width then bounding box is the specified width
... and height is the height of the CSS box that gets created
... and if you leave off the width, then you take the union of all the bounding boxes for the text
... to handle cases where things are positioned
... if you don't have positions then it's like the other two cases where you're looking at the box and returning the bounding box anyway
... think that makes it a consistent model
... probably don't need to describe in terms of those three things

Tav: looks like a good solution to me

RESOLUTION: for text bounding boxes with specified width, % or px, then the bounding box is the specified width with height being the height of CSS box that is created - otherwise bounding box is union of all child text bounding boxes

<scribe> ACTION: heycam to spec behaviour of getBBox on text [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action09]

<trackbot> Created ACTION-3742 - Spec behaviour of getbbox on text [on Cameron McCormack - due 2015-02-20].

<heycam> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Open_issues

heycam: bogdan suggested we gather up open issues on this page - we might not have a chance to resolve them all this meeting
... so I summarised which I thought were substantive issues that need discussing

ed: back to text, if you have text element without width or height and you have white space property set to pre wrap
... you have some return characters to specify text as multiple lines
... you get three lines of text
... behaviour of bounding box should be as auto

Open SVG 2 issues

<heycam> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Open_issues

heycam: this list is based just on the red issues that are noted in the spec
... may be a few more things in tracker

<scribe> ... new ones may also pop up as we continue reviewing the existing text

UNKNOWN_SPEAKER: Erik and I have reviewed some chapters
... neither of us are through the whole spec yet
... so probably later chapters need a closer look than the earlier ones
... bearing that in mind, this wiki lists the substantive issues that are noted in the spec

cyril: some chapters start at issue number > 1?

heycam: we've already discussed some and some don't need discussing
... we may or may not get through this list
... how would you like to prioritise?

BogdanBrinza: normally for us we take a first pass at the list and find highest priority items

Rossen: hope we're in agreement we want to ship the spec?
... so we can tackle a couple of ways
... we can look at the spec as a whole - if we agree we want to close all issues and ship the spec
... then move to a modular way of advancing svg
... then first pass should be to decide the must unstable and non core things
... that we can live without
... and make those modules right now
... that will reduce the amount of work we need to do as a group to discuss issues
... so as a first pass lets find big areas we can remove
... then from remaining we can assess what is in most dire need of group discussion time

heycam: I like the idea of creating modules immediately for things we're removing

cyril: maybe not the case for all chapters - but some seem to be very close to modules

<BogdanBrinza> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_readiness_assessment

Rossen: is your list an extraction of this table?

heycam: has some correlation probably but this is just my judgement of the issues
... and which are not editorial

BogdanBrinza: think we agree on chapters that have most issues

Rossen: do we think we can go through the first step and move things to modules?

krit: I'm in favour of that - do you have features that you want to move

Tav: Think we'd spend more time arguing over which stuff to move than how to solve the issues

BogdanBrinza: Chapters 15, mesh gradients has a lot of issues

heycam: don't think we should be looking at the chapter level - but at features
... if we look at my list of open issues - do you agree that if we've solved open issues for a feature should it stay?

Rossen: not sure - if we can move something to the next level why spend time talking about it?

heycam: sounds like you have ideas about features you don't want to see in the spec - even though there are no open issues

Rossen: I wouldn't oppose a stable feature staying

BogdanBrinza: generally not about features we want in the spec - but everyone wants to see a stable spec

heycam: do you think stability is not solely determined by open issues?

BogdanBrinza: I'd say that's the most important thing - but severity matters too

heycam: I was going to suggest looking at features that correspond to open issues
... so if we've resolved issues on a feature it can stay

Rossen: do we consider features complete?
... or just enough stuff there so we think it's complete but not sure
... are we going to find issues when we review?
... ok lets go through each issue then

heycam: let's finish co-ords chapter then we can talk about features in other chapters

<scribe> ACTION: heycam to make stable issue identifiers in the spec [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action10]

<trackbot> Created ACTION-3743 - Make stable issue identifiers in the spec [on Cameron McCormack - due 2015-02-20].

issue 17, co-ords chapter

heycam: issue 17, co-ords chapter
... should fill correspond to the main area of that element?
... so fill:false should exclude that rectangular region?

<ed> for ACTION-3743 make sure that the template has fields for assigned actions, wg discussion and resolution

heycam: if it's not an svg element you can't call getBBox, but you can call it on the parent
... so iframe or canvas should contribute to the bbox

Rossen: if it's not exposed how can you get the bbox?
... should define getBBox on these elements

krit: if you put HTML in an svg document, how does CSS box model contribute to the bounding box computations - it's a general problem

Rossen: we define getBBox on foriegnObejct? Behaviour should be the same

krit: but on fo you have a whole html doc

heycam: fo and iframe and canvas just return the rectangle - but issue is whether fill dictionary parameter controls whether that contained element contributes or not

Tav: To me fill:false is not a sensible option
... as a control

heycam: sounds like we agree on that

RESOLUTION: The fill dictionary parameter doesn't affect bounding box of iframe, canvas, etc

<scribe> ACTION: heycam to update spec for fill dictionary parameter when called on iframe, canvas, etc [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action11]

<trackbot> Created ACTION-3744 - Update spec for fill dictionary parameter when called on iframe, canvas, etc [on Cameron McCormack - due 2015-02-20].

heycam: proposing to remove svg:transform’ attribute

krit: already done

ChrisL: where is it being moved to ?

heycam: no one uses it

ChrisL: mapping people use it
... my understanding is we changed behaviour for this to match what implementations do

krit: the removed text was mostly pointless

cyril: it's not the same as the transform attribute - same name but in a different namespace

heycam: if you think it's being used by people it can stay
... just worried wording is outdated

ChrisL: this was standardised through JIS

krit: I'll put it in integration spec

ChrisL: that's ok - just don't want it removed

AlexD: isn't this what Takagi-san is using for tiling?

ChrisL: yes

cyril: don't think it should be in integration spec - should be module on it's own
... I see integration spec as between svg, html, css

ChrisL: it's larger - how css uses things

Tav: I'd like to see it moved before it's taken out

krit: I'm doing it right now
... into a new module right/

ChrisL: section above it as well?

heycam: there was going to be a mapping spec?

ChrisL: yes but mapping spec by itself wasn't useful
... by itself
... so dispersed these features into svg 2 spec

Tav: that's why it's good having annotations describing why things are moved

RESOLUTION: svg:transform attribute will be moved to a new module

heycam: let's look at remaining issues in terms of the features they encompass
... all path issues are for Catmull-Rom

Rossen: who is implementing it?

Tav: it's Doug's baby

Rossen: can we have a Catmull-Rom module?

<shepazu> why?

ChrisL: tricky because it's in the path element

shane: we did that in CSS

ChrisL: was going to bring that up as a bad example

shepazu: there's a not great way - which would still be good enough
... supersede description in new spec
... good way is define what path commands look like
... and say future specs may define new path commands

ChrisL: agree, not sure how much work it is making it properly extensible

shane: could put all stuff in path extension spec

ChrisL: so in core svg 2 path syntax is the same as svg 1.1?

heycam: we have bearing and stuff
... that's an example of a feature that is complete in the spec, but people have reservations about it being in core svg 2

Tav: it's not something I care too much about having - but feel it will be ignored once it's in another spec

Rossen: that's how css works
... survival of the fittest - good features progress faster
... I think it's a good way to do things

TabAtkins: don't be afraid of modules

heycam: Doing things in modules is the right thing- but I'm concerned if we move features to modules then svg 2 won't be much different to svg 1.1

ChrisL: that's a problem because we've then spent 10 years producing a spec that doesn't have new features

Rossen: if you have 5 other specs in the pipeline then you have a good story

ChrisL: we've already gone from modules to one monolithic spec
... now we're going back

Tav: how much work to fix Catmull Rom?

heycam: need to add math to the spec
... issues could be summarily decided

Rossen: this is a good example of a feature that could move imo
... it's a good feature
... some designers have questioned it's use

Tav: there's a good use when connecting points in a graph

heycam: I would have to do investigation of the math

Tav: it's pretty simple

Rossen: if it was such a hot feature I'd expect Adobe, InkScape, etc to be pushing it

krit: Adobe already stated we don't care

heycam: so if you want a sense of it staying in svg 2 or being split ... ?

krit: not necessary for svg 2

Rossen: can we resolve to move it to it's own module

heycam: as long as we create a new spec immediately
... don't want to lose the work we have done

ed: do you have same concern about bearing?

Rossen: I haven't read the bearing stuff

heycam: I'll be less excited about shipping svg 2 with all the features removed

shane: I think we'll fairly readily be able to find features that have no issues or trivial and those that have substantive issues
... why not appoint champion or owner for features with substantive issues
... if issues aren't resolved by wg within a certain time frame we move it out

Rossen: features without issues shouldn't necessarily remain part of the core
... if features have expensive implementation cost then they should maybe moved out

heycam: we could mark them at risk

Jet: is there a list of at risk features/
... that's probably the first step

heycam: table in your wiki page isn't at feature granularity, which is what we need to discuss

Rossen: it's easy to decide on some - basic types for example

krit: svg 1.1 isn't going to disappear - it can still be referenced

stakagi: not using transform at the moment - it is ok to remove it from this level
... you can put me as editor of the svg:transform spec

heycam: Catmull-Rom - what are we doing?
... put with superpath as svg path level 1?

shane: it's a really nice target for modularisation
... doesn't mean it won't be published at the same time as svg 2

heycam: let's publish first draft of these things when we publish CR of svg 2

RESOLUTION: Will create SVG path module

heycam: should svg 2 path only be what is supported by 1.1?
... so move all new things (e.g. bearing) into the module?

shane: there is work involved in moving stuff - if a feature has no issues then leave it

heycam: I'm ok either way

Rossen: i'm ok with either too

heycam: minimum work is leave it where it is

all: let's do that

<scribe> ACTION: heycam to move Catmull-Rom to SVG path module [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action12]

<trackbot> Created ACTION-3745 - Move catmull-rom to svg path module [on Cameron McCormack - due 2015-02-20].

heycam: Editors will be Cam, Doug, and Cyril

TabAtkins: do we want to use CSS naming where everything that builds off SVG 2 is next level?
... then we'd start at 2

all: that's confusing, let's start at
... 1

heycam: next bunch of issues are to do with text
... either shape text or rectangular ref text

Rossen: are your issues in an order?

heycam: just numeric

Rossen: can we do things with only 1 issue?

heycam: Let's do animate.html, Issue 2

birtles: basically new features we'll defer to a separate spec
... then there's one or two edits I should make with regards to correctness
... not sure about allowing animatemotion to use a basic shape
... not sure if we want to include those slight improvements
... or defer everything

Rossen: what would it look like after your change?

ed: we resolved to allow basic shapes for text on path

birtles: so for consistency we should leave it
... major features will be deferred
... I can take care of the issues that are there
... and get rid of references to features which we'll put in a different module

heycam: can we discuss attributeType="auto"?

ed: I came across issue with SMIL elements and attributeType
... default is auto which means check if it's a property first
... if so that's what your'e animated, otherwise attribute
... since we made x and y properties
... it's a problem on text element
... which takes a list of values
... I'm wondering if we should try to be smarter here selecting the right thing

heycam: why wouldn't that content work now?
... auto means when both property and presentation attribute, choose the property right?

ed: if we make x a property, we'll try to animate x as a css property
... and that might not give the same result as previously

heycam: outcome of previous discussion was that it would work
... property is the primary thing that determines the value

ed: if you have a list of values (e.g. "10 20 30") it's not valid for the property, so animation will stop working when it used to work
... one suggestion is to make auto pick the xml version if it's a text element
... that will preserve old behaviour
... and pick css property for any other element

Rossen: and when number of values is one?

AlexD: I don't like behaviour of attribute depending on what it's parent is

birtles: you have to look up parent or target anywhere when animating

AlexD: but not when binding

birtles: yes you need to look to see if there's an attribute of that name that can be animated

AlexD: seems like strange behaviour to me
... choose one or the other and whatever it breaks it breaks

Rossen: doesn't sound like much will break

ed: expect most would use one value

birtles: I think there'd be some breakage
... you see people moving characters around like that

Rossen: I'd be more concerned about tools and tool makers

birtles: that suggests keep backwards compat

AlexD: don't know if there's any tool that generates this

birtles: I was hoping to deprecate attributeType altogether

ChrisL: attributeType was introduced to disambiguate a name class between width and height attributes and properties

<birtles> Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1062106

ChrisL: so most of the time you didn't need to specify it
... in some was we have more of a clash now
... we've promoted lots of things that were attribtues into properties
... so I don't think it serves much purpose at the moment
... think people tended to guess as to which value to set
... and it usually didn't matter
... so you'd probably find uses - but removing attributeType would probably render just the same

birtles: but how do we make text case work?

Rossen: state it's deprecated

birtles: if we get rid of attributeType how do you animate x attribute on text element?

Rossen: so what are options we have?
... option a) remove attributeType altogether because pretty much all properties are attributes and only x is problematic
... we'll deprecate multiple x/y value animate for text
... as a consequence

ed: do we want to consider deprecating having multiple x/y values on text element

cyril: it's heavily used isn't it ?

krit: yes but not for animation

<scribe> ACTION: ed to add use counter for multiple x/y values on text element [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action13]

<trackbot> Created ACTION-3746 - Add use counter for multiple x/y values on text element [on Erik Dahlström - due 2015-02-20].

Rossen: let's wait for more data then

ed: don't think we need to make both decisions at the same time

Rossen: option b) get rid of attributeType and in this case have a fall back mechanism for the property that gives a list of values
... e.g. we can take last or first valid attribute from the list
... and animate with that
... which will again break animation, but not as badly (maybe)
... in one case you have no animations at all - second you have animations of one frame
... not perfect, but less invasive
... option c) get rid of attributeType and add special handling for x on text
... make it context aware
... is there another option where we extend the attributeType to specify instead of doing context aware

heycam: it already has values to select attribute or property

ed: we could make auto on text elements, pick xml as the default

Rossen: option d) attributeType for animate inside of text is always xml - there is no auto
... would reduce options in future

cyril: detect number of values?

Rossen: that would be hacky

birtles: I think we could drop attributeType and leave a note in the spec with the context aware behaviour as an open issue
... see what data we get on the use counter
... if there's not sufficient usage of multiple values for x we drop, otherwise we do context aware

Rossen: what about if we deprecate it now and see who fights for it?

birtles: I know there's a lot of opposition to multiple values for x anyway

ed: difference between static text with multiple values and animated multiple values - there will be a lot less animated

cyril: removing attributeType is ok - but the consequence in option a is not acceptable

birtles: the consequence only applies to animation

cyril: ahh ok

birtles: there is a work around for jittering text
... using dx/dy

RESOLUTION: remove attributeType and deprecate animation of multiple values in x/y

Rossen: that was the big issue with animation - so this chapter is mostly clear

birtles: I need to do some more tidy up but yes

heycam: interact.html ISSUE 1: should we remove duplicate events like SVGLoad? is already resolved
... lacuna value for pservers.html ISSUE 3: linearGradient y2 lacuna value is already resolved
... the value should really be zero

RESOLUTION: lacuna value of y2 on linearGreadient should be zero

Rossen: what about masking.html ISSUE 2: define how overflow-x,y work ?

krit: being moved
... ISSUE 3: should overflow:auto really be equivalent to visible
... we changed behaviour based on ie

Rossen: thought we discussed in London?

nikos: from London - All viewport-establishing elements will be overflow:visible by default, except for root <svg> of SVG whole documents.

http://www.w3.org/2014/08/22-svg-minutes.html#item04

Rossen: seems like a perfect fit for integration spec

krit: do we move overflow to integration spec?

heycam: why is it in our spec?

ed: we have lots of special rules

heycam: remove that section, add relevant UA rule and that should be enough
... krit can we really remove it all?
... I need to think about it - give me the action

<scribe> ACTION: Cameron to take care of overflow section in the masking chapter [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action14]

<trackbot> Created ACTION-3747 - Take care of overflow section in the masking chapter [on Cameron McCormack - due 2015-02-20].

nikos: a lot of the stuff in Clipping, Masking and compositing will move to rendering chapter or be removed so this chapter will probably go

RESOLUTION: masking.html, issue 2 - Drop overflow-x,y issue and don't do anything specific in SVG

krit: so all these changes are going to integration spec and are being removed from svg 2?

Rossen: yes

heycam: i'm concerned that it's not valid to state that auto on a particular element computes to a different value

Rossen: we do that all the time

RESOLUTION: masking.html ISSUE 3: should overflow:auto really be equivalent to visible? Should be moved to integration spec and removed from SVG 2

krit: can we remove 15.3 and 15.4 totally?

heycam: think in rendering chapter we need to describe how these things fit into the scheme of things

nikos: I think rendering chapter should say at what point these things occur and that's all

<ed> -- 15 min break --

<Tav> scribe: tav

<scribe> scribenick: Tav

Rossen: , Let's cover issue in color chapter.

svg2 issues in the color chapter

<cyril> s/Rossen,/Rossen:/

<ed> https://svgwg.org/svg2-draft/color.html#color-managed-images

Rossen: Issue 1:
... should this be here?

TabAtkins, : Should be in colors4.

scribe: not in yet, will be soon.

krit: What do we need to keep?

Rossen: Tab, what do we need to keep?

TabAtkins: Nothing.

Rossen: Motion: move everything in this chapter to color4.

<Rossen> https://svgwg.org/svg2-draft/color.html#InterfaceSVGColorProfileRule

krit: SVG Interface rule should disappear.

ed: will icc-color be part of the <color> grammar in css?

Rossen: Yes, should be in colors4.

RESOLUTION: Drop SVG color profile rule interface.
... Remove color chapter from SVG 2. Refer to CSS Color 3 and 4.

<scribe> ACTION: TabAtkins Finish CSS Color 4 (with stuff from SVG). [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action15]

<trackbot> Created ACTION-3748 - Finish css color 4 (with stuff from svg). [on Tab Atkins Jr. - due 2015-02-20].

<krit> https://svgwg.org/svg2-draft/types.html#InterfaceSVGCSSRule

<krit> https://svgwg.org/svg2-draft/types.html#InterfaceSVGRenderingIntent

Remove above two interfaces.

ed: Should go.

<ed> (to be clear, the entire room says that, not just me ;)

RESOLVE: Remove InterfaceSVGCSSRule and InterfaceSVGRenderingIntent.

Rossen: Only two chapters to go from heycam's list: painting & text.

Painting chapter issues

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

<Rossen> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Open_issues

heycam: first two issues are to do with arcs line-join

Tav: first issue is the name
... nobody suggested a different name
... so let's just leave it as is
... second one is what do you so with miter-limit
... now that we have this clipping option, ...
... it's possible to get a very long arc
... I would suggest that taking the mid point of the end of the stroke before the cap, then measure along the mid-arc the miter limit

RESOLUTION: arc line caps are affected by miter-limit by measuring along the middle arc and clipping a straight line perpendicular at that point

<scribe> ACTION: Tav to make miter-limit work on arc line caps in this way [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action16]

<trackbot> Created ACTION-3749 - Make miter-limit work on arc line caps in this way [on Tavmjong Bah - due 2015-02-20].

<Tav> Scribe: Tav

<scribe> ScribeNick: Tav

Issue: stroke-dashcorner doesn't work well for rounded rects

heycam: New feature in SVG 2. It's nice.
... look at pictures in section.

<heycam> https://svgwg.org/svg2-draft/painting.html#StrokeDashcornerProperty

heycam: Illustrator supports.

krit: Illustator dashing different.

heycam: Not the most important issue.

krit: Could we have a stroking enhancement spec?
... would like to have a core with what is supported today.

heycam: Not happy with pulling out stroking.

ed, Rossen stroking should be well defined.

krit: doesn't include stroke-alignment...

Rossen: The fact that stroking will be well defined in SVG 2 we could still have a stroking spec.. What would be in it?

heycam: I can summarize the new things:
... stroke-dashadjust
... stroke-dashcorner
... arcs line join
... stroke-alignment

krit, tav: stroke-alignment often requested.

tav: would like to have %

Rossen: stroke-dashcorner: our (IE) implementation for stroking is pretty complicated, could be hard to do.

krit: Used in illustrator.

heycam: Can just stretch dash array.

Rossen: We still don't have interopability with normal dashing today.

roc: SVG stroking is actually rather simple.

<ed> (in comparison to css border dashing)

roc: We need an extensible stroking task force. Lots of neat things you can do.

Rossen: Should there be a new module?
... What would be in the new SVG stroking module:

ed: Variable width stroking.

Rossen: That's a really cool feature.

krit/Rossen Dashing and Variable width.

Rossen: We extend in CSS specs with just one new value of a property.
... New specs should only add stuff that's not in already in SVG 2.

krit: But what should we ship here for SVG 2?

heycam: I think there are some things already implemented that should remain.

Rossen: Should we start with stroke-dashcorner? (Moving to new spec)

heycam: Question at approach: we've been telling authors about these new things. How can we maintain the message that things will be coming at the same pace.

Rossen: I think that moving things into modules sends the message that we can move faster than with a big SVG2 spec.

krit: I'm happy to move out new marker stuff to new spec.

heycam: There would be some overlap in text between specs.

Rossen: there are modules that we would ship ahead of SVG2.
... Interlude: explains IE/Microsoft philosophy towards choosing what to ship.

krit: Can we have a resolution having a painting module?
... put in paint-order

ed: Don't think that's a good idea.

tav: Would you (Rossen) implement 'paint-order' if it was in a separate spec?

Rossen: Yes.

ed: We could say that this section is stable.

Rossen: It's not in a stable spec.

Discussion of where things should go....

Rossen: Should we start an SVG marker spec?

heycam: I'm more concerned about public impression of SVG 2 if things get moved out.

<shepazu> modularization is time consuming and confuses developers

<ed> +1

BogdanBrinza: What the SVG working group thinks is more important than public perception.

<ed> (the time consuming part)

heycam: Things in the past that have been split out tend to mean that we don't want to work on it.
... One advantage of splitting out is that we would have a well defined owner for the spec.

Tav: A markers spec would be a good trial of this.

ed: Not clear that a marker spec could move faster. There is a lot of stuff tied to SVG core.

Rossen: having something in PR is much better than having some text in the bigger spec.
... saying this is stable.

krit: marker knockout should be moved to a separate markers spec.

heycam: ignoring the marker knockout, the rest is pretty stable.

Proposal: Start a new marker spec.

ed: Not so sure about this but won't object.

tav: with eric

heycam: Is willing to try it.

RESOLUTION: Move new marker features to a separate marker spec.

Rossen: We won't be discussing the following issues:

<Rossen> ISSUE 23: what to do with marker knockouts

<Rossen> ISSUE 18: name these vertex or segment markers?

<Rossen> ISSUE 30: should paint-order be able to select the different types of markers?

<Rossen> ISSUE 32: should SVGMarkerInstance objects be live? (or should we remove those interfaces?)

Rossen: Let's get back to stroke-dashcorner for rounded rects.

heycam: Dashing will move slower than markers. Dashing should move into a stroking spec.

Moving on to text issues.

Tav: Meta issue: how do we treat all the various text properties?

General discussion...

Rossen: It would be reasonable to expect that paragraph level things would work. (text-indent, etc.)

heycam: Properties that apply to inline elements should work.

roc: some aren't appropriate perhaps.

Rossen: overflow:scroll?

ChrisL: Don't want a white list.

krit: Text handled by normal code path.

Rossen: So do we.
... In trident we have the concept of paragraphs that are like blocks with out the blocky stuff (padding, etc.)
... text alignment, writing mode, etc. are supported.
... underline, bold are handled in one level down.

heycam: We should have a paragraph guiding our intentions so when new things come along they can be automatically included or excluded.

Rossen: We could ask the CSS working group to add a term that defines paragraph level properties.

roc: CSS does have the concept of anonymous blocks. We want everything that effects these blocks. But there is no name.

krit: We should ask CSS for an "official" name.

RESOLUTION: 'text-indent' applies to <text> as it is part of the CSS paragraph level properties.
... CSS Paragraph level properties are assume to apply to SVG <text> element with wrapping context.

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

Rossen: so that resolves issues 37 and 38
... shape-inside, shape-outside

Tav: I think I know what to do with these now after discussing with CSS folks

Rossen: I am the editor of that spec, too
... so the rest of the issues are shapes related
... issue 2, are dx/dy/rotate ignored for auto-wrapped text

ChrisL: when would you want to do that

heycam: never

Tav: I would be fine with that

ed: I agree

ChrisL: those things were because we didn't have wrapping text
... and some people wanted to do "better" text on a path

heycam: you could argue from consistency with single line text
... you could apply the positioning attributes to content area text just as easily
... but it won't be useful

RESOLUTION: dx/dy/rotate are ignored for text with a wrapping context

Rossen: last, issue 4; should x/y specify the corner of the content area or the origin of the first glyph

[Tav draws and shows the two options]

Rossen: I suggest using extent rather than width/height
... then authors won't think you should be able to put both width and height

RESOLUTION: Change width/height on <text> to extent

<scribe> ACTION: Tav to make the text changes from today's meeting [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action17]

<trackbot> Created ACTION-3750 - Make the text changes from today's meeting [on Tavmjong Bah - due 2015-02-20].

RRSAgent: make minutes

<pdr__> svgwg is rocking it for sticking with the pathseg removal.

<krit> commit 7d2ff7e2f7a1fd55f152f6b308f695915a814408

<krit> Author: Cameron McCormack <[email protected]>

<krit> Date: Fri Feb 13 22:13:02 2015 +1100

<krit> Markers module.

<krit> commit ce33635151342971e99b63c2cf63db8cb82a9e7e

<krit> Author: cconcolato <[email protected]>

<krit> Date: Fri Feb 13 11:39:52 2015 +0100

<krit> fix broken markup

<krit> commit 74e23360c8d7460facb61ef92f7b5919e7518cc3

<krit> Author: Dirk Schulze <[email protected]>

<krit> Date: Fri Feb 13 21:27:37 2015 +1100

<krit> Initial marker spec

<krit> heycam|away: I was ~1h earlier ;)

trackbot, start telcon

<trackbot> Meeting: SVG Working Group Teleconference

<trackbot> Date: 13 February 2015

<scribe> Chair: Cameron

<scribe> Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Agenda_proposals

<BogdanBrinza> scribe: BogdanBrinza

<scribe> scribeNick: BogdanBrinza

topic is SVG Markers

SVG Markers

<heycam> https://svgwg.org/specs/markers/

<heycam> https://svgwg.org/specs/marker/

heycam: Both Dirk and I took first step o producing first spec version for SVG Marker Level 1
... The question is - is this ready for first publish working draft

Rossen: In CSS WG the rule is you have a short name - which is stated on the module
... so that in mailing list you reference this and a page with issues

heycam: So in the end we should combine two versions

krit: We should decide on short name

shane: so markers would work nice and align with CSS

Tav: should we have a Level 2 already?

heycam: does everybody agree that knockout should be in L2?

Rossen: in FPWD we can have it and then split if needed. no reason to push this off

cyril: What about section 9? how markers are rendered?

heycam: I just missed copied that initially - will add this soon
... so the current approach is to copy all stuff we had in old spec at the moment

shane: it should be fine to use either

Rossen: again, the rule we follow in CSS is simple - if you're extending 2.1 you copy whole section and start extending
... if we're extending from SVG 1.1 this is something we can do, if we're extending from 2 (that is not ready) we can just get the deltas

birtles: As an author I don't like the deltas

<birtles> (because I have to look up two specs)

heycam: so what are we doing? deltas / no deltas?

Rossen: let's agree on consistency

cyril: is there a pointer in CSS that goes from L2 to L3?

Rossen: not really

cyril: this might be confusing if you want to find the latest version - google will give you not the latest

Rossen: CSS snapshots address this and everything that is up to date at certain moment

Tav: pointer up might be useful

cyril: pointer to a stable URL might be useful

RESOLUTION: Publish SVG Markers Level 1 as FPWD
... All specs would have a pointer to a stable SVG summary spec (snapshot) that lists the status of all modles

heycam: Because I took a text from SVG2 for this section - if SVG2 doesn't progress fast enough we might need to change links to SVG 1.1

Rossen: and you're going to move the section about rounding the markers?

heycam: knockouts?

Rossen: no details about the rendering

heycam: yes, I'll move this in
... So remaining on the agenda is next F2F meeting, motion path animation and couple of Tav topics

shane: didn't we decide we won't talke about motion path?

krit: yes

Rossen: where we left on remaining issues is
... we need to sync with Tav on remaining shapes issues

<heycam> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Open_issues

Rossen: next pat is painting where we took issues related to markers

we decided miter limits, arcs and remaining are stroking issues

Rossen: so the discussion was should we keep strokes in SVG2 or move to a new spec and fix the issues on fixed timelines

heycam: strokes are pretty much the same level of readiness as markers - so it should be also splittable if we want to

Rossen: this is great sign that SVG2 spec moved as set of modules

ed: so how do you want to do split? move jsut new things or everything?

Rossen: we should still move stroke the same way we moved markers
... so when we clean SVG2 strokes sections we should add extensions since 1
... when we ship SVG2 we'll have a section about stroking and new behavior goes to a separate spec
... and we can move or keep the new wording

heycam: it might be easier to take the whole section

Rossen: so who would be editor beside you?

heycam: there are stroke-dashcorner, miter-limit, arcs

someone: what about variable stroke width?

<birtles> birtles: that got deferred because I don't have time to work on it at the moment

Rossen: yesterday we decided we shouldn't move good ready modules - so from previously noted list of stoking features which are stable or ready to move

heycam: there are number of issues and discussions those features need
... so it would be useful to have implementors to try those features to provide feedback

Tav: Inkscape has prototype for arcs, not yet implementing dashing

Rossen: does anybody has implementation for stroke-dashing?

all: there are no current implementations of dashing

Rossen: so it would be good candidate to separate
... so arcs can live in current spec

heycam: we can have features at risk in the spec
... so we're moving this decision a bit earlier

Tav: so why would be pain-order at risk?

heycam: it's not - it's example of feature not at risk

Tav: so what about multiple stroke width?

heycam: it's a new and can be moved

krit: so multiple stroke width can go with multiple stroke layers

heycam: unless we want to decide how we want to ship with / without multiple stroke width

nikos: agree

Rossen: so in that case who is going to be the editor of SVG stroking

heycam: it's currently all features I've added

Rossen: so Cameron and Dirk?

cyril: I have a question regarding naming
... so we went with SVG Markers Level 1

Rossen: every module starts with Level 1 unless you're extending existing one

Tav: so what is extending in this case?

someone: so there was a initial confusion with CSS3 because it became a buzz word

krit: but we can start with Level 1 here

heycam: Let's stick with Level 1

cyril: so you have SVG 2 and Markers Level 1
... wouldn't they assume it's based on SVG 1?

shane: people who you're talking about wouldn't read the spec
... and the target audience already understands that state and what is based on what

Rossen: for now let's not give them many levels

birtles: that's wonderful

Rossen: so SVG strokes / stroking / else?

all: SVG Strokes

RESOLUTION: Create new spec SVG Strokes with heycam and krit as editors

Rossen: can we move to FPWD?

heycam: I'd like to check the text and we can review after that

all: we would be happy to resolve to publish

RESOLUTION: Publish FPWD of SVG Strokes

Rossen: that is pretty much all issues Cameron brought up
... so we currently have two new modules and remaining issues. What else is blocking?

heycam: existing issues and editoral changes
... so in order to move forward we might need to understand amount of editorial work and assign

https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_readiness_assessment

Rossen: so let's take a look at the sections in red currently

krit: so document structure?

Rossen: give me one second to log and put owners names to chapters
... ed you mentioned you can use help from somebody?

ed: Rich send a mail that there might be changes to better align with HTML and provide better accessibility
... there shouldn't be major issues, but need to go through all
... the major one - <use> alignment with web components TabAtkins
... the rest are DOM interfaces, mostly clarifications

Rossen: API design is not somethign to blaze through

ed: this is not API design - this is clarifications

heycam: I'd like to have each chapter to have a single point of contact

Rossen: there is still decent number of issues on Document structure

ed: we did resolve some issues on F2F

Rossen: suggestion - can you take a first pass at issues and editorials and bring this back to WG discussion
... on Document structure, Erik is primary owner, TabAtkins would help with <use> and rest is mostly editorial changes
... next one is Text and has a clear owner - Tav

Tav: yes, rest of the issues can be addressed pretty soon

Rossen: looking through the spec - we knocked most of them yesterday and at this point it's mostly cleaning up

Tav: for first pass I can take a look and get back with any outstanding issues

Rossen: Paining, etc - most of the issues have been moved to seprate specs, so cleaning out would give us a clean state
... the owner was still heycam?

heycam: yes

Rossen: next Paint Servers. There were issues on mesh gradients not in heycam's list?

Tav: those are minor issues. Inkscape has mesh gradients implementation for 3 years

Rossen: so in that case - after cleanup driven by Tav we can take another look and get help
... Basic Data Types - owner heycam and he has a good handle on this one
... next Styling

heycam: this might be in poor state and would need rewrite
... I think what this chapter should become is description on which CSS modules are required
... and description of presentation attributes

Rossen: why this is not part of integration chapter?

heycam: this chapter currently is describing how other things are used in SVG

Rossen: this is an inverse of integration chapter

krit: we also write what specifications we rely on CSS

heycam: we should put specifications SVG relies on

Rossen: so can we assign the owner to clean this and decide the struecture of this one?

heycam: I would like to do that

Rossen: we're having to much on heycam, but let's try this and on next telcons learn what we can do to help

BogdanBrinza: I can take remaining yellow ones
... so Paths, Embedded content are on me with help from WG

Rossen: next introduction section - cyril

nikos: Rendering model - that should be me

Rossen: next SVG Layout properties

krit: that's me

Rossen: Basic shapes - Rossen

krit: Color section would go entirely with additional work from TabAtkins

Rossen: Clipping and masking - krit, nikos

all: Filter effects are gone

cyril: Linking makes sense to keep with Embedded content

BogdanBrinza: so Linking goes to BogdanBrinza as well

Rossen: Animations - birtles
... Scripting might be close to Animations

birtles: might not be able to take it before April

Rossen: ok, BogdanBrinza and Rossen will take it
... Metadata - owner ed pending merge with document

ACTION ed to merge Metadata chapter with Document structure

<trackbot> Created ACTION-3751 - Merge metadata chapter with document structure [on Erik Dahlström - due 2015-02-20].

ACTION krit to remove Backwards Compatibility

<trackbot> Created ACTION-3752 - Remove backwards compatibility [on Dirk Schulze - due 2015-02-20].

Rossen: Extensibility - I can take this

ACTION BogdanBrinza to add Addendums to the SVG readiness table

<trackbot> Created ACTION-3753 - Add addendums to the svg readiness table [on Bogdan Brinza - due 2015-02-20].

<heycam> -- 15 min break --

ACTION BogdanBrinza summarize owners for chapters in https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_readiness_assessment

<trackbot> Created ACTION-3754 - Summarize owners for chapters in https://www.w3.org/graphics/svg/wg/wiki/svg2_readiness_assessment [on Bogdan Brinza - due 2015-02-20].

Timeline for SVG2 and modules

Rossen: how about we put timelines/cap on chapters
... next telcon is not goign to happen in next two weeks
... so owners of the chapter need to put items on the agenda and highlight most critical issues

heycam: we might not cover all things we have on the next call

Rossen: is there anyone who believes we won't meet 3 weeks for having all of the assessments and starting actual work?

heycam: by March 5th we should have those things listed in actionable state
... there are couple Appendicies I would propose to remove
... Internatialization support appendix

<heycam> https://svgwg.org/svg2-draft/i18n.html

cyril: I can add things in Introduction chapter?

RESOLUTION: Remove the Appendix F: Internationalization Support

<heycam> https://svgwg.org/svg2-draft/minimize.html

ed: next one Appendix G

RESOLUTION: Remove Appendix G: Minimizing SVG File Sizes

heycam: Next one Appendix N: Media Type Registration for image/svg+xml
... Chris would check where that links to

ed: this might point to latest TR version of it

<cyril> iana link: [http://www.w3.org/TR/SVG/mimereg.html]

<cyril> check this page: http://www.iana.org/assignments/media-types/media-types.xhtml#image

ACTION ChrisL to check and remove Appendix N: Media Type Registration for image/svg+xml

<trackbot> Created ACTION-3755 - Check and remove appendix n: media type registration for image/svg+xml [on Chris Lilley - due 2015-02-21].

ed: Appendix L: IDL Index - do we need this?

krit: this is just an index

heycam: IDL definitions would include all, maybe we don't need them in two places?
... so let's leave that in place

<heycam> https://svgwg.org/svg2-draft/access.html

heycam: next one Appendix E: Accessibility Support

<Rossen> ping

<Rossen> ping

<BogdanBrinz> ACTION Rich to define the further steps for Appendix E: Accessibility Support

<trackbot> Created ACTION-3756 - Define the further steps for appendix e: accessibility support [on Richard Schwerdtfeger - due 2015-02-21].

SVG2 WD publication

<BogdanBrinz> RESOLUTION: SVG WG to publish SVG2 WD

Next F2F meetings

<ed> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015

<ed> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015

<ed> https://www.w3.org/2002/09/wbs/19480/Linkoping2015

<ed> please sign up

<BogdanBrinz> ed: What is our next after Linkoping?

<BogdanBrinz> Tav: what are the options?

<BogdanBrinz> Rossen: Paris with CSS WG

<BogdanBrinz> all: also SVG Open

<BogdanBrinz> RESOLUTION: Next SVG F2F after June would be TPAC

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

Smoothing in mesh gradients

<Tav> http://tavmjong.free.fr/SVG/MESH_SMOOTHING/index.html

Tav: coons patch meshes suffer from a flaw
... the derivative of the colour profile can have jumps at patch boundaries
... leading to visible artifacts, bright lines, etc. at patch corners
... this is enhanced by mach banding, where your eye is caught by changes in the color profile
... you can see that the color distribution is continuous, but appears to your eyes that it has bright white bands
... the way illustrator and coreldraw handle this is they smooth their meshes
... for adobe, when you export the mesh, it subdivides a patch into an 8x8 array of patches

nikos: I think it might be adaptive

Tav: at least in one example I've seen 8x8

nikos: certainly a lot of patches

Tav: you can see it on the screen
... you can see the little patches
... it'd be nice to be able to do that smoothing in SVG, then you can reduce the number of patches in the file

nikos: and it means you don't lose the information in the editor

Tav: so I did some experiments with various smoothing algorithms
... I show them in 1D
... the top one on that page above is what you get out of a coons patch mesh now
... you can see the discontinuity
... the first thing to try is a hermite, a simple smoothing algorithm where the deriviative across the boundary is zero
... it makes the profile within the patch not to be linear
... looks wavy
... next is to try Catmull-Rom interpolation
... that gives you the hermite function, but what you need is the tangent across the boundaries
... the next three examples on the page does that
... the difference between them is the end treatment
... one doubles the first/last points, one reflects them (the n+1 point is a reflection of the n-1 point)
... the third is insisting that the polynomial is a quadratic
... so you have the magnitude of two points on one side, and you have a tangent. you can fit a quadratic to that.
... that seems to be what's happening in illustrator

cyril: I remember reading a paper explaining what adobe was doing

nikos: by Sun

Tav: the next problem is that Catmull-Rom curves can produce minimum and maximum values within a patch
... you can avoid that by restricting the tangent to a value that's 3 times the value of the tangent you get when looking across the whole patch
... it gives you a monotonic profile
... so you adjust the tangents to get that
... now, looking at 2D
... there is a bicubic-interpolation you can do, which I've implemented in inkscape

[shows a demo]

scribe: my proposal is to have a patch have a type, default would be coons patch, second type would be smooth

nikos: this doesn't let you control the gradient across the boundary
... if you want a sharp boundary you couldn't achieve it

Tav: you could by adding an extra row in

nikos: it'd be nice to have a control

Tav: that complicates things quite a bit
... this is just one flag
... the algorithm is here, fairly easy to implement

nikos: in Illustrator, can you control the gradient?

cyril: no

Tav: this matches Illustrator's behaviour

cyril: calling it "smooth".... "bicubic" would be clearer

Tav: I'm fine with that
... my proposal is to add this and spec it all out
... I've got the formulas and prototype implementation

cyril: you'll turn off all the other modes in inkscape?

Tav: yes that was just for demonstration

cyril: now that the mode does not say "smooth", it'd be good to ensure we don't preclude adding additional controls in the future

nikos: the reason we were talking about having different elements was that otherwise you'd have different attributes depending on the value of type=""
... if we had smoothing and we wanted to add control points for the smoothing...

Tav: I don't see it ever happening
... you'd need control points for the three different colours?
... that's an order of magnitude more complicated in editing

nikos: if you give them the raw control, yes it's a lot of work
... but I think you an simplify that through UI for authors
... having a handle to control how far out something is spread would be useful I think
... I just don't want to not have the option to do that later, or for it to be a confusing syntax later

Tav: do you have an idea what syntax you would use?

nikos: not at the moment
... even if you controlled the channels separately for the handles, it's not nice for authors, but could be for converted content
... vectorised photographs for example

Tav: I'm worried that that will delay meshes

nikos: I don't want to do that
... I really like this proposal
... we should go with it
... I just want to keep the door open to extending without running into nasty syntax in the ftureu

Tav: you'd have to add a new thing to the patch
... dx/dy for each of the colours

cyril: derivativecontrol="coords"

nikos: would rather have a different element when you have a different mode

cyril: is this part of the SVG 2 spec?

Tav: it's all worked out, I'd just add it to SVG 2

nikos: I'm OK with having a type="" I think
... if you have something with extra handles you could have a new element later
... ok

RESOLUTION: We will have a type="smooth-bicubic" or similar on <patch>

<scribe> ACTION: Tav to add <patch type="smooth-bicubic"> to the spec. [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action18]

<trackbot> Created ACTION-3757 - Add <patch type="smooth-bicubic"> to the spec. [on Tavmjong Bah - due 2015-02-21].

nikos: because the control is on the patch, you can have a mesh made of smooth and coons patches

heycam: is that useful?

Tav: no the type="" goes on the <mesh>

ACTION-3757: Actually type="" is on the <mesh> element.

<trackbot> Notes added to ACTION-3757 Add <patch type="smooth-bicubic"> to the spec..

<cyril> http://en.wikipedia.org/wiki/Monotone_cubic_interpolation

<scribe> ACTION: Cyril to investigate web-platform-tests for SVG test suite and write up a wiki page [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action19]

<trackbot> Created ACTION-3758 - Investigate web-platform-tests for svg test suite and write up a wiki page [on Cyril Concolato - due 2015-02-21].

<stakagi> https://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_Overview

<stakagi> last update : June 2012

stakagi, :)

stakagi, that would be a good page to update

<cyril> http://testthewebforward.org/docs/

<cyril> https://github.com/w3c/web-platform-tests

<cyril> https://github.com/w3c/test-results/

outermost svg element definition

<birtles> https://svgwg.org/svg2-draft/struct.html#TermCurrentInnermostSVGDocumentFragment

<html> <svg><foreignObject><html><svg><svg>

[reads out definitions of "current innermost" and friends]

birtles: I think we can drop half of these definitions

krit: depends where they're used

ed: perhaps this chapter is not where they're used first

<scribe> ACTION: Brian to fix outermost/innermost svg element definitions, checking where they're used currently [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action20]

<trackbot> Created ACTION-3759 - Fix outermost/innermost svg element definitions, checking where they're used currently [on Brian Birtles - due 2015-02-21].

-- adjourned --

but first...

motion path

shane: couple of minor issues

<krit> http://dev.w3.org/fxtf/motion-1/

shane: some of these are adding more details/examples
... another is what happens if the position is negative or exceeds the motion path length
... we've decidd that if it's a closed path it wraps, if it's an open path it clamps
... we have one about "more natual names" for auto and reverse
... an issue about how to get the position in more detail
... an issue about path transform computation needing to be more explicit
... and finally do we need to specify an origin of an element in motion so it can be positioned appropriately
... I think of all of those, the only ones we don't have a good answer for is the origin one
... I think we should just use transform-origin in this case
... it says in the issue we probably shouldn't, but we should!
... the motion is going to end up in the transform list anyway

cyril: a problem is that the motion animation is an additional transform
... you could combine those two; if you think they have the same origin...

shane: the motion path spec isn't a clean drop in replacement for animateMotion
... you need to be careful about order of application
... and origin setting
... so this is more what the origin should be for a specified motion path use should be
... I think the simplest thing to do is make it the same as transform-origin
... if you're generating equivalent behaviour for <animateMotion>, you might need to fiddle with some translations

krit: I think we will state this usse on the mailing list again
... but here we just want to note all the open issues

shane: in the absence of significant discussion, I would say transform-origin we should proceed with
... given this is the only substantive issue, I am asking whether we should we can have a FPWD of motion animation

RESOLUTION: We agree on a FPWD of Motion Path Module Level 1.

-- adjourn for real --

RRSAgent: make minutes

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/prens/parens/
Succeeded: s/Porilfe/Profile/
Succeeded: s/SVG//
Succeeded: s/Tav/jet/
Succeeded: s/.../Tav/
Succeeded: s/.../Tav/
Succeeded: s/fine/fine with it/
Succeeded: s/taht/that/
Succeeded: s/masking.html, issue 3/masking.html, issue 2/
Succeeded: s/Rossen/Rossen:/
FAILED: s/Rossen,/Rossen:/
Succeeded: s/Rossen,/Rossen:/
Succeeded: s/What about ICC?/will icc-color be part of the <color> grammar in css?/
Succeeded: s/with/width/
Succeeded: s/RESOLVE:/RESOLUTION:/
Succeeded: s/birtles: what about variable stroke width?/someone: what about variable stroke width?/
Succeeded: s/dagshin/dashing/
Succeeded: s/taht/that/
Succeeded: s/use/<use>/
Succeeded: s/(Tav)/TabAtkins/
Succeeded: s/Interactivity/Embedded content/
Found Scribe: Cameron
Found ScribeNick: heycam
Found ScribeNick: ed
Found Scribe: Nikos
Inferring ScribeNick: nikos
Found ScribeNick: nikos
Found Scribe: tav
Inferring ScribeNick: Tav
Found ScribeNick: Tav
Found Scribe: Cameron
Found ScribeNick: heycam
Found Scribe: Tav
Inferring ScribeNick: Tav
Found ScribeNick: Tav
Found Scribe: Cameron
Found ScribeNick: heycam
Found Scribe: BogdanBrinza
Inferring ScribeNick: BogdanBrinza
Found ScribeNick: BogdanBrinza
Found Scribe: Cameron
Found ScribeNick: heycam
Scribes: Cameron, Nikos, tav, BogdanBrinza
ScribeNicks: heycam, ed, nikos, Tav, BogdanBrinza
Default Present: +61.2.933.6.aaaa, Doug_Schepers
Present: +61.2.933.6.aaaa Doug_Schepers

WARNING: Fewer than 3 people found for Present list!

Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Agenda_proposals
WARNING: Date not understood: Fri Feb 13 22:13:02 2015 +1100
Got date from IRC log name: 12 Feb 2015
Guessing minutes URL: http://www.w3.org/2015/02/12-svg-minutes.html
People with action items: brian cameron cyril ed heycam jean-claude krit tabatkins tav