21:49:27 <RRSAgent> RRSAgent has joined #svg
21:49:27 <RRSAgent> logging to http://www.w3.org/2015/02/12-svg-irc
21:49:47 <ed> RRSAgent, stay
21:50:03 <ed> rrsagent, this meeting spans midnight
21:50:10 <ed> RRSAgent, make logs public
21:50:51 <ed> Meeting: SVG WG Sydney F2F 2015, day 2
21:50:57 <ed> chair: ed
21:51:00 <roc> roc has joined #svg
21:51:17 <ed> Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Agenda_proposals
21:53:35 <tantek> tantek has joined #svg
22:09:02 <stakagi> stakagi has joined #svg
22:11:08 <heycam> Scribe: Cameron
22:11:10 <heycam> ScribeNick: heycam
22:12:04 <heycam> Topic: superpath
22:12:14 <cyril> cyril has joined #svg
22:14:20 <BogdanBrinza> BogdanBrinza has joined #svg
22:14:52 <cyril> http://moissinac.github.io/SuperPath/
22:15:07 <heycam> cyril: my colleague has been working on this superpath prototype
22:15:25 <heycam> ... the idea is that in many graphics, you need to share paths or pieces of paths among bigger paths
22:15:42 <heycam> ... for example you need to share them if you have regions in a map, share them sometimes in direct order, sometimes in reverse order
22:15:47 <heycam> ... so the idea is to reuse a piece of a path in another path
22:15:56 <Tav> Tav has joined #svg
22:16:05 <heycam> ... benefits in reducing file size, but also more semantically correct content. not duplicating information when not needed.
22:16:13 <heycam> ... viewers could do better antialiasing on that path, it's only present once
22:16:22 <heycam> ... it could be rendered seamless
22:16:38 <heycam> ... 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
22:16:51 <heycam> ... after some investigation we realised that it's very hard to extract a piece of a path and make it a separate path alone
22:16:56 <heycam> ... because what command would you put at the front
22:17:05 <heycam> ... the geometry of the path often depends on the point before or the point after
22:17:36 <heycam> ... so we changed our idea here ab it
22:17:53 <heycam> ... nikos suggested instead of having the reusable path a separate path, define it while using it in the first place
22:17:57 <heycam> ... so you have the full context
22:18:11 <heycam> ... 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
22:18:19 <heycam> Tav: that's clear, but not sure if it's necessary
22:18:28 <heycam> cyril: you can see some examples on this page
22:18:33 <heycam> ... don't pay much attention to the syntax yet
22:18:41 <jet> jet has joined #svg
22:18:53 <heycam> ... my colleague is happy to change the syntax, it's just a prototype
22:19:02 <cyril>  d="M 90,190 220,90 330,150 (p1|L330,150 280,230 L330,310 280,400)L120,375 z"
22:19:13 <heycam> ... this is an example of syntax; the path you will be reusing is between prens
22:19:15 <heycam> s/prens/parens/
22:19:23 <heycam> ... the ID is the thing after the open paren, and it ends with the bar
22:19:34 <heycam> ... when you want to reuse it
22:19:35 <cyril> d="M 500,385 390,460 280,400!p1|L450,50 565,81 z"
22:19:50 <heycam> ... that's a reverse use
22:19:56 <heycam> ... and I think the prototype uses # for forward use
22:20:09 <cyril> http://moissinac.github.io/SuperPath/Samples/piece01withExternalScript.svg
22:20:24 <heycam> ... there's a more complex example with a map
22:20:24 <AmeliaBR_> AmeliaBR_ has joined #svg
22:20:29 <cyril> http://moissinac.github.io/SuperPath/Samples/bretagneSuperPath.svg
22:20:50 <heycam> ... this is a region of france with three subregions
22:20:55 <heycam> ... the blue path for the sea
22:21:18 <heycam> ... as I said, the syntax is probably not the best
22:21:25 <heycam> ... but the big change is the path is defined inline
22:21:28 <heycam> ... when it's first used
22:21:32 <heycam> ... to have the full context
22:21:37 <heycam> ... what is preserved is the geometry
22:21:51 <heycam> ... what he does is any path used is converted to a path that has relative commands, so it's easier to reverse
22:21:56 <heycam> ... then the reversed relative commands are applied
22:22:12 <heycam> ... the next step for us is to fix the syntax, then have it run on many examples
22:22:24 <heycam> ... JC is writing a program to analyse existing content and replace duplicated paths with this
22:22:49 <heycam> ... when the content has been authored and the paths don't exactly match, e.g. with slightly different floating point values
22:23:12 <heycam> Tav: in inkscape you can output in relative or absolute
22:23:17 <heycam> ... I want to talk about auto closing a path
22:23:23 <heycam> ... with a rounded segment
22:23:42 <heycam> ... so you'd leave out the first point, then put the first point in the path
22:23:58 <heycam> nikos: it wasn't to do with smooth curve final segments was it?
22:24:55 <heycam> Tav: it helps with positioning the marker
22:25:01 <heycam> heycam: so that's a mid marker
22:25:11 <heycam> Tav: and makes the orientation expected
22:25:22 <jun> jun has joined #svg
22:25:46 <heycam> cyril: what does the group think of defining the reusable path name in the path data?
22:26:38 <heycam> krit: how do we handle compatibility?
22:26:58 <heycam> cyril: for the path that defines the reusable path, it you could skip the ID then it could render
22:27:08 <heycam> ... the path that reuses it you couldn't really do anything
22:27:29 <rossen_syd> rossen_syd has joined #svg
22:27:39 <heycam> Tav: now you define a country, as one path, and a region in that would be the path that you share?
22:27:52 <heycam> 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
22:28:11 <heycam> ... 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
22:28:21 <heycam> Tav: I find that conceptually more complicated than defining each subpath separately
22:28:30 <heycam> nikos: you could define all the subpaths in defs
22:28:38 <heycam> ... and then you only need to reference it because you want to fill it
22:29:38 <heycam> 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
22:29:47 <heycam> ed: can you get a continuous curve with reused subpaths?
22:29:49 <heycam> cyril: yes
22:29:59 <heycam> ed: it's a similar problem to the autoclosing command
22:30:31 <heycam> ed: also wondering with this proposed syntax, is it possible to have nested reusable subpaths?
22:30:50 <heycam> cyril: I haven't tested that, I guess the prototype doesn't accept that
22:31:16 <heycam> ... but in theory it could work
22:31:49 <heycam> ... 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
22:32:00 <heycam> ... there's a possibiltiy you need to process the whole file before doing anything
22:32:10 <heycam> ... there's also the possibility of doing loops
22:32:21 <heycam> Tav: don't we have some rules for dealing with that already
22:32:24 <heycam> ed: yes for ID cycles
22:32:29 <heycam> cyril: so that would need to be specified
22:33:38 <heycam> heycam: bit uneasy about defining the names in the path data
22:33:41 <heycam> ... seems odd
22:33:54 <heycam> birtles: if I add the get-path-data-as-floats API, how would this work?
22:34:00 <heycam> cyril: it would return the expanded path
22:34:06 <heycam> ... animation is also an open issue
22:34:49 <heycam> cyril: I don't know how it can be implemented in browsers
22:34:52 <heycam> ... polyfilling is easy
22:36:20 <heycam> heycam: we wouldn't do the seamless rendering first, that would need lots of graphics library rewriting
22:36:40 <heycam> cyril: I don't think I need a resolution or an action, but if anyone is willing to help/test
22:36:46 <heycam> ... e.g. prototype in inkscape
22:36:54 <heycam> Tav: I'd like to but have enough other prototypes to work on for now
22:38:34 <heycam> ACTION: jean-claude to further develop the protoype including with animation support
22:38:35 <trackbot> Created ACTION-3734 - Further develop the protoype including with animation support [on Jean-Claude Moissinac - due 2015-02-19].
22:38:55 <heycam> Topic: optimizing for machine generation
22:39:53 <heycam> jet: I wanted to talk to the group about some implementation experience that I've had
22:39:55 <heycam> ... recently and in the past
22:40:02 <heycam> ... at Mozilla we recently implemented a flash player in JS
22:40:06 <heycam> ... and just deployed it in nightly Firefox builds
22:40:21 <cyril> RRSAgent, meeting spans midnight
22:40:23 <heycam> ... previously I worked at Adobe on the flash player
22:40:28 <cyril> RRSAgent, draft minutes
22:40:28 <RRSAgent> I have made the request to generate http://www.w3.org/2015/02/12-svg-minutes.html cyril
22:40:29 <heycam> ... before that at Macromedia on the flash authoring tool
22:40:40 <heycam> ... at Macromedia, Adobe was building their LiveMotion authoring tool
22:40:54 <heycam> ... I wanted to share with the group some of why flash got the ubiquity it did and Adobe's SVG didn't
22:41:06 <heycam> ... 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
22:41:13 <heycam> ... I think there's an opportunity to get past that after all this years
22:41:23 <heycam> ... and move interactive animations on the web in a way that SVG could not at the time
22:41:39 <heycam> ... the things that made it get over that hump at the time, weren't the things you'd expect
22:41:51 <heycam> ... Adobe's authoring tool was good, had a reputation for quality software, plugin worked in many places
22:42:09 <heycam> ... but when we would evanglize Flash over SVG, we'd demo with the worst browsers with SVG, and the best browser with Flash
22:42:35 <heycam> ... one company in particular the Flash developers went to at the time was Disney
22:42:50 <heycam> ... experts in animation, decided to use Flash on the front page of their site
22:43:05 <heycam> ... at the time, if you wanted to use animation you'd use GIF89, and there wasn't really anything else
22:43:14 <heycam> ... this is the era of 9600 baud modems and 386 computers
22:43:27 <heycam> ... today, the hardware is better, but similar network issues
22:43:50 <heycam> ... the things that made Flash successful was bug compatibility across browsers, and performance characteristics that were consistent across browsers
22:44:06 <heycam> ... for example Flash had retained mode API, binary file format
22:44:09 <heycam> ... small, fast, compiled
22:44:40 <heycam> ... 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)
22:44:58 <heycam> ... what I'm getting at is that SVG is an excellent authoring format, but a poor runtime format
22:45:18 <heycam> ... 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
22:45:35 <heycam> ... an example: coons patches, flash doesn't support that; nor gradient meshes
22:45:48 <heycam> ... but you can build a gradient mesh in the authoring tool and it spits out a bitmap under the covers
22:46:06 <heycam> ... 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
22:46:23 <heycam> ... so what I'd like to get from the SVG group to see if there's an appetite to fix that
22:46:48 <heycam> ... 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
22:47:09 <heycam> ... 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
22:47:25 <heycam> krit: it sounds a bit like the Basic SVG Porilfe
22:47:29 <heycam> s/Porilfe/Profile/
22:47:34 <heycam> jet: SVG is one facet of it
22:47:41 <heycam> ... vector art and animation, and interactivity
22:47:53 <heycam> ... the part that made Flash also be ubiquitous is that its OM was very contained and strict
22:48:08 <heycam> ... you wouldn't expect that the HTML hosting your Flash file could mess with the Flash OM
22:48:12 <heycam> ... so maybe a basic profile of SVG?
22:48:43 <heycam> ... today, we implemented flash in SVG/canvas
22:48:50 <heycam> s/SVG//
22:49:00 <heycam> ... something similar to the React Canvas
22:49:08 <heycam> ... implementing flash in JS/canvas
22:49:17 <Rossen> Rossen has joined #svg
22:49:35 <heycam> ... SVG is so rich and powerful that I think it's better suited as an authoring format than a runtime one
22:49:46 <heycam> ... if we could design a subset that is a subset that has clear DOM semantics
22:49:57 <heycam> ... that the runtime can then make decisions about rasterising etc.
22:50:33 <heycam> ... that's the spiel, don't have concrete ideas
22:51:10 <heycam> heycam: are you coming from the perspective of trying to implement Flash in SVG, and the performance wasn't there?
22:51:37 <heycam> Tav: not all performance, but also different rendering model
22:51:40 <heycam> s/Tav/jet/
22:51:48 <heycam> jet: we also have an ad use case
22:51:56 <heycam> ... flash can bundle things up in a package neatly
22:52:05 <heycam> ChrisL: sounds like you're asking for a package format
22:52:11 <heycam> ... which travels in one unit
22:52:16 <heycam> ... or can play without being unpacked
22:52:23 <heycam> jet: yes, that's one way. maybe it is a zip container.
22:52:40 <heycam> ... there are things that made flash as a tagged binary file format, in the order of use
22:52:50 <heycam> ... you know before you use an element that you would've pushed it through the network
22:53:00 <heycam> ... the packaged file fromat like jar files, you have to get the whole blob before you can start
22:53:10 <heycam> cyril: the work I presented yesterday uses mp4 container rather than zip
22:53:13 <heycam> ... which can be used for streaming
22:53:27 <heycam> ... to come back to the earlier statement, I agree that design of Flash was very different
22:53:32 <heycam> ... authoring format, and publication format
22:53:39 <heycam> ... SVG is completely different in that the authoring format is the publication format
22:53:43 <heycam> ... so the tradeoffs are different
22:53:52 <heycam> ... performance and compact model is not the same
22:53:59 <heycam> ... that's a benefit but also a problem for optimisation
22:54:09 <heycam> ... looking at converting cartoons to SVG, there are thousands of ways of doing it
22:54:14 <heycam> ... so it's hard to optimise
22:54:20 <heycam> ... there are so many ways to do the same thing
22:54:26 <heycam> jet: for an authoring format, that's great
22:54:32 <heycam> ... flash was an authoring tool before it was a runtime format
22:54:48 <heycam> ... the compile-to-runtime was an artifact of having to send things over slow networks
22:55:22 <heycam> ... the answer I get to asking people why they're still writing flash, games/ads/etc., is both (a) these issues and (b) tooling
22:55:57 <heycam> ... 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
22:56:07 <heycam> Rossen: I heard you mention a few times offering a subset
22:56:11 <heycam> ... and also guaranteeing interop
22:56:20 <heycam> ... I think we can all agree on how to spec a subset
22:56:28 <heycam> ... I don't know about guaranteeing interop
22:56:32 <heycam> ... it's what we all try to do
22:56:36 <heycam> ... but how do you guarantee it?
22:56:45 <heycam> jet: I think that opens us up to the same disadvantages
22:56:54 <heycam> Rossen: here's one way to go
22:57:13 <heycam> ... 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
22:57:19 <heycam> ... that's the only way I can see that it's interoperable always
22:57:47 <heycam> ... going back for a second, you're mentioning a subset
22:57:49 <heycam> ... do you have an idea?
22:57:56 <heycam> jet: I say subset just so it would be surmountable problem
22:58:10 <heycam> ... if we say basic shapes are required and then pixel perfect requirements
22:58:17 <heycam> ... because that's a simple problem
22:58:34 <heycam> ChrisL: last meeting we tried to decide "is a geometry coordinate at the top/left of a pixel, or middle of a pixel"
22:58:51 <heycam> ... and we couldn't agree, because different graphics libraries are different
22:59:07 <heycam> ... one reason Flash was successul was that there was one implementation (that mattered)
22:59:15 <heycam> ... and that the implementation is basically the spec
22:59:22 <heycam> jet: so we implemented Flash using JS/canvas
22:59:30 <heycam> ... that it was possible is somethign taht got me thinking
22:59:46 <heycam> ... 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?
23:00:25 <heycam> ... 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
23:00:51 <heycam> ... couldn't we polyfill a format other than flash, perhaps a subset of svg?
23:00:56 <heycam> ... I'd like to build on things already in the web platform
23:01:13 <heycam> 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
23:01:34 <heycam> 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
23:01:40 <heycam> cyril: I doubt you'd have good performance there though
23:01:53 <heycam> Rossen: I'm still thinking you're talking about two different things here
23:02:22 <heycam> ... 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
23:02:29 <heycam> ... so that they become part of the native packaged platform
23:02:47 <Zakim> Zakim has joined #svg
23:02:51 <heycam> Zakim, room for 4?
23:02:52 <Zakim> ok, heycam; conference Team_(svg)23:02Z scheduled with code 26631 (CONF1) for 60 minutes until 0002Z
23:03:48 <Zakim> Team_(svg)23:02Z has now started
23:03:56 <Zakim> + +61.2.933.6.aaaa
23:04:37 <heycam> ChrisL: [tooling]
23:04:48 <heycam> ... the other reason I have Flash installed on my machine is that I like to watch video
23:04:52 <Zakim> +Doug_Schepers
23:04:54 <heycam> krit: content protection
23:05:05 <heycam> jet: we're solving the video problems another way, I think we'll get there
23:05:15 <heycam> ... the use cases are the ones I'd like to cover are ads, 2D games
23:05:26 <heycam> ... the people who makes those games/ads in Flash, is that SVG implementations are fragile
23:05:42 <heycam> ... 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
23:05:47 <heycam> Rossen: I think everything that we publish is normative
23:06:01 <heycam> ... in order to get interop you either have to converge on a single implementation, or just pray
23:06:14 <heycam> cyril: if you subset SVG, in some sense you don't have 10 ways to do the same thing
23:06:17 <heycam> ... you can optimise that
23:06:20 <heycam> Rossen: example?
23:06:28 <heycam> krit: asm.js
23:06:44 <heycam> cyril: how do you frame based animation in SVG?
23:06:47 <heycam> Rossen: what is it today?
23:06:52 <heycam> cyril: you can use display, visibility, opacity
23:07:02 <heycam> ... Brian just exposed yesterday all the challenges if you want to optimise your animation
23:07:09 <heycam> ... there are several ways, will-change, transfromZ
23:07:14 <heycam> Rossen: let's go back to SVG
23:07:25 <heycam> ... from the SVG spec, tell me what is exposed is ambiguous and can be implemented in many ways
23:07:55 <heycam> ... 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
23:08:20 <heycam> ... I'd still like to figure out the problem for SVG
23:08:31 <heycam> ChrisL: I'd like to see detail on what they find is fragile
23:08:56 <heycam> roc: do people demand exact rasterisation consistency on all targets? or are they more concerned about performance consistency?
23:08:58 <heycam> ... or other things?
23:09:03 <heycam> jet: it was consistency across targets
23:09:09 <heycam> roc: rasterisation consistency?
23:09:32 <heycam> jet: that, performance, ...
23:10:03 <heycam> ... we built a Flash renderer in JS, could this be a SVG renderer
23:10:20 <heycam> Rossen: what does versioning look like in this case?
23:10:40 <heycam> ... 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
23:10:50 <heycam> ... there's always a first to market, and others following
23:11:03 <heycam> ... are you going to hold everything back so that nobody jumps the gun and releases a feature?
23:11:20 <heycam> ... I think we build new features so that you have graceful progression
23:11:37 <heycam> ... and that comes back to the single implementation
23:11:59 <heycam> 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?
23:12:22 <heycam> 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
23:12:30 <heycam> roc: they're finding canvas more consistent then
23:12:45 <heycam> roc: you could have authoring tools produce canvas and JS
23:12:45 <heycam> ... and compile down to that level
23:12:47 <heycam> ... if you do that I think everyone gets what they want
23:13:02 <heycam> jet: there's something amiss there, then you have to implement the playback engine
23:13:09 <tantek> tantek has joined #svg
23:13:11 <heycam> roc: you can customise that engine right down to exactly what the ad needs
23:13:23 <heycam> ... you won't need most of the features that Shumway has
23:13:40 <heycam> ... I don't know how small we can make that, but I think for a lot of ads we can make it pretty small
23:13:47 <heycam> jet: is that something we could standardise?
23:13:56 <heycam> roc: we wouldn't need to, which is why it'd be a great solution
23:14:06 <heycam> ... in standards, we could look at making canvas rendering consistent
23:14:13 <heycam> ... as canvas is more focused than svg is
23:14:23 <heycam> cyril: what's the scalability of canvas?
23:14:29 <heycam> ChrisL: well it's immediate mode
23:14:34 <heycam> roc: that's a problem that canvas-using apps already have
23:14:39 <heycam> ... there's a couple of pieces to solving that
23:14:50 <heycam> ... we have consensus on solving that; there's an event that first when canvas needs to be re-rendered
23:14:56 <heycam> ... and an application listens for that event and rerender
23:15:06 <heycam> ... and we need a way for the app to size the backing store to device pixels
23:15:17 <heycam> ... which is a renderedWidth/Height property on the canvas
23:15:37 <heycam> jet: then maybe all we have missing is the packaging side
23:15:54 <heycam> roc: you might be able to design your ad such that --- well you have image assets etc.
23:16:02 <heycam> ... there have been several proposals for zip-like but streamable bundles
23:16:26 <heycam> ... (you can make zip streamable if you format it correctly iirc)
23:16:37 <heycam> ... I'm not sure why they didn't go anyway
23:16:43 <heycam> ... maybe the use cases weren't compelling enough?
23:16:52 <heycam> ... some people were trying to do it as a performance thing in a single HTTP transaction
23:16:55 <heycam> ... but then SPDY came along
23:17:04 <heycam> ... so for speeding up website loading that solved it
23:17:16 <heycam> ... but for this problem of content traversing multiple networks was not really thought of as a use case
23:17:27 <heycam> ... technically it's not a mysterious problem
23:17:35 <heycam> cyril: you should look at the SVG streaming spec; it's still a draft, but it might help you
23:18:03 <heycam> heycam: marcos will know about packaging
23:18:15 <heycam> roc: if we could re-use this new app packaging format that might be a solution
23:18:19 <heycam> cyril: my recollection is that it wasn't streamable
23:18:51 <Tav> http://tavmjong.free.fr/SVG/MITER_LIMIT/index.html
23:18:57 <heycam> Topic: Miter line join
23:19:11 <cyril> https://github.com/w3ctag/packaging-on-the-web
23:19:20 <heycam> jet ^ (packaging)
23:19:33 <heycam> Tav: people were asking for a different type of miter
23:20:04 <heycam> ... instead of clipping at a certain point, when you reach the limit, you get a uniform clipping
23:20:20 <heycam> ChrisL: the existing one is discontinuous
23:20:24 <heycam> krit: in canvas, what do we do there?
23:20:28 <heycam> ... do we do the second one?
23:21:17 <heycam> Tav: the guy from nvidia (not neil) said that half graphics engines do it one way, half do the other
23:21:26 <heycam> ... the lower one is existing behaviour in some engines?
23:21:33 <heycam> roc: we just use the underlying graphics libraries
23:21:39 <heycam> ... so I'm sure it would be different on different platforms
23:21:58 <krit> https://developer.mozilla.org/samples/canvas-tutorial/4_8_canvas_miterlimit.html
23:21:59 <heycam> krit: I think different platforms do align
23:22:22 <heycam> ... the proposal is to have a fourth (well, we have 'arcs')
23:22:45 <heycam> ... so if you're already doing something to implement arcs (i.e. not solely relying on existing libraries), then implementing this proposal is trivial
23:22:53 <heycam> s/.../Tav/
23:22:53 <heycam> s/.../Tav/
23:23:00 <heycam> ChrisL: a new value would be good
23:23:30 <heycam> Tav: I've played with the cairo line join code
23:23:35 <heycam> ... and doing this is trivial
23:23:44 <heycam> krit: does it work cross platform? cairo uses CoreGraphics on OS X.
23:23:53 <heycam> roc: so the image rasteriser, not the other backends
23:24:16 <cyril> zakim, who's on the phone ?
23:24:16 <Zakim> On the phone I see +61.2.933.6.aaaa, Doug_Schepers
23:24:34 <roc> cyril: in what way is http://w3ctag.github.io/packaging-on-the-web/#streamable-package-format not streamable?
23:26:16 <roc> shepazu: can you hear us?
23:26:41 <heycam> ed: the proposal is?
23:26:48 <heycam> krit: a new value that has this behaviour
23:27:32 <heycam> Rossen: are you proposing an interpolation function that goes between these things?
23:27:39 <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.
23:27:45 <heycam> Tav: no just clip the miter rather than fall back to the other point
23:27:46 <roc> ah
23:28:13 <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"
23:28:50 <cyril> roc: there are use cases for adaptive streaming of ads as well
23:28:53 <heycam> ChrisL: so you're using a line cap which never triggers miter-limit
23:29:00 <heycam> ... the numerical value for miter-limit wouldn't affect it?
23:29:02 <heycam> Tav: it would
23:29:19 <heycam> ChrisL: you're looking for a line-join keyword?
23:29:37 <cyril> roc: mp4 being ubiquitous in all browser, I think it's a candidate that shouldn't be dropped without investigation
23:29:42 <roc> cyril: maybe, but I think you can't have adaptive streaming and a single inviolable package.
23:29:51 <heycam> ChrisL: miter-clip
23:30:34 <Zakim> -Doug_Schepers
23:30:50 <cyril> cyril: still controlled/timed delivery of big packages is interesting too
23:31:31 <cyril> roc: still controlled/timed delivery of big packages is interesting too
23:33:01 <heycam> RESOLUTION: We will add line-join:miter-clip in SVG 2.
23:33:09 <heycam> ACTION: Tav to add line-join:miter-clip to SVG 2.
23:33:10 <trackbot> Created ACTION-3735 - Add line-join:miter-clip to svg 2. [on Tavmjong Bah - due 2015-02-19].
23:33:21 <heycam> -- 15 min break --
23:33:24 <ChrisL> ChrisL has joined #svg
23:33:55 <jdaggett> jdaggett has joined #svg
23:48:06 <jdaggett_> jdaggett_ has joined #svg
23:54:09 <tantek> tantek has joined #svg
23:56:52 <heycam> Topic: auto closing path closing
23:57:09 <Tav> http://tavmjong.free.fr/SVG/AUTO_PATH_CLOSING/index.html
23:57:32 <heycam> Tav: there are problems when you have a curved segment at the begin/end of a path
23:57:40 <heycam> ... in that in order to close the path you have to have a 0-length z
23:57:47 <heycam> ... that causes problems with how markers are rendered
23:57:55 <heycam> ... there are inconsistencies with how browsers handle them
23:58:10 <heycam> ... if you paste that link in 2 different browsers, compare the rendering, you'll see that they're inconsistent
23:58:28 <heycam> ... 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
23:58:35 <heycam> ... would be nice to have a way that specifies they should match up
23:58:44 <heycam> ... some possible solutions on how to do that
23:58:52 <heycam> ... one possibility is new commands
23:59:03 <heycam> ... the Z command is essentially an L command, where the point is the first point
23:59:20 <heycam> ... so you could extend that, but I don't think it's good to extend Z_a or whatever
23:59:28 <heycam> ... you could use a non-numerical parameter
23:59:33 <heycam> ... which means "use the first point"
23:59:45 <heycam> ... you could use a Z to indicate that you should replace a missing point with the first point in the path
23:59:52 <heycam> ... so either the second or third solution would be a way of doing it
00:00:31 <heycam> heycam: would you accept this special symbol anywhere in the path?
00:00:42 <heycam> Tav: maybe but it wouldn't be as useful
00:00:52 <heycam> heycam: makes me wonder if you would want to go back to any point, not just the first point
00:01:34 <heycam> 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?
00:02:11 <heycam> heycam: I think we covered the marker direction issue a couple of weeks ago
00:03:16 <heycam> cyril: the whole problem comes from rounding errors, right?
00:04:09 <BogdanBrinza_> BogdanBrinza_ has joined #svg
00:04:17 <heycam> Tav: yes
00:04:39 <heycam> nikos: even ignoring precision issues, having a Z command that closes a bezier is useful anyway
00:04:55 <heycam> ... you could expand the meaning of Z to mean "close a path and create a segment if it needs to"
00:05:27 <heycam> heycam: that's the third option
00:06:24 <heycam> nikos: what if in an arc command you omitted the flag values and put a z there
00:06:51 <heycam> heycam: I think just make that invalid
00:07:00 <Zakim> disconnecting the lone participant, +61.2.933.6.aaaa, in Team_(svg)23:02Z
00:07:03 <Zakim> Team_(svg)23:02Z has ended
00:07:03 <Zakim> Attendees were +61.2.933.6.aaaa, Doug_Schepers
00:07:31 <heycam> RESOLUTION: We will allow a Z to fill in any final coordinate pairs missing from the previous command.
00:07:46 <heycam> ACTION: Tav to add the new Z behaviour.
00:07:46 <trackbot> Created ACTION-3736 - Add the new z behaviour. [on Tavmjong Bah - due 2015-02-20].
00:08:05 <Tav> http://tavmjong.free.fr/SVG/TEXT_ON_A_SHAPE/index.html
00:08:11 <heycam> Topic: Text on a shape
00:08:51 <heycam> Tav: inkscape originally drew ellipses/circles with paths
00:09:20 <heycam> ... some people noticed they could no longer put text along a circle
00:09:35 <heycam> ... because it's a common thing to do, it was proposed that we allow text on shapes
00:09:49 <heycam> ... in inkscape this is easy to do, because at the time we disply we've already converted the shape to a path
00:10:06 <heycam> ... the major issues have already been solved, such as the start point on a circle, because we had to define that using markers
00:10:12 <heycam> heycam: and dashing
00:10:18 <heycam> Tav: there are a couple of challenges
00:10:31 <heycam> ... if you put text on a circle it might make sense to use a negative startOffset
00:10:37 <heycam> ... how do you put text on the other side
00:11:17 <heycam> ... we could have a flag to say which way the text goes
00:12:01 <heycam> heycam: sounds fine
00:12:41 <heycam> heycam: what about the flag?
00:12:51 <heycam> ChrisL: what would the names be? inside/outside? left/right?
00:12:54 <heycam> Tav: left/right
00:13:00 <heycam> ChrisL: as long as you have a good definition
00:13:24 <heycam> roc: clockwise/anticlockwise?
00:14:01 <cyril> RRSAgent, draft minutes
00:14:01 <RRSAgent> I have made the request to generate http://www.w3.org/2015/02/12-svg-minutes.html cyril
00:14:31 <heycam> roc: mapping people use "true left" of a river, left when moving downstream
00:14:50 <heycam> Tav: how about negative startOffset?
00:15:43 <heycam> heycam: negative startOffset is already allowed, but we probably don't define what happens with closed subpaths
00:16:37 <heycam> RESOLUTION: We will allow <textPath> to reference shapes and a flag to say which side of the path the text is put.
00:16:47 <heycam> ACTION: Tav to update textPath for text on a shape.
00:16:48 <trackbot> Created ACTION-3737 - Update textpath for text on a shape. [on Tavmjong Bah - due 2015-02-20].
00:17:05 <heycam> Topic: x/y/width/height on <symbol>
00:17:17 <heycam> Tav: this is an issue I came across
00:18:04 <Tav> http://tavmjong.free.fr/SVG/viewport.svg
00:18:21 <heycam> Tav: Opera Presto and Inkscape you see no red boxes
00:18:29 <heycam> ChrisL: and red is bad right?
00:19:04 <heycam> Tav: it means x/y/width/height are being interpreted when the spec says they shouldn't be
00:19:20 <heycam> cyril: Firefox/Chrome behave the same
00:19:40 <ChrisL> IE11 is correct
00:20:17 <heycam> Tav: Batik does it wrong, and probably everyone assumed Batik does it right
00:20:48 <heycam> Tav: so I don't think following those attributes is useful
00:20:53 <heycam> ... I think the spec should be followed in this case
00:23:57 <heycam> roc: I suspect those attributes got cloned onto the <svg> and they're being interpreted in place
00:24:26 <heycam> ... so maybe we should add them for consistency with referencing <svg>?
00:24:57 <heycam> ChrisL: is it fully defined what it means, if we removed that rule from the spec?
00:25:10 <heycam> ... given that nested <svg>s already allow this
00:25:55 <heycam> Rossen: I don't want to change
00:26:38 <heycam> ChrisL: the reason I changed was that we added x/y to <svg>, and now referencing it is different from referencing <symbol>
00:27:32 <heycam> 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.
00:27:41 <heycam> krit: does <symbol> have viewBox?
00:27:44 <heycam> Tav: yes
00:27:49 <heycam> krit: then I'm starting to agree with roc
00:28:38 <shepazu> +1 to roc's proposal... we should do the same for <marker>, etc.
00:29:09 <heycam> ed: if you have width/height on the <use> it will override the ones on the cloned tree
00:29:15 <heycam> Rossen: and that makes sense
00:29:24 <heycam> roc: this is not an argument for making symbol behave differently though
00:29:32 <heycam> Tav: it's only used by a <use> element
00:31:43 <stakagi_> stakagi_ has joined #svg
00:33:02 <heycam> RRSAgent, pointer?
00:33:02 <RRSAgent> See http://www.w3.org/2015/02/12-svg-irc#T00-33-02
00:33:12 <heycam> ed: I think you'll still get the same behaviour if you default width/height on <symbol> to 100%
00:33:18 <heycam> ... so if we did that I'd be fine
00:33:21 <heycam> s/fine/fine with it/
00:33:46 <heycam> krit: what happens now that x/y are properties?
00:34:34 <stakagi__> stakagi__ has joined #svg
00:35:40 <heycam> Rossen: what is the main use case here that would be broken if we don't do this?
00:35:50 <heycam> Tav: if someone has incorrectly put x/y/width/height
00:35:57 <heycam> ... some browsers have ignored it, others have not
00:36:23 <heycam> Rossen: what would be the expected behaviour or use that comes out from tooling?
00:36:30 <heycam> ... what would be more natual for tooling to output for this?
00:36:45 <heycam> ... when you're using <use>, I would expect tooling would probably define x/y/width/height on the <use>
00:37:42 <heycam> heycam: so I agree that x/y on <symbol> is not useful
00:37:57 <heycam> ... but the argument would be consistency with referencing <svg>
00:38:08 <heycam> krit: it's an edge case, I don't think content would be relying on this behaviour
00:38:18 <heycam> Rossen: what would be the most natural thing from the author's point of view?
00:38:27 <heycam> ... in either case the code change would be straightfowrard
00:38:32 <heycam> ... I want to know what the effect for users would be
00:38:56 <heycam> krit: <symbol width height> and <use x y> without width/height, that would be useful to avoid duplicating width/height all the time
00:39:11 <heycam> ... I think there is an argument to simplify the code
00:39:19 <heycam> ... by treating these the same
00:39:27 <heycam> ... the user could live with specifying width/height on <use>
00:39:40 <heycam> dmitry: it looks more to be a bug in the spec rather than the browsers
00:39:53 <heycam> ... as an author, I would expect x/y/width/height to be available on <symbol>
00:39:58 <heycam> ... it's not a big deal
00:40:40 <heycam> 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
00:40:47 <heycam> ... it does mean sometimes you need to display all four quadrants
00:40:51 <heycam> ... and there are some issues with clipping
00:41:04 <heycam> ... some people would rather specify the middle rather than 0,0
00:41:11 <heycam> Tav: well we now have refX/refY on symbol, to match marker
00:42:04 <heycam> Rossen: what would users want/say
00:42:10 <heycam> roc: I don't think users are necessarily going to use this
00:42:50 <heycam> ... do we change the spec to make things things more consistent
00:43:54 <pdr__> cyril asked me to confirm that swiffy has indeed switched to canvas
00:44:17 <heycam> ed: send a mail to www-svg asking for feedback, wait two weeks, decide then?
00:44:19 <heycam> Rossen: sounds reasonable
00:44:42 <heycam> ACTION: Tav to mail www-svg about the symbol x/y/width/height issue and report back in two weeks
00:44:42 <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].
00:46:06 <cyril> zakim, pick a victim
00:46:06 <Zakim> sorry, cyril, I don't know what conference this is
00:46:16 <ChrisL> zakim, this will be svg
00:46:16 <Zakim> I do not see a conference matching that name scheduled within the next hour, ChrisL
00:46:21 <cyril> zakim, this is SVG
00:46:21 <Zakim> sorry, cyril, I do not see a conference named 'SVG' in progress or scheduled at this time
00:46:28 <cyril> zakim, go to hell
00:46:28 <Zakim> I don't understand 'go to hell', cyril
00:46:43 <ed> scribeNick: ed
00:46:44 <ChrisL> zakim, pick a victim !important
00:46:44 <Zakim> I don't understand 'pick a victim !important', ChrisL
00:46:46 <shane> Zakim, cyril is a meanie
00:46:46 <Zakim> I don't understand 'cyril is a meanie', shane
00:47:08 <ed> topic: svg2 issues
00:47:20 <heycam> https://svgwg.org/svg2-draft/layout.html
00:47:26 <botie> botie has joined #svg
00:47:38 <ed> heycam: this is the chapter for x,y,cx,cy and so on properties
00:47:48 <ChrisL> botie, tell cyril he was mean to zakim
00:47:48 <botie> ChrisL: excuse me?
00:47:53 <ed> ... issue 1: need to check the initial values for all of them
00:48:10 <ed> krit: r has different initial values for gradients and circle
00:48:18 <ed> ... propose to make it 'auto'
00:48:31 <ed> ... to make it work out the correct value depending on element
00:48:48 <ed> heycam: is this done with UA styles?
00:49:04 <ed> TabAtkins: auto is more for when auto is going to affect the results
00:49:11 <cyril> zakim, enjoy your 137 days left
00:49:11 <Zakim> I don't understand 'enjoy your 137 days left', cyril
00:49:25 <ed> ... if you're just doing based on the element you should use UA styleaheets
00:50:38 <ed> krit: next issue, rx and ry should use zero as initial value
00:50:54 <ed> ... something that's not there is fx and fy
00:50:58 <ed> ... on radial gradient
00:51:20 <ed> ... the descirption is complicated, by default uses values from cx and cy...
00:51:34 <ed> ... we could set them to auto and make them do the same thing
00:51:48 <ed> heycam: it's a strange feature
00:52:27 <ed> krit: it doesn't define specialcasing for fx,fy
00:52:40 <ed> heycam: we did decide to make fx and fy properties, right?
00:52:43 <ed> krit: yes
00:53:06 <ed> heycam: did we only do this because we did the other gradient attributes?
00:53:07 <ed> krit: I think so
00:53:24 <ed> heycam: we should focus on the basic shapes
00:53:42 <ed> ... don't do this for the gradient elements, even with cx, cy on gradients
00:54:35 <ed> ChrisL: but you can put presentation attributes on any element
00:54:52 <ed> ed: can't we just make them presentation attributes on particular elements?
00:56:04 <ed> heycam: if it's easier since presentation attributes work on any element (?)
00:56:34 <ed> krit: in webkit we didn't turn cx cy to properties on radialgradient
00:56:54 <ed> heycam: i'd prefer not making them presattrs in this case
00:58:25 <ed> RESOLUTION: don't make the layout properties into presentation attributes on the gradient elements
00:58:46 <ed> heycam: issue 2, what to do about x and y on text elements?
00:59:10 <ed> Tav: we also have them on tspan right?
00:59:13 <ed> heycam: yes
00:59:25 <ed> ... the issue is that they're list of values
00:59:50 <ed> ... either we could allow list of values in the property, but only use the first value
01:00:00 <ed> ... or the attribute has some special processing
01:00:30 <ed> ... one option is to not make x y presentation attributes on any of the text elements
01:01:28 <ed> krit: I like that, or alternatively make xy presattr on text, but map them to other properties
01:01:36 <ed> ... don't quite like the second idea though
01:01:57 <ed> heycam: we already decided that the x,y lists are bad due to font issues
01:02:15 <ed> ... so don't think we should allow the second one
01:03:25 <ed> krit: another way might be to apply the xy property to text elements, but also apply the positoning fromthe xy attributes also
01:03:34 <ed> ... that would allow positioning from css
01:03:46 <ed> heycam: that'd be a little bit confusing
01:03:55 <ed> ... but might be the best solution
01:04:49 <ed> Tav: so discourage use of the x,y,dx,dy?
01:05:01 <ed> heycam: I think we should try it out
01:05:22 <ed> krit: ok, so spec that and await feedback from implementations?
01:05:27 <ed> Tav: ok
01:06:18 <ed> 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
01:07:11 <ed> 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
01:07:12 <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].
01:07:15 <heycam> https://svgwg.org/svg2-draft/coords.html
01:07:27 <ed> heycam: next chapter, coordinates
01:07:47 <ed> ... issue 2, are there any more up-to-date defs for sizing? (i haven't checked)
01:07:57 <ed> ... prob needs some closer review by somebody
01:08:29 <ed> ... someone should take an action to look at this?
01:09:12 <ed> ACTION: krit to review the svg2 coordinate chapter
01:09:13 <trackbot> Created ACTION-3740 - Review the svg2 coordinate chapter [on Dirk Schulze - due 2015-02-20].
01:09:38 <ed> heycam: issue 9, about pAR
01:09:39 <heycam> https://svgwg.org/svg2-draft/coords.html#PreserveAspectRatioAttribute
01:09:55 <ed> ... do ppl use 'defer' or can we drop it?
01:10:22 <ed> ChrisL: is this somehting new?
01:10:31 <ed> heycam: I think it's from the original 1.0 spec
01:10:40 <ed> krit: don't think webkit implements this
01:10:59 <ed> heycam: we have some tests for defer, but doesn't mean that ppl are using it
01:11:08 <ed> ... would be happy to try removing it
01:11:43 <ed> ed: I'm fine with removing it
01:11:50 <tantek> tantek has joined #svg
01:12:13 <ed> heycam: firefox at least supports parsing it
01:12:22 <ed> Tav: inkscape doesn't support it
01:13:17 <ed> krit: webkit parses it but ignores it
01:14:14 <ed> ed: so does that imply that we should allow it but say in the spec that it must be ignored?
01:14:28 <ed> heycam: would prefer just to remove it (don't think there's much content using it)
01:15:25 <ed> krit: think we should parse it but ignore it
01:15:33 <ed> heycam: I'd prefer removing it
01:16:21 <tantek_> tantek_ has joined #svg
01:16:35 <ed> RESOLUTION: make defer do nothing (and investigate removing it later)
01:17:09 <ed> ACTION: krit to make defer be ignored in pAR
01:17:10 <trackbot> Created ACTION-3741 - Make defer be ignored in par [on Dirk Schulze - due 2015-02-20].
01:17:46 <ed> heycam: next, issue 15
01:17:50 <heycam> https://svgwg.org/svg2-draft/coords.html#BoundingBoxes
01:17:52 <ed> ... in the bbox section
01:18:18 <ed> ... bbox of text with the widht/height set on it
01:18:36 <ed> ... should it be the box that it's laid out in, or the union of the glyph cells?
01:19:06 <ed> Tav: the text would just be the content area, can be reduced due to padding/margin
01:19:22 <ed> krit: we should handle it like normal block elements in html
01:19:33 <ed> heycam: so what should getBbox return?
01:19:55 <ed> Tav: there are different bboxes in css
01:21:24 <ed> <text x=10 y=10 width=100>A</text>
01:21:24 <ed> heycam: sometimes you have content that can't wrap
01:22:02 <ed> Rossen: inline elements don't have width in css
01:22:10 <ed> ... this is closer to block
01:22:24 <ed> ... the blockrelated properties is what should apply to svg here
01:22:40 <ed> heycam: we don't need to make getbbox does like getboundingclientrect
01:22:53 <ed> ... if we ignore the width feature
01:23:07 <ed> ... we might return the size of A
01:23:21 <ed> Rossen: with the width today if you specify it
01:23:36 <shepazu> (SVG also has different bboxes... geometric bbox, decorated bbox, etc.)
01:23:37 <ed> ... you can say it's the bbox or that it's the union of the two, or just the text inside
01:23:59 <ed> Tav: depends on how much text you put in
01:24:05 <ed> heycam: it's a run of glyphs
01:24:15 <ed> ... we can do pre-formatted text
01:24:21 <ed> ... we can union the bboxes
01:24:42 <ed> ... i think we shouldn't return the rect area defined by width/height for text
01:32:03 <ed> Tav: if you've wrapped text, some text sticks out further than the others, you should make that affect the bbox
01:32:03 <ed> ... you'd have to look at all the lines to figure out the exact bbox
01:32:05 <ed> nikos: if we say width(height is always returned from getbbox you could just check the attribute
01:32:10 <ed> Rossen: the information for size of each line is available internally
01:32:15 <ed> ... you might want each line separately
01:32:18 <ed> ed: multiline text is new in svg2, do we want to allow fetching the size of each line?
01:32:23 <ed> krit: cssom defines that getclientrects maps to getbbox (?)
01:32:23 <ed> roc: maybe think of it as shrinkwrapped
01:32:23 <ed> ... the intrinsic preferred width
01:32:23 <ed> heycam: problem is tht dx dy influences the bbox
01:32:26 <ed> krit: we could disable them for the case of having width/height
01:32:26 <ed> heycam: the options
01:32:57 <ed> ... 1) look just a the glyphs, take bbox of each and then union the bboxes
01:33:59 <ed> ... 2) if you have width attribute then bbox has that exact width and height be multiple of lineheight
01:34:15 <ed> ... 3) union of option 1 and 2
01:34:27 <ed> TabAtkins: option 2 is closest to what css is doing today
01:35:11 <ed> Rossen: what do we do for negative margin on inline boxes?
01:35:28 <ed> TabAtkins: doesn't count
01:35:48 <ed> Rossen: not sure it translates well to svg
01:36:51 <ed> (draws on whiteboard)
01:39:41 <ed> 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
01:40:01 <ed> heycam: if we want options we have a param for getBBox that we can use
01:43:01 <ed> Rossen: so list of text content boxes, or the parent box that's the union essentially
01:43:35 <ed> heycam: we can always add a way to get the other one
01:43:48 <ed> Rossen: right, because we don't have any way to get the lineboxes
01:44:10 <ed> heycam: the only downside is that it's inconsistent with non-areabased text
01:44:19 <ed> ... where we're using css to layout the text
01:44:26 <ed> ... but shrinkwrapping the text
01:44:56 <ed> Rossen: that's fine though, the bbox is defined by the text content in that case
01:46:13 <ed> Tav: think we should not consider dx, dy and rotate in the textarea case
01:46:22 <ed> ... for the bbox
01:47:06 <ed> heycam: I think the block level element in css should provide the bbox (positioned)
01:47:29 <ed> Rossen: when width is auto one of the three possible ways to size the box
01:47:42 <ed> ... one is dependency on parent, in percentage
01:48:04 <ed> ... other is that it's fixed
01:48:12 <ed> ... third is that it's attached to the text content
01:54:23 <ed> -- break for lunch --
02:28:57 <tantek> tantek has joined #svg
03:01:22 <stakagi> stakagi has joined #svg
03:02:09 <nikos> scribe: Nikos
03:02:11 <nikos> scribenick: nikos
03:02:46 <nikos> Topic: Text bounding box
03:03:05 <nikos> heycam: we discussed over lunch
03:03:35 <nikos> heycam: when you call getBBox on a text element that has % or px or specified width then bounding box is the specified width
03:03:43 <nikos> ... and height is the height of the CSS box that gets created
03:04:05 <BogdanBrinza> BogdanBrinza has joined #svg
03:04:08 <nikos> ... and if you leave off the width, then you take the union of all the bounding boxes for the text
03:04:15 <nikos> ... to handle cases where things are positioned
03:04:32 <nikos> ... 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
03:04:38 <nikos> ... think that makes it a consistent model
03:04:48 <nikos> ... probably don't need to describe in terms of those three things
03:05:03 <nikos> Tav: looks like a good solution to me
03:06:49 <nikos> 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
03:07:22 <nikos> ACTION: heycam to spec behaviour of getBBox on text
03:07:22 <trackbot> Created ACTION-3742 - Spec behaviour of getbbox on text [on Cameron McCormack - due 2015-02-20].
03:07:34 <heycam> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Open_issues
03:07:58 <nikos> heycam: bogdan suggested we gather up open issues on this page - we might not have a chance to resolve them all this meeting
03:08:12 <nikos> ... so I summarised which I thought were substantive issues that need discussing
03:09:05 <nikos> ed: back to text, if you have text element without width or height and you have white space property set to pre wrap
03:09:15 <nikos> ... you have some return characters to specify text as multiple lines
03:09:19 <nikos> ... you get three lines of text
03:09:28 <nikos> ... behaviour of bounding box should be as auto
03:09:46 <AlexD> AlexD has joined #svg
03:09:48 <nikos> Topic: Open SVG 2 issues
03:09:51 <heycam> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Open_issues
03:10:03 <nikos> heycam: this list is based just on the red issues that are noted in the spec
03:10:08 <nikos> ... may be a few more things in tracker
03:10:18 <nikos> ... new ones may also pop up as we continue reviewing the existing text
03:10:24 <nikos> ... Erik and I have reviewed some chapters
03:10:32 <nikos> ... neither of us are through the whole spec yet
03:10:43 <nikos> ... so probably later chapters need a closer look than the earlier ones
03:11:03 <nikos> ... bearing that in mind, this wiki lists the substantive issues that are noted in the spec
03:11:23 <nikos> cyril: some chapters start at issue number > 1?
03:11:30 <nikos> heycam: we've already discussed some and some don't need discussing
03:11:37 <nikos> ... we may or may not get through this list
03:11:44 <nikos> ... how would you like to prioritise?
03:12:13 <nikos> BogdanBrinza: normally for us we take a first pass at the list and find highest priority items
03:12:34 <nikos> Rossen: hope we're in agreement we want to ship the spec?
03:12:46 <nikos> ... so we can tackle a couple of ways
03:13:01 <nikos> ... we can look at the spec as a whole - if we agree we want to close all issues and ship the spec
03:13:07 <nikos> ... then move to a modular way of advancing svg
03:13:17 <nikos> ... then first pass should be to decide the must unstable and non core things
03:13:19 <nikos> ... that we can live without
03:13:23 <nikos> ... and make those modules right now
03:13:32 <nikos> ... that will reduce the amount of work we need to do as a group to discuss issues
03:13:42 <nikos> ... so as a first pass lets find big areas we can remove
03:13:56 <nikos> ... then from remaining we can assess what is in most dire need of group discussion time
03:14:12 <nikos> heycam: I like the idea of creating modules immediately for things we're removing
03:14:44 <nikos> cyril: maybe not the case for all chapters - but some seem to be very close to modules
03:15:32 <BogdanBrinza> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_readiness_assessment
03:16:07 <nikos> Rossen: is your list an extraction of this table?
03:16:18 <nikos> heycam: has some correlation probably but this is just my judgement of the issues
03:16:24 <nikos> ... and which are not editorial
03:16:35 <nikos> BogdanBrinza: think we agree on chapters that have most issues
03:17:01 <ChrisL> ChrisL has joined #svg
03:17:22 <nikos> Rossen: do we think we can go through the first step and move things to modules?
03:17:43 <nikos> krit: I'm in favour of that - do you have features that you want to move
03:18:24 <nikos> Tav: Think we'd spend more time arguing over which stuff to move than how to solve the issues
03:19:47 <nikos> BogdanBrinza: Chapters 15, mesh gradients has a lot of issues
03:20:02 <nikos> heycam: don't think we should be looking at the chapter level - but at features
03:20:24 <nikos> heycam: 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?
03:20:40 <nikos> Rossen: not sure - if we can move something to the next level why spend time talking about it?
03:20:57 <nikos> heycam: sounds like you have ideas about features you don't want to see in the spec - even though there are no open issues
03:21:07 <nikos> Rossen: I wouldn't oppose a stable feature staying
03:21:24 <nikos> BogdanBrinza: generally not about features we want in the spec - but everyone wants to see a stable spec
03:21:39 <nikos> heycam: do you think stability is not solely determined by open issues?
03:21:51 <nikos> BogdanBrinza: I'd say that's the most important thing - but severity matters too
03:21:59 <nikos> heycam: I was going to suggest looking at features that correspond to open issues
03:22:13 <nikos> ... so if we've resolved issues on a feature it can stay
03:22:27 <nikos> Rossen: do we consider features complete?
03:22:34 <nikos> ... or just enough stuff there so we think it's complete but not sure
03:22:41 <nikos> ... are we going to find issues when we review?
03:23:05 <nikos> Rossen: ok lets go through each issue then
03:23:32 <nikos> heycam: let's finish co-ords chapter then we can talk about features in other chapters
03:24:28 <nikos> ACTION: heycam to make stable issue identifiers in the spec
03:24:29 <trackbot> Created ACTION-3743 - Make stable issue identifiers in the spec [on Cameron McCormack - due 2015-02-20].
03:24:43 <nikos> issue 17, co-ords chapter
03:24:51 <nikos> heycam: issue 17, co-ords chapter
03:25:00 <nikos> heycam: should fill correspond to the main area of that element?
03:25:10 <nikos> ... so fill:false should exclude that rectangular region?
03:25:21 <ed> for ACTION-3743 make sure that the template has fields for assigned actions, wg discussion and resolution
03:26:01 <nikos> heycam: if it's not an svg element you can't call getBBox, but you can call it on the parent
03:26:07 <nikos> ... so iframe or canvas should contribute to the bbox
03:26:33 <nikos> Rossen: if it's not exposed how can you get the bbox?
03:26:45 <nikos> ... should define getBBox on these elements
03:27:10 <nikos> 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
03:27:26 <nikos> Rossen: we define getBBox on foriegnObejct? Behaviour should be the same
03:27:38 <nikos> krit: but on fo you have a whole html doc
03:28:25 <nikos> 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
03:29:16 <nikos> Tav: To me fill:false is not a sensible option
03:29:20 <nikos> ... as a control
03:29:26 <nikos> heycam: sounds like we agree on that
03:30:06 <nikos> RESOLUTION: The fill dictionary parameter doesn't affect bounding box of iframe, canvas, etc
03:30:53 <nikos> ACTION: heycam to update spec for fill dictionary parameter when called on iframe, canvas, etc
03:30:53 <trackbot> Created ACTION-3744 - Update spec for fill dictionary parameter when called on iframe, canvas, etc [on Cameron McCormack - due 2015-02-20].
03:31:19 <nikos> heycam: proposing to remove svg:transform’ attribute
03:31:23 <nikos> krit: already done
03:31:28 <nikos> ChrisL: where is it being moved to ?
03:31:31 <nikos> heycam: no one uses it
03:31:48 <nikos> ChrisL: mapping people use it
03:31:55 <tantek> tantek has joined #svg
03:32:09 <Zakim> Zakim has left #svg
03:32:09 <nikos> ... my understanding is we changed behaviour for this to match what implementations do
03:32:32 <nikos> krit: the removed text was mostly pointless
03:33:05 <nikos> cyril: it's not the same as the transform attribute - same name but in a different namespace
03:33:12 <nikos> heycam: if you think it's being used by people it can stay
03:33:18 <nikos> ... just worried wording is outdated
03:33:33 <nikos> ChrisL: this was standardised through JIS
03:33:44 <nikos> krit: I'll put it in integration spec
03:33:50 <nikos> ChrisL: that's ok - just don't want it removed
03:34:01 <nikos> AlexD: isn't this what Takagi-san is using for tiling?
03:34:04 <nikos> ChrisL: yes
03:34:53 <nikos> cyril: don't think it should be in integration spec - should be module on it's own
03:35:05 <nikos> ... I see integration spec as between svg, html, css
03:35:13 <nikos> ChrisL: it's larger - how css uses things
03:35:21 <nikos> Tav: I'd like to see it moved before it's taken out
03:35:24 <nikos> krit: I'm doing it right now
03:35:29 <nikos> ... into a new module right/
03:35:35 <nikos> ChrisL: section above it as well?
03:35:48 <nikos> heycam: there was going to be a mapping spec?
03:35:56 <nikos> ChrisL: yes but mapping spec by itself wasn't useful
03:35:59 <nikos> ... by itself
03:36:05 <nikos> ... so dispersed these features into svg 2 spec
03:36:18 <nikos> Tav: that's why it's good having annotations describing why things are moved
03:36:55 <nikos> RESOLUTION: svg:transform attribute will be moved to a new module
03:37:41 <nikos> heycam: let's look at remaining issues in terms of the features they encompass
03:37:48 <nikos> ... all path issues are for Catmull-Rom
03:37:58 <nikos> Rossen: who is implementing it?
03:38:04 <nikos> Tav: it's Doug's baby
03:38:11 <nikos> Rossen: can we have a Catmull-Rom module?
03:38:21 <shepazu> why?
03:38:30 <nikos> ChrisL: tricky because it's in the path element
03:38:42 <nikos> shane: we did that in CSS
03:38:57 <nikos> ChrisL: was going to bring that up as a bad example
03:39:16 <nikos> shepazu: there's a not great way - which would still be good enough
03:39:27 <nikos> ... supersede description in new spec
03:39:34 <nikos> ... good way is define what path commands look like
03:39:42 <nikos> ... and say future specs may define new path commands
03:39:52 <nikos> ChrisL: agree, not sure how much work it is making it properly extensible
03:40:16 <nikos> shane: could put all stuff in path extension spec
03:40:41 <nikos> ChrisL: so in core svg 2 path syntax is the same as svg 1.1?
03:40:44 <nikos> heycam: we have bearing and stuff
03:41:16 <nikos> heycam: that's an example of a feature that is complete in the spec, but people have reservations about it being in core svg 2
03:41:35 <nikos> Tav: it's not something I care too much about having - but feel it will be ignored once it's in another spec
03:41:39 <nikos> Rossen: that's how css works
03:41:47 <nikos> ... survival of the fittest - good features progress faster
03:41:55 <nikos> ... I think it's a good way to do things
03:42:00 <nikos> TabAtkins: don't be afraid of modules
03:42:39 <nikos> 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
03:42:52 <nikos> ChrisL: that's a problem because we've then spent 10 years producing a spec that doesn't have new features
03:43:05 <nikos> Rossen: if you have 5 other specs in the pipeline then you have a good story
03:43:16 <nikos> ChrisL: we've already gone from modules to one monolithic spec
03:43:19 <nikos> ... now we're going back
03:43:31 <nikos> Tav: how much work to fix Catmull Rom?
03:43:35 <nikos> heycam: need to add math to the spec
03:43:44 <nikos> ... issues could be summarily decided
03:44:33 <nikos> Rossen: this is a good example of a feature that could move imo
03:44:36 <nikos> ... it's a good feature
03:44:53 <nikos> ... some designers have questioned it's use
03:45:25 <nikos> Tav: there's a good use when connecting points in a graph
03:45:46 <nikos> heycam: I would have to do investigation of the math
03:45:49 <nikos> Tav: it's pretty simple
03:46:21 <nikos> Rossen: if it was such a hot feature I'd expect Adobe, InkScape, etc to be pushing it
03:46:26 <nikos> krit: Adobe already stated we don't care
03:47:21 <nikos> heycam: so if you want a sense of it staying in svg 2 or being split ... ?
03:47:29 <nikos> krit: not necessary for svg 2
03:47:36 <nikos> Rossen: can we resolve to move it to it's own module
03:47:50 <nikos> heycam: as long as we create a new spec immediately
03:47:54 <nikos> ... don't want to lose the work we have done
03:48:34 <nikos> ed: do you have same concern about bearing?
03:48:38 <nikos> Rossen: I haven't read the bearing stuff
03:48:53 <nikos> heycam: I'll be less excited about shipping svg 2 with all the features removed
03:49:14 <nikos> shane: I think we'll fairly readily be able to find features that have no issues or trivial and those that have substantive issues
03:49:30 <nikos> ... why not appoint champion or owner for features with substantive issues
03:49:44 <nikos> ... if issues aren't resolved by wg within a certain time frame we move it out
03:50:02 <nikos> Rossen: features without issues shouldn't necessarily remain part of the core
03:50:37 <nikos> ... if features have expensive implementation cost then they should maybe moved out
03:50:45 <nikos> heycam: we could mark them at risk
03:50:55 <nikos> Jet: is there a list of at risk features/
03:51:00 <nikos> ... that's probably the first step
03:51:14 <nikos> heycam: table in your wiki page isn't at feature granularity, which is what we need to discuss
03:51:33 <jet> jet has joined #svg
03:51:34 <nikos> Rossen: it's easy to decide on some - basic types for example
03:52:41 <nikos> krit: svg 1.1 isn't going to disappear - it can still be referenced
03:52:57 <nikos> stakagi: not using transform at the moment - it is ok to remove it from this level
03:53:07 <nikos> ... you can put me as editor of the svg:transform spec
03:53:33 <nikos> heycam: Catmull-Rom - what are we doing?
03:53:40 <nikos> heycam: put with superpath as svg path level 1?
03:53:49 <nikos> shane: it's a really nice target for modularisation
03:53:56 <nikos> ... doesn't mean it won't be published at the same time as svg 2
03:54:12 <nikos> heycam: let's publish first draft of these things when we publish CR of svg 2
03:54:34 <nikos> RESOLUTION: Will create SVG path module
03:55:24 <nikos> heycam: should svg 2 path only be what is supported by 1.1?
03:55:31 <nikos> ... so move all new things (e.g. bearing) into the module?
03:55:57 <nikos> shane: there is work involved in moving stuff - if a feature has no issues then leave it
03:56:00 <nikos> heycam: I'm ok either way
03:56:06 <nikos> Rossen: i'm ok with either too
03:56:13 <nikos> heycam: minimum work is leave it where it is
03:56:20 <nikos> all: let's do that
03:56:39 <nikos> ACTION: heycam to move Catmull-Rom to SVG path module
03:56:40 <trackbot> Created ACTION-3745 - Move catmull-rom to svg path module [on Cameron McCormack - due 2015-02-20].
03:56:59 <nikos> heycam: Editors will be Cam, Doug, and Cyril
03:57:36 <nikos> TabAtkins: do we want to use CSS naming where everything that builds off SVG 2 is next level?
03:57:41 <nikos> ... then we'd start at 2
03:57:46 <nikos> all: that's confusing, let's start at
03:57:49 <nikos> ... 1
03:57:55 <nikos> heycam: next bunch of issues are to do with text
03:58:06 <nikos> ... either shape text or rectangular ref text
03:58:15 <nikos> Rossen: are your issues in an order?
03:58:18 <nikos> heycam: just numeric
03:58:26 <nikos> Rossen: can we do things with only 1 issue?
03:58:58 <nikos> heycam: Let's do animate.html, Issue 2
03:59:20 <nikos> birtles: basically new features we'll defer to a separate spec
03:59:31 <nikos> ... then there's one or two edits I should make with regards to correctness
03:59:39 <nikos> ... not sure about allowing animatemotion to use a basic shape
03:59:52 <nikos> ... not sure if we want to include those slight improvements
03:59:56 <nikos> ... or defer everything
04:00:04 <nikos> Rossen: what would it look like after your change?
04:00:18 <nikos> ed: we resolved to allow basic shapes for text on path
04:00:27 <nikos> birtles: so for consistency we should leave it
04:00:34 <nikos> birtles: major features will be deferred
04:00:59 <nikos> ...I can take care of the issues that are there
04:01:10 <nikos> ... and get rid of references to features which we'll put in a different module
04:01:34 <nikos> heycam: can we discuss attributeType="auto"?
04:02:00 <nikos> ed: I came across issue with SMIL elements and attributeType
04:02:12 <nikos> ... default is auto which means check if it's a property first
04:02:18 <nikos> ... if so that's what your'e animated, otherwise attribute
04:02:25 <nikos> ... since we made x and y properties
04:02:30 <nikos> ... it's a problem on text element
04:02:35 <nikos> ... which takes a list of values
04:02:50 <nikos> ... I'm wondering if we should try to be smarter here selecting the right thing
04:02:56 <Florian> Florian has joined #svg
04:03:04 <nikos> heycam: why wouldn't that content work now?
04:03:14 <nikos> ... auto means when both property and presentation attribute, choose the property right?
04:04:11 <nikos> ed: if we make x a property, we'll try to animate x as a css property
04:04:17 <nikos> ... and that might not give the same result as previously
04:04:26 <nikos> heycam: outcome of previous discussion was that it would work
04:04:44 <nikos> ... property is the primary thing that determines the value
04:05:16 <nikos> 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
04:05:48 <nikos> ... one suggestion is to make auto pick the xml version if it's a text element
04:05:53 <nikos> ... that will preserve old behaviour
04:05:59 <nikos> ... and pick css property for any other element
04:06:05 <nikos> Rossen: and when number of values is one?
04:06:33 <nikos> AlexD: I don't like behaviour of attribute depending on what it's parent is
04:06:43 <nikos> birtles: you have to look up parent or target anywhere when animating
04:06:45 <nikos> AlexD: but not when binding
04:07:01 <nikos> birtles: yes you need to look to see if there's an attribute of that name that can be animated
04:07:07 <nikos> AlexD: seems like strange behaviour to me
04:07:18 <nikos> ... choose one or the other and whatever it breaks it breaks
04:07:23 <nikos> Rossen: doesn't sound like much will break
04:07:27 <nikos> ed: expect most would use one value
04:07:31 <nikos> birtles: I think there'd be some breakage
04:07:45 <nikos> ... you see people moving characters around like taht
04:07:51 <nikos> s/taht/that
04:08:03 <nikos> Rossen: I'd be more concerned about tools and tool makers
04:08:14 <nikos> birtles: that suggests keep backwards compat
04:08:22 <nikos> AlexD: don't know if there's any tool that generates this
04:09:01 <nikos> birtles: I was hoping to deprecate attributeType altogether
04:09:18 <nikos> ChrisL: attributeType was introduced to disambiguate a name class between width and height attributes and properties
04:09:20 <birtles> Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1062106
04:09:30 <nikos> ... so most of the time you didn't need to specify it
04:09:36 <nikos> ... in some was we have more of a clash now
04:09:49 <nikos> ... we've promoted lots of things that were attribtues into properties
04:09:59 <nikos> ... so I don't think it serves much purpose at the moment
04:10:06 <nikos> ... think people tended to guess as to which value to set
04:10:11 <nikos> ... and it usually didn't matter
04:10:24 <nikos> ... so you'd probably find uses - but removing attributeType would probably render just the same
04:10:30 <nikos> birtles: but how do we make text case work?
04:10:39 <nikos> Rossen: state it's deprecated
04:11:00 <nikos> birtles: if we get rid of attributeType how do you animate x attribute on text element?
04:11:48 <nikos> Rossen: so what are options we have?
04:12:33 <nikos> Rossen: option a) remove attributeType altogether because pretty much all properties are attributes and only x is problematic
04:12:50 <nikos> ... we'll deprecate multiple x/y value animate for text
04:13:00 <nikos> ... as a consequence
04:13:49 <nikos> ed: do we want to consider deprecating having multiple x/y values on text element
04:13:59 <nikos> cyril: it's heavily used isn't it ?
04:14:03 <nikos> krit: yes but not for animation
04:14:35 <nikos> ACTION: ed to add use counter for multiple x/y values on text element
04:14:35 <trackbot> Created ACTION-3746 - Add use counter for multiple x/y values on text element [on Erik Dahlström - due 2015-02-20].
04:14:53 <nikos> Rossen: let's wait for more data then
04:15:00 <nikos> ed: don't think we need to make both decisions at the same time
04:15:24 <nikos> 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
04:15:35 <nikos> ... e.g. we can take last or first valid attribute from the list
04:15:38 <nikos> ... and animate with that
04:15:45 <nikos> ... which will again break animation, but not as badly (maybe)
04:15:56 <nikos> ... in one case you have no animations at all - second you have animations of one frame
04:16:10 <nikos> Rossen: not perfect, but less invasive
04:16:25 <nikos> ... option c) get rid of attributeType and add special handling for x on text
04:16:43 <nikos> ... make it context aware
04:18:25 <nikos> Rossen: is there another option where we extend the attributeType to specify instead of doing context aware
04:18:36 <nikos> heycam: it already has values to select attribute or property
04:18:54 <nikos> ed: we could make auto on text elements, pick xml as the default
04:19:21 <nikos> Rossen: option d) attributeType for animate inside of text is always xml - there is no auto
04:19:33 <nikos> ... would reduce options in future
04:19:39 <nikos> cyril: detect number of values?
04:19:45 <nikos> Rossen: that would be hacky
04:20:22 <nikos> birtles: I think we could drop attributeType and leave a note in the spec with the context aware behaviour as an open issue
04:20:27 <nikos> ... see what data we get on the use counter
04:20:42 <nikos> ... if there's not sufficient usage of multiple values for x we drop, otherwise we do context aware
04:20:51 <nikos> Rossen: what about if we deprecate it now and see who fights for it?
04:21:25 <nikos> birtles: I know there's a lot of opposition to multiple values for x anyway
04:21:43 <nikos> ed: difference between static text with multiple values and animated multiple values - there will be a lot less animated
04:23:24 <nikos> cyril: removing attributeType is ok - but the consequence in option a is not acceptable
04:23:35 <nikos> birtles: the consequence only applies to animation
04:23:39 <nikos> cyril: ahh ok
04:23:53 <nikos> birtles: there is a work around for jittering text
04:24:06 <nikos> ... using dx/dy
04:24:56 <nikos> RESOLUTION: remove attributeType and deprecate animation of multiple values in x/y
04:25:14 <nikos> Rossen: that was the big issue with animation - so this chapter is mostly clear
04:25:20 <nikos> birtles: I need to do some more tidy up but yes
04:25:45 <nikos> heycam: interact.html  ISSUE 1: should we remove duplicate events like SVGLoad? is already resolved
04:26:06 <nikos> ... lacuna value for pservers.html  ISSUE 3: linearGradient y2 lacuna value is already resolved
04:26:14 <nikos> ... the value should really be zero
04:26:29 <nikos> RESOLUTION: lacuna value of y2 on linearGreadient should be zero
04:27:09 <nikos> Rossen: what about masking.html  ISSUE 2: define how overflow-x,y work ?
04:27:48 <nikos> krit: being moved
04:28:58 <nikos> krit: ISSUE 3: should overflow:auto really be equivalent to visible
04:29:06 <nikos> ... we changed behaviour based on ie
04:29:16 <nikos> Rossen: thought we discussed in London?
04:29:58 <Florian> Florian has joined #svg
04:31:30 <nikos> nikos: from London - All viewport-establishing elements will be overflow:visible by default, except for root <svg> of SVG whole documents.
04:31:46 <nikos> http://www.w3.org/2014/08/22-svg-minutes.html#item04
04:32:15 <nikos> Rossen: seems like a perfect fit for integration spec
04:32:24 <nikos> krit: do we move overflow to integration spec?
04:32:28 <nikos> heycam: why is it in our spec?
04:32:32 <nikos> ed: we have lots of special rules
04:32:49 <nikos> heycam: remove that section, add relevant UA rule and that should be enough
04:33:32 <nikos> heycam: krit can we really remove it all?
04:33:45 <nikos> heycam: I need to think about it - give me the action
04:34:09 <nikos> ACTION: Cameron to take care of overflow section in the masking chapter
04:34:09 <trackbot> Created ACTION-3747 - Take care of overflow section in the masking chapter [on Cameron McCormack - due 2015-02-20].
04:35:16 <nikos> 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
04:37:28 <nikos> RESOLUTION: masking.html, issue 3 - Drop overflow-x,y issue and don't do anything specific in SVG
04:38:02 <Rossen> s/masking.html, issue 3/masking.html, issue 2/
04:41:13 <jdaggett> jdaggett has joined #svg
04:41:54 <nikos> krit: so all these changes are going to integration spec and are being removed from svg 2?
04:41:58 <nikos> Rossen: yes
04:42:35 <nikos> heycam: i'm concerned that it's not valid to state that auto on a particular element computes to a different value
04:42:38 <nikos> Rossen: we do that all the time
04:44:32 <nikos> RESOLUTION: masking.html  ISSUE 3: should overflow:auto really be equivalent to visible? Should be moved to integration spec and removed from SVG 2
04:45:39 <nikos> krit: can we remove 15.3 and 15.4 totally?
04:45:51 <nikos> heycam: think in rendering chapter we need to describe how these things fit into the scheme of things
04:47:20 <nikos> nikos: I think rendering chapter should say at what point these things occur and that's all
04:55:04 <ed> -- 15 min break --
05:16:52 <Tav> scribe: tav
05:17:10 <Tav> scribenick: Tav
05:17:36 <Tav> Rossen, Let's cover issue in color chapter.
05:17:50 <ed> topic: svg2 issues in the color chapter
05:17:57 <cyril> s/Rossen/Rossen:/
05:18:02 <cyril> s/Rossen,/Rossen:/
05:18:54 <ed> https://svgwg.org/svg2-draft/color.html#color-managed-images
05:19:02 <Tav> Rossen, Issue 1:
05:19:09 <cyril> s/Rossen,/Rossen:/
05:19:10 <Tav> ... should this be here?
05:19:37 <Tav> TabAtkins, : Should be in colors4.
05:20:24 <Tav> .... not in yet, will be soon.
05:21:34 <Tav> krit: What do we need to keep?
05:21:44 <Tav> Rossen: Tab, what do we need to keep?
05:21:55 <Tav> TabAtkins: Nothing.
05:22:13 <Tav> Rossen: Motion: move everything in this chapter to color4.
05:22:38 <Rossen> https://svgwg.org/svg2-draft/color.html#InterfaceSVGColorProfileRule
05:22:42 <Tav> krit: SVG Interface rule should disappear.
05:23:38 <Tav> ed: What about ICC?
05:23:59 <Tav> Rossen: Yes, should be in colors4.
05:24:19 <Tav> RESOLUTION: Drop SVG color profile rule interface.
05:24:46 <ed> s/What about ICC?/will icc-color be part of the <color> grammar in css?/
05:25:06 <Tav> RESOLUTION: Remove color chapter from SVG 2. Refer to CSS Color 3 and 4.
05:25:55 <Tav> ACTION: TabAtkins Finish CSS Color 4 (with stuff from SVG).
05:25:55 <trackbot> Created ACTION-3748 - Finish css color 4 (with stuff from svg). [on Tab Atkins Jr. - due 2015-02-20].
05:26:18 <krit> https://svgwg.org/svg2-draft/types.html#InterfaceSVGCSSRule
05:26:28 <krit> https://svgwg.org/svg2-draft/types.html#InterfaceSVGRenderingIntent
05:26:40 <Tav> Topic: Remove above two interfaces.
05:27:02 <Tav> ed: Should go.
05:27:39 <ed> (to be clear, the entire room says that, not just me ;)
05:27:44 <Tav> RESOLVE: Remove InterfaceSVGCSSRule and InterfaceSVGRenderingIntent.
05:28:43 <Tav> Rossen: Only two chapters to go from heycam's list: painting & text.
05:29:12 <Tav> Topic: Painting chapter issues
05:29:30 <heycam> Scribe: Cameron
05:29:33 <heycam> ScribeNick: heycam
05:29:40 <Rossen> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Open_issues
05:30:03 <heycam> heycam: first two issues are to do with arcs line-join
05:30:10 <heycam> Tav: first issue is the name
05:30:17 <heycam> ... nobody suggested a different name
05:30:19 <heycam> ... so let's just leave it as is
05:30:39 <heycam> ... second one is what do you so with miter-limit
05:30:53 <heycam> ... now that we have this clipping option, ...
05:31:12 <heycam> ... it's possible to get a very long arc
05:32:47 <heycam> ... 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
05:35:16 <heycam> RESOLUTION: arc line caps are affected by miter-limit by measuring along the middle arc and clipping a straight line perpendicular at that point
05:36:49 <heycam> ACTION: Tav to make miter-limit work on arc line caps in this way
05:36:49 <trackbot> Created ACTION-3749 - Make miter-limit work on arc line caps in this way [on Tavmjong Bah - due 2015-02-20].
05:38:06 <Tav> Scribe: Tav
05:38:13 <Tav> ScribeNick: Tav
05:38:56 <Tav> Topic: Issue: stroke-dashcorner doesn't work well for rounded rects
05:39:23 <Tav> heycam: New feature in SVG 2. It's nice.
05:39:34 <Tav> ... look at pictures in section.
05:40:02 <heycam> https://svgwg.org/svg2-draft/painting.html#StrokeDashcornerProperty
05:40:27 <Tav> ... Illustrator supports.
05:40:44 <Tav> krit: Illustator dashing different.
05:41:02 <Tav> heycam: Not the most important issue.
05:41:13 <Tav> krit: Could we have a stroking enhancement spec?
05:41:54 <Tav> ... would like to have a core with what is supported today.
05:42:10 <Tav> heycam: Not happy with pulling out stroking.
05:42:24 <Tav> ed, Rossen stroking should be well defined.
05:42:40 <Tav> krit: doesn't include stroke-alignment...
05:43:25 <Tav> Rossen: The fact that stroking will be well defined in SVG 2 we could still have a stroking spec.. What would be in it?
05:43:44 <Tav> heycam: I can summarize the new things:
05:43:58 <Tav> ... stroke-dashadjust
05:44:08 <Tav> .... stroke-dashcorner
05:44:37 <Tav> ... arcs line join
05:44:50 <Tav> ... stroke-alignment
05:45:54 <Tav> krit, tav: stroke-alignment often requested.
05:46:02 <Tav> tav: would like to have %
05:48:15 <Tav> Rossen: stroke-dashcorner: our (IE) implementation for stroking is pretty complicated, could be hard to do.
05:48:23 <Tav> krit: Used in illustrator.
05:48:35 <Tav> heycam: Can just stretch dash array.
05:49:12 <Tav> Rossen: We still don't have interopability with normal dashing today.
05:49:30 <Tav> roc: SVG stroking is actually rather simple.
05:50:03 <ed> (in comparison to css border dashing)
05:50:21 <Tav> roc: We need an extensible stroking task force. Lots of neat things you can do.
05:50:44 <Tav> Rossen: Should there be a new module?
05:51:20 <Tav> Rossen: What would be in the new SVG stroking module:
05:51:30 <Tav> ed: Variable with stroking.
05:51:38 <Tav> Rossen: That's a really cool feature.
05:51:39 <ed> s/with/width/
05:51:41 <stakagi> stakagi has joined #svg
05:52:03 <Tav> krit/Rossen Dashing and Variable width.
05:52:35 <Tav> Rossen: We extend in CSS specs with just one new value of a property.
05:53:55 <Tav> Rossen: New specs should only add stuff that's not in already in SVG 2.
05:54:16 <Tav> krit: But what should we ship here for SVG 2?
05:54:52 <Tav> heycam: I think there are some things already implemented that should remain.
05:55:26 <Tav> Rossen: Should we start with stroke-dashcorner? (Moving to new spec)
05:56:32 <Tav> 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.
05:57:30 <Tav> Rossen: I think that moving things into modules sends the message that we can move faster than with a big SVG2 spec.
05:58:25 <Tav> krit: I'm happy to move out new marker stuff to new spec.
05:58:47 <Tav> heycam: There would be some overlap in text between specs.
05:59:53 <Tav> Rossen: there are modules that we would ship ahead of SVG2.
06:01:56 <Tav> Rossen: Interlude: explains IE/Microsoft philosophy towards choosing what to ship.
06:02:43 <Tav> krit: Can we have a resolution having a painting module?
06:02:52 <Tav> ... put in paint-order
06:03:08 <Tav> ed: Don't think that's a good idea.
06:03:56 <Tav> tav: Would you (Rossen) implement 'paint-order' if it was in a separate spec?
06:04:02 <Tav> Rossen: Yes.
06:04:29 <Tav> ed: We could say that this section is stable.
06:04:39 <Tav> Rossen: It's not in a stable spec.
06:05:12 <Tav> Discussion of where things should go....
06:05:48 <Tav> Rossen: Should we start an SVG marker spec?
06:07:02 <Tav> heycam: I'm more concerned about public impression of SVG 2 if things get moved out.
06:07:58 <shepazu> modularization is time consuming and confuses developers
06:08:06 <ed> +1
06:08:12 <Tav> BogdanBrinza: What the SVG working group thinks is more important than public perception.
06:08:49 <ed> (the time consuming part)
06:08:53 <Tav> heycam: Things in the past that have been split out tend to mean that we don't want to work on it.
06:09:50 <Tav> heycam: One advantage of splitting out is that we would have a well defined owner for the spec.
06:10:27 <Tav> Tav: A markers spec would be a good trial of this.
06:11:26 <Tav> ed: Not clear that a marker spec could move faster. There is a lot of stuff tied to SVG core.
06:11:56 <Tav> Rossen: having something in PR is much better than having some text in the bigger spec.
06:12:17 <Tav> ... saying this is stable.
06:12:44 <Tav> krit: marker knockout should be moved to a separate markers spec.
06:14:00 <Tav> heycam: ignoring the marker knockout, the rest is pretty stable.
06:15:10 <Tav> Proposal: Start a new marker spec.
06:15:33 <Tav> ed: Not so sure about this but won't object.
06:15:52 <Tav> tav: with eric
06:16:34 <Tav> heycam: Is willing to try it.
06:19:42 <Tav> RESOLUTION: Move new marker features to a separate marker spec.
06:20:17 <cyril> RRSAgent, draft minutes
06:20:17 <RRSAgent> I have made the request to generate http://www.w3.org/2015/02/12-svg-minutes.html cyril
06:22:11 <Tav> Rossen: We won't be discussing the following issues:
06:22:12 <Rossen>  ISSUE 23: what to do with marker knockouts
06:22:27 <Rossen>  ISSUE 18: name these vertex or segment markers?
06:23:34 <Rossen> ISSUE 30: should paint-order be able to select the different types of markers?
06:23:44 <Rossen> ISSUE 32: should SVGMarkerInstance objects be live?  (or should we remove those interfaces?)
06:24:08 <Tav> Rossen: Let's get back to stroke-dashcorner for rounded rects.
06:24:49 <Tav> heycam: Dashing will move slower than markers. Dashing should move into a stroking spec.
06:25:30 <Tav> Moving on to text issues.
06:28:02 <Tav> Tav: Meta issue: how do we treat all the various text properties?
06:28:33 <Tav> General discussion...
06:30:32 <Tav> Rossen: It would be reasonable to expect that paragraph level things would work. (text-indent, etc.)
06:31:41 <Tav> heycam: Properties that apply to inline elements should work.
06:31:57 <Tav> roc: some aren't appropriate perhaps.
06:32:16 <Tav> Rossen: overflow:scroll?
06:33:11 <Tav> ChrisL: Don't want a white list.
06:33:30 <Tav> krit: Text handled by normal code path.
06:33:38 <Tav> Rossen: So do we.
06:34:17 <Tav> Rossen: In trident we have the concept of paragraphs that are like blocks with out the blocky stuff (padding, etc.)
06:34:35 <Tav> ... text alignment, writing mode, etc. are supported.
06:35:02 <Tav> ... underline, bold are handled in one level down.
06:35:34 <Tav> heycam: We should have a paragraph guiding our intentions so when new things come along they can be automatically included or excluded.
06:36:13 <Tav> Rossen: We could ask the CSS working group to add a term that defines paragraph level properties.
06:37:21 <Tav> roc: CSS does have the concept of anonymous blocks. We want everything that effects these blocks. But there is no name.
06:37:39 <Tav> krit: We should ask CSS for an "official" name.
06:40:31 <Tav> RESOLVE: 'text-indent' applies to <text> as it is part of the CSS paragraph level properties.
06:41:31 <ed> s/RESOLVE:/RESOLUTION:/
06:48:03 <Tav> RESOLUTION: CSS Paragraph level properties are assume to apply to SVG <text> element with wrapping context.
06:48:39 <heycam> Scribe: Cameron
06:48:42 <heycam> ScribeNick: heycam
06:48:49 <heycam> Rossen: so that resolves issues 37 and 38
06:49:14 <heycam> ... shape-inside, shape-outside
06:49:32 <heycam> Tav: I think I know what to do with these now after discussing with CSS folks
06:49:39 <heycam> Rossen: I am the editor of that spec, too
06:49:45 <heycam> Rossen: so the rest of the issues are shapes related
06:49:59 <heycam> ... issue 2, are dx/dy/rotate ignored for auto-wrapped text
06:50:48 <heycam> ChrisL: when would you want to do that
06:50:50 <heycam> heycam: never
06:50:53 <heycam> Tav: I would be fine with that
06:50:57 <heycam> ed: I agree
06:51:04 <heycam> ChrisL: those things were because we didn't have wrapping text
06:51:14 <heycam> ... and some people wanted to do "better" text on a path
06:52:15 <heycam> heycam: you could argue from consistency with single line text
06:52:26 <heycam> ... you could apply the positioning attributes to content area text just as easily
06:52:29 <heycam> ... but it won't be useful
06:52:46 <heycam> RESOLUTION: dx/dy/rotate are ignored for text with a wrapping context
06:53:10 <heycam> Rossen: last, issue 4; should x/y specify the corner of the content area or the origin of the first glyph
06:54:08 <heycam> [Tav draws and shows the two options]
07:01:19 <heycam> Rossen: I suggest using extent rather than width/height
07:01:29 <heycam> ... then authors won't think you should be able to put both width and height
07:01:37 <heycam> RESOLUTION: Change width/height on <text> to extent
07:02:04 <heycam> ACTION: Tav to make the text changes from today's meeting
07:02:04 <trackbot> Created ACTION-3750 - Make the text changes from today's meeting [on Tavmjong Bah - due 2015-02-20].
07:02:48 <heycam> RRSAgent: make minutes
07:02:48 <RRSAgent> I have made the request to generate http://www.w3.org/2015/02/12-svg-minutes.html heycam
09:13:13 <myakura> myakura has joined #svg
11:11:23 <Tav> Tav has joined #svg
13:44:41 <richardschwerdtfeger> richardschwerdtfeger has joined #svg
14:10:36 <shepazu_> shepazu_ has joined #svg
15:37:41 <richardschwerdtfeger> richardschwerdtfeger has joined #svg
15:47:26 <richardschwerdtfeger> richardschwerdtfeger has joined #svg
16:01:27 <richardschwerdtfeger> richardschwerdtfeger has joined #svg
17:06:49 <pdr__> svgwg is rocking it for sticking with the pathseg removal.
19:49:36 <krit> commit 7d2ff7e2f7a1fd55f152f6b308f695915a814408
19:49:37 <krit> Author: Cameron McCormack <cam@mcc.id.au>
19:49:37 <krit> Date:   Fri Feb 13 22:13:02 2015 +1100
19:49:37 <krit>     Markers module.
19:49:37 <krit> commit ce33635151342971e99b63c2cf63db8cb82a9e7e
19:49:37 <krit> Author: cconcolato <cyril.concolato@telecom-paristech.fr>
19:49:37 <krit> Date:   Fri Feb 13 11:39:52 2015 +0100
19:49:37 <krit>     fix broken markup
19:49:37 <krit> commit 74e23360c8d7460facb61ef92f7b5919e7518cc3
19:49:37 <krit> Author: Dirk Schulze <dschulze@chromium.org>
19:49:37 <krit> Date:   Fri Feb 13 21:27:37 2015 +1100
19:49:37 <krit>     Initial marker spec
19:49:50 <krit> heycam|away: I was ~1h earlier ;)
20:24:28 <tantek> tantek has joined #svg
22:00:14 <roc> roc has joined #svg
22:01:16 <heycam> trackbot, start telcon
22:01:18 <trackbot> RRSAgent, make logs public
22:01:18 <Zakim> Zakim has joined #svg
22:01:20 <trackbot> Zakim, this will be GA_SVGWG
22:01:20 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
22:01:21 <trackbot> Meeting: SVG Working Group Teleconference
22:01:21 <trackbot> Date: 13 February 2015
22:01:44 <heycam> Chair: Cameron
22:02:03 <heycam> Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Agenda_proposals
22:04:45 <stakagi> stakagi has joined #svg
22:05:26 <cyril> cyril has joined #svg
22:12:57 <rossen_syd> rossen_syd has joined #svg
22:18:33 <richardschwerdtfeger> richardschwerdtfeger has joined #svg
22:22:18 <BogdanBrinza> BogdanBrinza has joined #svg
22:22:44 <BogdanBrinza> scribe: BogdanBrinza
22:22:52 <BogdanBrinza> scribeNick: BogdanBrinza
22:23:40 <BogdanBrinza> topic is SVG Markers
22:23:46 <heycam> topic: SVG Markers
22:24:04 <heycam> https://svgwg.org/specs/markers/
22:24:08 <heycam> https://svgwg.org/specs/marker/
22:24:12 <Tav> Tav has joined #svg
22:24:27 <BogdanBrinza> heycam: Both Dirk and I took first step o producing first spec version for SVG Marker Level 1
22:25:08 <BogdanBrinza> heycam: The question is - is this ready for first publish working draft
22:25:33 <BogdanBrinza> Rossen: In CSS WG the rule is you have a short name - which is stated on the module
22:26:00 <BogdanBrinza> Rossen: so that in mailing list you reference this and a page with issues
22:26:15 <BogdanBrinza> heycam: So in the end we should combine two versions
22:26:32 <BogdanBrinza> krit: We should decide on short name
22:26:55 <BogdanBrinza> shane: so markers would work nice and align with CSS
22:27:07 <BogdanBrinza> Tav: should we have a Level 2 already?
22:27:30 <BogdanBrinza> heycam: does everybody agree that knockout should be in L2?
22:27:46 <BogdanBrinza> Rossen: in FPWD we can have it and then split if needed. no reason to push this off
22:28:04 <BogdanBrinza> cyril: What about section 9? how markers are rendered?
22:28:29 <BogdanBrinza> heycam: I just missed copied that initially - will add this soon
22:28:52 <BogdanBrinza> heycam: so the current approach is to copy all stuff we had in old spec at the moment
22:29:34 <BogdanBrinza> shane: it should be fine to use either
22:30:01 <cyril> RRSAgent, draft minutes
22:30:01 <RRSAgent> I have made the request to generate http://www.w3.org/2015/02/12-svg-minutes.html cyril
22:30:29 <BogdanBrinza> Rossen: again, the rule we follow in CSS is simple - if you're extending 2.1 you copy whole section and start extending
22:31:03 <BogdanBrinza> Rossen: 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
22:31:14 <BogdanBrinza> birtles: As an author I don't like the deltas
22:31:35 <birtles> (because I have to look up two specs)
22:32:07 <BogdanBrinza> heycam: so what are we doing? deltas / no deltas?
22:32:16 <BogdanBrinza> Rossen: let's agree on consistency
22:32:40 <BogdanBrinza> cyril: is there a pointer in CSS that goes from L2 to L3?
22:32:46 <BogdanBrinza> Rossen: not really
22:33:17 <BogdanBrinza> cyril: this might be confusing if you want to find the latest version - google will give you not the latest
22:33:41 <BogdanBrinza> Rossen: CSS snapshots address this and everything that is up to date at certain moment
22:34:09 <BogdanBrinza> Tav: pointer up might be useful
22:34:17 <BogdanBrinza> cyril: pointer to a stable URL might be useful
22:35:11 <BogdanBrinza> RESOLUTION: Publish SVG Markers Level 1 as FPWD
22:36:16 <BogdanBrinza> RESOLUTION: All specs would have a pointer to a stable SVG summary spec (snapshot) that lists the status of all modles
22:36:53 <BogdanBrinza> 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
22:37:23 <BogdanBrinza> Rossen: and you're going to move the section about rounding the markers?
22:37:29 <BogdanBrinza> heycam: knockouts?
22:37:37 <BogdanBrinza> Rossen: no details about the rendering
22:37:42 <BogdanBrinza> heycam: yes, I'll move this in
22:38:14 <BogdanBrinza> heycam: So remaining on the agenda is next F2F meeting, motion path animation and couple of Tav topics
22:38:28 <BogdanBrinza> shane: didn't we decide we won't talke about motion path?
22:38:44 <BogdanBrinza> krit: yes
22:38:52 <richardschwerdtfeger> richardschwerdtfeger has joined #svg
22:38:57 <BogdanBrinza> Rossen: where we left on remaining issues is
22:39:10 <BogdanBrinza> Rossen: we need to sync with Tav on remaining shapes issues
22:39:24 <heycam> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Open_issues
22:39:26 <BogdanBrinza> Rossen: next pat is painting where we took issues related to markers
22:39:47 <BogdanBrinza> we decided miter limits, arcs and remaining are stroking issues
22:40:30 <BogdanBrinza> Rossen: so the discussion was should we keep strokes in SVG2 or move to a new spec and fix the issues on fixed timelines
22:40:57 <BogdanBrinza> heycam: strokes are pretty much the same level of readiness as markers - so it should be also splittable if we want to
22:41:25 <BogdanBrinza> Rossen: this is great sign that SVG2 spec moved as set of modules
22:41:43 <BogdanBrinza> ed: so how do you want to do split? move jsut new things or everything?
22:42:02 <BogdanBrinza> Rossen: we should still move stroke the same way we moved markers
22:42:38 <BogdanBrinza> Rossen: so when we clean SVG2 strokes sections we should add extensions since 1
22:43:15 <BogdanBrinza> Rossen: when we ship SVG2 we'll have a section about stroking and new behavior goes to a separate spec
22:43:29 <BogdanBrinza> Rossen: and we can move or keep the new wording
22:43:38 <BogdanBrinza> heycam: it might be easier to take the whole section
22:44:09 <BogdanBrinza> Rossen: so who would be editor beside you?
22:44:44 <BogdanBrinza> heycam: there are stroke-dashcorner, miter-limit, arcs
22:44:56 <BogdanBrinza> birtles: what about variable stroke width?
22:45:29 <birtles> s/birtles: what about variable stroke width?/someone: what about variable stroke width?/
22:45:44 <birtles> birtles: that got deferred because I don't have time to work on it at the moment
22:46:03 <BogdanBrinza> 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
22:46:15 <BogdanBrinza> heycam: there are number of issues and discussions those features need
22:46:50 <BogdanBrinza> heycam: so it would be useful to have implementors to try those features to provide feedback
22:47:15 <BogdanBrinza> Tav: Inkscape has prototype for arcs, not yet implementing dashing
22:47:32 <BogdanBrinza> Rossen: does anybody has implementation for stroke-dashing?
22:47:46 <BogdanBrinza> all: there are no current implementations of dagshin
22:47:55 <BogdanBrinza> s/dagshin/dashing
22:48:12 <BogdanBrinza> Rossen: so it would be good candidate to separate
22:48:44 <BogdanBrinza> Rossen: so arcs can live in current spec
22:48:54 <BogdanBrinza> heycam: we can have features at risk in the spec
22:49:10 <BogdanBrinza> heycam: so we're moving this decision a bit earlier
22:49:22 <BogdanBrinza> Tav: so why would be pain-order at risk?
22:49:35 <BogdanBrinza> heycam: it's not - it's example of feature not at risk
22:49:59 <BogdanBrinza> Tav: so what about multiple stroke width?
22:50:16 <BogdanBrinza> heycam: it's a new and can be moved
22:50:36 <BogdanBrinza> krit: so multiple stroke width can go with multiple stroke layers
22:51:29 <BogdanBrinza> heycam: unless we want to decide how we want to ship with / without multiple stroke width
22:51:37 <BogdanBrinza> nikos: agree
22:51:53 <BogdanBrinza> Rossen: so in that case who is going to be the editor of SVG stroking
22:52:05 <BogdanBrinza> heycam: it's currently all features I've added
22:52:13 <BogdanBrinza> Rossen: so Cameron and Dirk?
22:52:33 <BogdanBrinza> cyril: I have a question regarding naming
22:52:47 <BogdanBrinza> cyril: so we went with SVG Markers Level 1
22:53:09 <BogdanBrinza> Rossen: every module starts with Level 1 unless you're extending existing one
22:53:17 <BogdanBrinza> Tav: so what is extending in this case?
22:54:15 <BogdanBrinza> someone: so there was a initial confusion with CSS3 because it became a buzz word
22:54:26 <BogdanBrinza> krit: but we can start with Level 1 here
22:54:52 <BogdanBrinza> heycam: Let's stick with Level 1
22:55:06 <BogdanBrinza> cyril: so you have SVG 2 and Markers Level 1
22:55:20 <BogdanBrinza> cyril: wouldn't they assume it's based on SVG 1?
22:55:34 <BogdanBrinza> shane: people who you're talking about wouldn't read the spec
22:56:03 <BogdanBrinza> shane: and the target audience already understands that state and what is based on what
22:56:20 <BogdanBrinza> Rossen: for now let's not give them many levels
22:56:38 <BogdanBrinza> birtles: that's wonderful
22:56:59 <BogdanBrinza> Rossen: so SVG strokes / stroking / else?
22:57:17 <BogdanBrinza> all: SVG Strokes
22:58:10 <BogdanBrinza> RESOLUTION: Create new spec SVG Strokes with heycam and krit as editors
22:58:30 <BogdanBrinza> Rossen: can we move to FPWD?
22:58:43 <BogdanBrinza> heycam: I'd like to check the text and we can review after taht
22:58:48 <BogdanBrinza> s/taht/that
22:59:10 <BogdanBrinza> all: we would be happy to resolve to publish
22:59:28 <BogdanBrinza> RESOLUTION: Publish FPWD of SVG Strokes
22:59:59 <BogdanBrinza> Rossen: that is pretty much all issues Cameron brought up
23:00:23 <BogdanBrinza> Rossen: so we currently have two new modules and remaining issues. What else is blocking?
23:00:38 <BogdanBrinza> heycam: existing issues and editoral changes
23:01:08 <BogdanBrinza> heycam: so in order to move forward we might need to understand amount of editorial work and assign
23:01:17 <BogdanBrinza> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_readiness_assessment
23:02:45 <BogdanBrinza> Rossen: so let's take a look at the sections in red currently
23:03:06 <BogdanBrinza> krit: so document structure?
23:04:10 <BogdanBrinza> Rossen: give me one second to log and put owners names to chapters
23:04:59 <BogdanBrinza> Rossen: ed you mentioned you can use help from somebody?
23:05:32 <BogdanBrinza> ed: Rich send a mail that there might be changes to better align with HTML and provide better accessibility
23:05:51 <BogdanBrinza> ed: there shouldn't be major issues, but need to go through all
23:06:11 <BogdanBrinza> ed: the major one - use alignment with web components (Tav)
23:06:23 <BogdanBrinza> s/use/<use>
23:06:29 <ed> s/(Tav)/TabAtkins/
23:06:59 <BogdanBrinza> ed: the rest are DOM interfaces, mostly clarifications
23:07:37 <BogdanBrinza> Rossen: API design is not somethign to blaze through
23:07:55 <BogdanBrinza> ed: this is not API design - this is clarifications
23:08:19 <BogdanBrinza> heycam: I'd like to have each chapter to have a single point of contact
23:09:30 <BogdanBrinza> Rossen: there is still decent number of issues on Document structure
23:09:42 <BogdanBrinza> ed: we did resolve some issues on F2F
23:10:21 <BogdanBrinza> Rossen: suggestion - can you take a first pass at issues and editorials and bring this back to WG discussion
23:11:13 <BogdanBrinza> Rossen: on Document structure, Erik is primary owner, TabAtkins would help with <use> and rest is mostly editorial changes
23:11:29 <BogdanBrinza> Rossen: next one is Text and has a clear owner - Tav
23:11:44 <BogdanBrinza> Tav: yes, rest of the issues can be addressed pretty soon
23:12:17 <BogdanBrinza> Rossen: looking through the spec - we knocked most of them yesterday and at this point it's mostly cleaning up
23:12:36 <BogdanBrinza> Tav: for first pass I can take a look and get back with any outstanding issues
23:13:12 <BogdanBrinza> Rossen: Paining, etc - most of the issues have been moved to seprate specs, so cleaning out would give us a clean state
23:13:35 <BogdanBrinza> Rossen: the owner was still heycam?
23:13:37 <BogdanBrinza> heycam: yes
23:14:14 <BogdanBrinza> Rossen: next Paint Servers. There were issues on mesh gradients not in heycam's list?
23:14:34 <BogdanBrinza> Tav: those are minor issues. Inkscape has mesh gradients implementation for 3 years
23:15:16 <BogdanBrinza> Rossen: so in that case - after cleanup driven by Tav we can take another look and get help
23:16:24 <BogdanBrinza> Rossen: Basic Data Types - owner heycam and he has a good handle on this one
23:16:36 <BogdanBrinza> Rossen: next Styling
23:16:48 <BogdanBrinza> heycam: this might be in poor state and would need rewrite
23:17:08 <BogdanBrinza> heycam: I think what this chapter should become is description on which CSS modules are required
23:17:26 <BogdanBrinza> heycam: and description of presentation attributes
23:17:37 <BogdanBrinza> Rossen: why this is not part of integration chapter?
23:18:49 <BogdanBrinza> heycam: this chapter currently is describing how other things are used in SVG
23:19:06 <BogdanBrinza> Rossen: this is an inverse of integration chapter
23:19:39 <BogdanBrinza> krit: we also write what specifications we rely on CSS
23:19:55 <BogdanBrinza> heycam: we should put specifications SVG relies on
23:21:05 <BogdanBrinza> Rossen: so can we assign the owner to clean this and decide the struecture of this one?
23:21:15 <BogdanBrinza> heycam: I would like to do that
23:21:58 <BogdanBrinza> Rossen: we're having to much on heycam, but let's try this and on next telcons learn what we can do to help
23:24:01 <BogdanBrinza> BogdanBrinza: I can take remaining yellow ones
23:25:36 <BogdanBrinza> BogdanBrinza: so Paths, Embedded content are on me with help from WG
23:25:53 <BogdanBrinza> Rossen: next introduction section - cyril
23:26:18 <BogdanBrinza> nikos: Rendering model - that should be me
23:26:34 <BogdanBrinza> Rossen: next SVG Layout properties
23:26:37 <BogdanBrinza> krit: that's me
23:29:04 <BogdanBrinza> Rossen: Basic shapes - Rossen
23:29:37 <BogdanBrinza> krit: Color section would go entirely with additional work from TabAtkins
23:30:30 <BogdanBrinza> Rossen: Clipping and masking - krit, nikos
23:30:41 <BogdanBrinza> all: Filter effects are gone
23:30:43 <richardschwerdtfeger> richardschwerdtfeger has joined #svg
23:31:08 <BogdanBrinza> cyril: Linking makes sense to keep with Interactivity
23:31:37 <BogdanBrinza> s/Interactivity/Embedded content
23:32:08 <BogdanBrinza> BogdanBrinza: so Linking goes to BogdanBrinza as well
23:33:31 <BogdanBrinza> Rossen: Animations - birtles
23:33:56 <BogdanBrinza> Rossen: Scripting might be close to Animations
23:34:34 <BogdanBrinza> birtles: might not be able to take it before April
23:34:43 <BogdanBrinza> Rossen: ok, BogdanBrinza and Rossen will take it
23:35:14 <BogdanBrinza> Rossen: Metadata - owner ed pending merge with document
23:35:41 <BogdanBrinza> ACTION ed to merge Metadata chapter with Document structure
23:35:41 <trackbot> Created ACTION-3751 - Merge metadata chapter with document structure [on Erik Dahlström - due 2015-02-20].
23:36:42 <BogdanBrinza> ACTION krit to remove Backwards Compatibility
23:36:42 <trackbot> Created ACTION-3752 - Remove backwards compatibility [on Dirk Schulze - due 2015-02-20].
23:37:51 <BogdanBrinza> Rossen: Extensibility - I can take this
23:38:43 <BogdanBrinza> ACTION BogdanBrinza to add Addendums to the SVG readiness table
23:38:44 <trackbot> Created ACTION-3753 - Add addendums to the svg readiness table [on Bogdan Brinza - due 2015-02-20].
23:39:36 <heycam> -- 15 min break --
23:39:59 <BogdanBrinza> ACTION BogdanBrinza summarize owners for chapters in https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_readiness_assessment
23:40:00 <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].
00:03:31 <Zakim> Zakim has left #svg
00:14:20 <BogdanBrinza> TOPIC: Timeline for SVG2 and modules
00:15:23 <BogdanBrinza> Rossen: how about we put timelines/cap on chapters
00:15:37 <BogdanBrinza> Rossen: next telcon is not goign to happen in next two weeks
00:16:46 <BogdanBrinza> Rossen: so owners of the chapter need to put items on the agenda and highlight most critical issues
00:17:31 <BogdanBrinza> heycam: we might not cover all things we have on the next call
00:18:46 <BogdanBrinza> Rossen: is there anyone who believes we won't meet 3 weeks for having all of the assessments and starting actual work?
00:19:50 <BogdanBrinza> heycam: by March 5th we should have those things listed in actionable state
00:20:58 <BogdanBrinza> heycam: there are couple Appendicies I would propose to remove
00:21:14 <BogdanBrinza> heycam: Internatialization support appendix
00:21:27 <heycam> https://svgwg.org/svg2-draft/i18n.html
00:21:50 <BogdanBrinza> cyril: I can add things in Introduction chapter?
00:22:19 <BogdanBrinza> RESOLUTION: Remove the Appendix F: Internationalization Support
00:22:21 <heycam> https://svgwg.org/svg2-draft/minimize.html
00:22:32 <BogdanBrinza> ed: next one Appendix G
00:23:03 <BogdanBrinza> RESOLUTION: Remove Appendix G: Minimizing SVG File Sizes
00:23:21 <BogdanBrinza> heycam: Next one Appendix N: Media Type Registration for image/svg+xml
00:23:34 <BogdanBrinza> heycam: Chris would check where that links to
00:23:48 <BogdanBrinza> ed: this might point to latest TR version of it
00:24:14 <cyril> iana link: [http://www.w3.org/TR/SVG/mimereg.html]
00:24:35 <cyril> check this page: http://www.iana.org/assignments/media-types/media-types.xhtml#image
00:24:57 <BogdanBrinza> ACTION ChrisL to check and remove Appendix N: Media Type Registration for image/svg+xml
00:24:57 <trackbot> Created ACTION-3755 - Check and remove appendix n: media type registration for image/svg+xml [on Chris Lilley - due 2015-02-21].
00:26:40 <BogdanBrinza> ed: Appendix L: IDL Index - do we need this?
00:26:47 <BogdanBrinza> krit: this is just an index
00:27:19 <BogdanBrinza> heycam: IDL definitions would include all, maybe we don't need them in two places?
00:28:41 <BogdanBrinza> heycam: so let's leave that in place
00:28:45 <heycam> https://svgwg.org/svg2-draft/access.html
00:28:56 <BogdanBrinza> heycam: next one Appendix E: Accessibility Support
00:29:58 <Rossen> ping
00:30:46 <BogdanBrinz> BogdanBrinz has joined #svg
00:30:51 <Rossen> ping
00:31:00 <BogdanBrinz> ACTION Rich to define the further steps for Appendix E: Accessibility Support
00:31:01 <trackbot> Created ACTION-3756 - Define the further steps for appendix e: accessibility support [on Richard Schwerdtfeger - due 2015-02-21].
00:31:14 <BogdanBrinz> TOPIC: SVG2 WD publication
00:31:48 <BogdanBrinz> RESOLUTION: SVG WG to publish SVG2 WD
00:33:49 <BogdanBrinz> TOPIC: Next F2F meetings
00:33:53 <ed> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015
00:34:05 <ed> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015
00:34:12 <ed> https://www.w3.org/2002/09/wbs/19480/Linkoping2015
00:34:57 <ed> please sign up
00:34:59 <BogdanBrinz> ed: What is our next after Linkoping?
00:35:04 <BogdanBrinz> Tav: what are the options?
00:35:09 <BogdanBrinz> Rossen: Paris with CSS WG
00:36:02 <BogdanBrinz> all: also SVG Open
00:40:42 <BogdanBrinz> RESOLUTION: Next SVG F2F after June would be TPAC
00:42:43 <heycam> Scribe: Cameron
00:42:46 <heycam> ScribeNick: heycam
00:42:57 <heycam> Topic: Smoothing in mesh gradients
00:43:05 <Tav> http://tavmjong.free.fr/SVG/MESH_SMOOTHING/index.html
00:45:49 <heycam> Tav: coons patch meshes suffer from a flaw
00:45:56 <heycam> ... the derivative of the colour profile can have jumps at patch boundaries
00:46:03 <heycam> ... leading to visible artifacts, bright lines, etc. at patch corners
00:46:19 <heycam> ... this is enhanced by mach banding, where your eye is caught by changes in the color profile
00:46:32 <heycam> ... you can see that the color distribution is continuous, but appears to your eyes that it has bright white bands
00:46:43 <heycam> ... the way illustrator and coreldraw handle this is they smooth their meshes
00:47:00 <heycam> ... for adobe, when you export the mesh, it subdivides a patch into an 8x8 array of patches
00:47:10 <heycam> nikos: I think it might be adaptive
00:47:17 <heycam> Tav: at least in one example I've seen 8x8
00:47:20 <heycam> nikos: certainly a lot of patches
00:47:24 <heycam> Tav: you can see it on the screen
00:47:28 <heycam> ... you can see the little patches
00:47:43 <heycam> ... it'd be nice to be able to do that smoothing in SVG, then you can reduce the number of patches in the file
00:47:49 <heycam> nikos: and it means you don't lose the information in the editor
00:47:58 <heycam> Tav: so I did some experiments with various smoothing algorithms
00:48:02 <heycam> ... I show them in 1D
00:48:12 <heycam> ... the top one on that page above is what you get out of a coons patch mesh now
00:48:16 <heycam> ... you can see the discontinuity
00:48:40 <heycam> ... the first thing to try is a hermite, a simple smoothing algorithm where the deriviative across the boundary is zero
00:49:00 <heycam> ... it makes the profile within the patch not to be linear
00:49:23 <heycam> ... looks wavy
00:49:30 <heycam> ... next is to try Catmull-Rom interpolation
00:49:43 <heycam> ... that gives you the hermite function, but what you need is the tangent across the boundaries
00:49:51 <heycam> ... the next three examples on the page does that
00:49:55 <heycam> ... the difference between them is the end treatment
00:50:39 <heycam> ... one doubles the first/last points, one reflects them (the n+1 point is a reflection of the n-1 point)
00:50:53 <heycam> ... the third is insisting that the polynomial is a quadratic
00:51:06 <heycam> ... so you have the magnitude of two points on one side, and you have a tangent. you can fit a quadratic to that.
00:51:15 <heycam> ... that seems to be what's happening in illustrator
00:51:26 <heycam> cyril: I remember reading a paper explaining what adobe was doing
00:51:31 <heycam> nikos: by Sun
00:51:58 <heycam> Tav: the next problem is that Catmull-Rom curves can produce minimum and maximum values within a patch
00:52:27 <heycam> ... 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
00:52:31 <heycam> ... it gives you a monotonic profile
00:52:51 <heycam> ... so you adjust the tangents to get that
00:52:52 <heycam> ... now, looking at 2D
00:53:30 <heycam> ... there is a bicubic-interpolation you can do, which I've implemented in inkscape
00:53:42 <heycam> [shows a demo]
00:55:26 <heycam> ... my proposal is to have a patch have a type, default would be coons patch, second type would be smooth
00:56:09 <heycam> nikos: this doesn't let you control the gradient across the boundary
00:56:16 <heycam> ... if you want a sharp boundary you couldn't achieve it
00:56:21 <heycam> Tav: you could by adding an extra row in
00:56:25 <heycam> nikos: it'd be nice to have a control
00:56:29 <heycam> Tav: that complicates things quite a bit
00:56:32 <heycam> ... this is just one flag
00:56:37 <heycam> ... the algorithm is here, fairly easy to implement
00:56:44 <heycam> nikos: in Illustrator, can you control the gradient?
00:56:45 <heycam> cyril: no
00:56:55 <heycam> Tav: this matches Illustrator's behaviour
00:57:09 <heycam> cyril: calling it "smooth".... "bicubic" would be clearer
00:57:16 <heycam> Tav: I'm fine with that
00:57:24 <heycam> Tav: my proposal is to add this and spec it all out
00:57:31 <heycam> ... I've got the formulas and prototype implementation
00:57:39 <heycam> cyril: you'll turn off all the other modes in inkscape?
00:57:43 <heycam> Tav: yes that was just for demonstration
00:58:43 <heycam> 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
00:59:07 <heycam> nikos: the reason we were talking about having different elements was that otherwise you'd have different attributes depending on the value of type=""
00:59:17 <heycam> ... if we had smoothing and we wanted to add control points for the smoothing...
00:59:23 <heycam> Tav: I don't see it ever happening
00:59:30 <heycam> ... you'd need control points for the three different colours?
00:59:40 <heycam> ... that's an order of magnitude more complicated in editing
00:59:47 <heycam> nikos: if you give them the raw control, yes it's a lot of work
00:59:52 <heycam> ... but I think you an simplify that through UI for authors
01:00:01 <heycam> ... having a handle to control how far out something is spread would be useful I think
01:00:13 <heycam> ... I just don't want to not have the option to do that later, or for it to be a confusing syntax later
01:00:19 <heycam> Tav: do you have an idea what syntax you would use?
01:00:24 <heycam> nikos: not at the moment
01:01:10 <heycam> ... even if you controlled the channels separately for the handles, it's not nice for authors, but could be for converted content
01:01:14 <heycam> ... vectorised photographs for example
01:01:32 <heycam> Tav: I'm worried that that will delay meshes
01:01:36 <heycam> nikos: I don't want to do that
01:01:39 <heycam> ... I really like this proposal
01:01:41 <heycam> ... we should go with it
01:01:51 <heycam> ... I just want to keep the door open to extending without running into nasty syntax in the ftureu
01:01:59 <heycam> Tav: you'd have to add a new thing to the patch
01:02:02 <heycam> ... dx/dy for each of the colours
01:02:15 <heycam> cyril: derivativecontrol="coords"
01:02:25 <heycam> nikos: would rather have a different element when you have a different mode
01:02:38 <heycam> cyril: is this part of the SVG 2 spec?
01:02:45 <heycam> Tav: it's all worked out, I'd just add it to SVG 2
01:03:08 <heycam> nikos: I'm OK with having a type="" I think
01:03:32 <heycam> ... if you have something with extra handles you could have a new element later
01:03:34 <heycam> ... ok
01:04:23 <heycam> RESOLUTION: We will have a type="smooth-bicubic" or similar on <patch>
01:04:49 <heycam> ACTION: Tav to add <patch type="smooth-bicubic"> to the spec.
01:04:49 <trackbot> Created ACTION-3757 - Add <patch type="smooth-bicubic"> to the spec. [on Tavmjong Bah - due 2015-02-21].
01:06:00 <heycam> nikos: because the control is on the patch, you can have a mesh made of smooth and coons patches
01:06:06 <heycam> heycam: is that useful?
01:06:53 <heycam> Tav: no the type="" goes on the <mesh>
01:07:04 <heycam> ACTION-3757: Actually type="" is on the <mesh> element.
01:07:04 <trackbot> Notes added to ACTION-3757 Add <patch type="smooth-bicubic"> to the spec..
01:09:10 <cyril> http://en.wikipedia.org/wiki/Monotone_cubic_interpolation
01:10:38 <heycam> ACTION: Cyril to investigate web-platform-tests for SVG test suite and write up a wiki page
01:10:39 <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].
01:10:55 <stakagi> https://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_Overview
01:11:53 <stakagi> last update : June 2012
01:11:58 <heycam> stakagi, :)
01:12:02 <heycam> stakagi, that would be a good page to update
01:16:32 <cyril> http://testthewebforward.org/docs/
01:16:54 <cyril> https://github.com/w3c/web-platform-tests
01:17:13 <cyril> https://github.com/w3c/test-results/
01:17:34 <heycam> Topic: outermost svg element definition
01:17:54 <birtles> https://svgwg.org/svg2-draft/struct.html#TermCurrentInnermostSVGDocumentFragment
01:18:54 <heycam> <html><svg><foreignObject><html><svg><svg>
01:19:35 <heycam> [reads out definitions of "current innermost" and friends]
01:23:58 <heycam> birtles: I think we can drop half of these definitions
01:24:03 <heycam> krit: depends where they're used
01:24:18 <heycam> ed: perhaps this chapter is not where they're used first
01:25:50 <heycam> ACTION: Brian to fix outermost/innermost svg element definitions, checking where they're used currently
01:25:50 <trackbot> Created ACTION-3759 - Fix outermost/innermost svg element definitions, checking where they're used currently [on Brian Birtles - due 2015-02-21].
01:26:11 <heycam> -- adjourned --
01:26:39 <heycam> but first...
01:26:42 <heycam> Topic: motion path
01:26:51 <heycam> shane: couple of minor issues
01:26:55 <krit> http://dev.w3.org/fxtf/motion-1/
01:27:06 <heycam> ... some of these are adding more details/examples
01:27:20 <heycam> ... another is what happens if the position is negative or exceeds the motion path length
01:27:29 <heycam> ... we've decidd that if it's a closed path it wraps, if it's an open path it clamps
01:27:36 <heycam> ... we have one about "more natual names" for auto and reverse
01:27:42 <heycam> ... an issue about how to get the position in more detail
01:27:52 <heycam> ... an issue about path transform computation needing to be more explicit
01:28:05 <heycam> ... and finally do we need to specify an origin of an element in motion so it can be positioned appropriately
01:28:31 <heycam> ... I think of all of those, the only ones we don't have a good answer for is the origin one
01:28:42 <heycam> ... I think we should just use transform-origin in this case
01:28:49 <heycam> ... it says in the issue we probably shouldn't, but we should!
01:28:57 <heycam> ... the motion is going to end up in the transform list anyway
01:29:05 <heycam> cyril: a problem is that the motion animation is an additional transform
01:29:20 <heycam> ... you could combine those two; if you think they have the same origin...
01:29:30 <heycam> shane: the motion path spec isn't a clean drop in replacement for animateMotion
01:29:44 <heycam> ... you need to be careful about order of application
01:29:46 <heycam> ... and origin setting
01:29:58 <heycam> ... so this is more what the origin should be for a specified motion path use should be
01:30:06 <heycam> ... I think the simplest thing to do is make it the same as transform-origin
01:30:26 <heycam> ... if you're generating equivalent behaviour for <animateMotion>, you might need to fiddle with some translations
01:30:38 <heycam> krit: I think we will state this usse on the mailing list again
01:30:48 <heycam> ... but here we just want to note all the open issues
01:31:06 <heycam> shane: in the absence of significant discussion, I would say transform-origin we should proceed with
01:31:33 <heycam> ... given this is the only substantive issue, I am asking whether we should we can have a FPWD of motion animation
01:32:02 <heycam> RESOLUTION: We agree on a FPWD of Motion Path Module Level 1.
01:32:10 <heycam> -- adjourn for real --
01:32:17 <heycam> RRSAgent: make minutes
01:32:17 <RRSAgent> I have made the request to generate http://www.w3.org/2015/02/12-svg-minutes.html heycam
03:12:27 <roc> roc has joined #svg
04:26:20 <krit> Note: I plan to rename "basic shapes"/"shapes" to "shape elements". The term is used in the spec as well already but makes more sense and does not collide with other definitions.
05:51:32 <jdaggett> jdaggett has joined #svg
07:56:28 <Tav> Tav has joined #svg
09:21:03 <roc> roc has joined #svg
11:16:01 <jdaggett> jdaggett has joined #svg
11:50:41 <jdaggett> jdaggett has joined #svg
14:08:29 <richardschwerdtfeger> richardschwerdtfeger has joined #svg
22:34:40 <nikos> nikos has joined #svg
00:41:06 <jdaggett> jdaggett has joined #svg
01:17:02 <jdaggett> jdaggett has joined #svg
02:11:04 <roc> roc has joined #svg
06:56:56 <heycam> krit, sounds fine to me
06:57:17 <heycam> krit, rename the chapter from "Basic Shapes" to "Shapes" too?
07:34:22 <shepazu> shepazu has joined #svg
07:55:25 <krit> heycam: Shape elements unless there is more than that in the chapter
07:56:17 <heycam> krit, there isn't. though we have a "Paths" chapter and not a "Path elements" chapter
07:56:31 <heycam> I think "Shapes" would fit better
08:04:46 <krit> no objection
08:08:12 <heycam> krit, more than 24 hours later?
08:08:25 <krit> yes, 27 all together
08:08:37 <heycam> long journey :/
08:08:37 <krit> 5h in Munich alone 2 in Singapore
08:09:31 <heycam> I had a 13h stopover in Melbourne for me ;)
08:22:26 <krit> heycam: ?
08:22:38 <krit> oh, you flew back and then to Oakland?
08:22:43 <heycam> Auckland
08:22:44 <heycam> yeah
08:22:49 <krit> ah right ;)
08:23:01 <krit> used to the other spelling :P
08:23:09 <heycam> it's a bit further away ;)
08:23:34 <krit> yes :) and likely not as pretty
08:35:04 <krit> heycam: could you please remind me if we decided to move multiple stroke layers into a new spec as well, or if that is just for the rest of the new features?
08:35:21 <krit> heycam: also, are you doing the work or should I do it?
08:35:26 <heycam> krit, hmm, I wonder if we didn't get back to that topic
08:35:31 <heycam> krit, I would need to check the minutes
08:35:53 <krit> heycam: we resolved on having a new spec at least called SVG Strokes
08:36:00 <krit> (with plural s)
08:36:17 <heycam> krit, yes. oh I remember now.
08:36:21 <krit> heycam: we can leave it in SVG2 for now and bring it up during the call
08:36:25 <heycam> the layers remain in the main spec
08:36:26 <heycam> yes
08:36:37 <heycam> as they were small and done
08:36:39 <krit> heycam: ok, shall I do it, or do you?
08:36:57 <heycam> krit, I can do it unless you want to
08:37:13 <krit> heycam: :) use a coin?
08:37:39 <heycam> krit, http://justflipacoin.com/
08:37:46 <heycam> krit, heads means I do it
08:37:50 <heycam> krit, tell me what it comes up as :)
08:38:00 <krit> Heads :/
08:38:10 <heycam> sounds like you really want to do it :p
08:38:25 <heycam> can you do it using the current build scripts?
08:38:33 <krit> heycam: no
08:38:37 <heycam> oh ;)
08:38:47 <krit> heycam: if you want to use the build script, you need to do it for now
08:38:57 <heycam> ok
08:39:06 <heycam> the current build scripts produce nicer looking output for the moment...
08:39:07 <krit> heycam: but it has no elements, so perfect for backside ;)
08:39:09 <heycam> so I do prefer it...
08:39:13 <heycam> that's true
08:39:26 <krit> how...
08:39:43 <krit> why auto correct from bikeshed to backside ?
08:39:59 <heycam> ?
08:40:04 <heycam> haha
08:40:14 <krit> OS X autocorrection
08:41:54 <heycam> funny
08:43:01 <krit> heycam: to PathSeg: I think this is a definite keeper. Please do not remove. So much has been removed already in order to follow browser implementations rather than setting a spec that might be the next best thing to cheese.
08:43:19 <krit> heycam: I guess negative comments can be expected though
08:43:30 <heycam> "next best thing to cheese"!
08:44:39 <krit> cheese smells ....
08:45:01 <heycam> smells .... great!
08:47:19 <heycam> krit, do you remember how you are authorized to push to the svgwg github repo?
08:47:32 <krit> heycam: hm, the SVG sizing thing we agreed on in Leipzig, where does that need to be in the spec?
08:47:48 <heycam> krit, for SVG in image? that should be integration.
08:47:56 <krit> I don't... maybe because I am member of W3C group?
08:48:06 <krit> heycam: ok
08:48:12 <krit> heycam: we should work on that :P
08:48:19 <heycam> krit, yeah that would be good!
08:50:05 <krit> heycam: maybe something for sweden, right after finishing SVG2
08:50:15 <heycam> krit, sure :)
08:50:32 <heycam> krit, well, we have the discussion/decision, just need to do it
08:50:33 <krit> heycam: and then we can collect the nobel price
08:50:37 <heycam> lol
09:52:06 <jet> jet has joined #svg
12:33:04 <plinss_away> plinss_away has joined #svg
12:33:43 <Rossen_away> Rossen_away has joined #svg
13:15:44 <jdaggett> jdaggett has joined #svg
14:52:21 <jdaggett> jdaggett has joined #svg
20:41:42 <shepazu> shepazu has joined #svg
20:44:00 <roc> roc has joined #svg
00:00:02 <jdaggett> jdaggett has joined #svg
00:33:21 <jdaggett_> jdaggett_ has joined #svg
09:04:39 <roc> roc has joined #svg
10:48:02 <jdaggett> jdaggett has joined #svg
14:27:52 <ed> in what? svg-size-onomics?
14:59:45 <cyril> cyril has joined #svg
17:01:14 <krit> ed: ?
17:01:31 <krit> ed: reading your mail, SVGPathSegment looks very similar to Path2D
17:01:49 <krit> ed: so maybe it is better to reuse Path2D
17:02:13 <krit> ed: and In a way I would like Path2D integration with SVGPathElement
17:02:35 <krit> ed: In any case, we need to know the use cases first to see if we address them
17:04:02 <krit> ed: https://html.spec.whatwg.org/multipage/scripting.html#path2d
17:04:30 <krit> ed: maybe at very least, any new API should implement CanvasPathMethods https://html.spec.whatwg.org/multipage/scripting.html#canvaspathmethods
17:04:45 <krit> ed: lets take that for SVG3 :)
17:08:35 <ed> krit: assuming there's a way to map all the path2d ops to svg syntax...
17:08:56 <ed> (or well, *a defined* way)
17:13:00 <krit> ed: agree with defined way
17:13:13 <krit> ed: doesn't need a 1:1 mapping IMO
17:13:26 <krit> ed: even though this would probably be preferred if possible
17:15:39 <ed> krit: sure
17:19:34 <ed> the draft api tried to factor in brian's wish for getting "an array" of values for easier scripting
17:21:08 <krit> ed: Path2D is meant as a direct-to-draw API
17:21:21 <krit> ed: no read back intended (on purpose)
17:25:06 <ed> krit: right, I'm not sure that would address the use-cases people in that thread have (judging by the examples there)
17:25:35 <krit> ed: yes, might be. As said, the would not prevent us from using CanvasPathMethods
17:26:37 <ed> krit: true
17:28:43 <krit> ed: IMO, a simple API that stringifies what an author has should be enough. Don't want to have anotehr verbose API for things that authors can easily handle themselves in the webplatform
23:32:08 <jdaggett> jdaggett has joined #svg
23:44:53 <jdaggett_> jdaggett_ has joined #svg
23:59:03 <jdaggett_> jdaggett_ has joined #svg
00:42:53 <shepazu> shepazu has joined #svg
00:51:08 <shepazu> shepazu has joined #svg
00:57:42 <jdaggett_> jdaggett_ has joined #svg
00:59:42 <shepazu> shepazu has joined #svg
01:42:41 <jdaggett> jdaggett has joined #svg
01:44:36 <shepazu> shepazu has joined #svg
02:03:48 <AlexD> AlexD has joined #svg
02:32:25 <AlexD> AlexD has joined #svg
03:14:54 <jdaggett> jdaggett has joined #svg
04:02:57 <AlexD> AlexD has joined #svg
08:05:27 <stakagi> stakagi has joined #svg
08:28:40 <MarkS> MarkS has joined #svg
10:31:28 <ed> now we're down to 19 chapters :)
10:32:17 <ed> if this trend continues we'll soon have more appendices than chapters
12:32:31 <jdaggett> jdaggett has joined #svg
15:33:26 <krit> ed: the opacity/masking chapter will disappear
15:33:42 <krit> ed: and merge with rendering
15:36:54 <krit> ed: heycam|away: btw. "Feature strings for the hasFeature method call" https://svgwg.org/svg2-draft/svgdom.html#FeatureStrings Does that stay in the spec?
15:37:30 <krit> oohhh: Relationship with DOM Level 2 CSS
15:38:18 <krit> "user agents must support all of the required interfaces defined in DOM Level 2 CSS" how could we get SVG1.1SE to REC?
15:38:20 <ed> krit: I think we should discuss dropping that chapter
15:38:29 <ed> (the feature strings one that is)
15:38:53 <krit> ed: Relationship with DOM Level 3 Events was edited by Rich IIRC
15:47:57 <krit> ed: heycam|away: We require XML conform SVG document. What if we keep the requirement but allow host languages to override requirements? (Which HTML5 does today anyway.)
18:37:34 <TabAtkins> krit: Why not just drop that requirement?  It comes for free from the XML serialization anyway; if you write invalid XML, it's not a valid document, and XML doesn't allow languages to override the processing.
18:38:16 <krit> TabAtkins: we do not have an SVG parser and the HMTL parser didn't work out in Blink... just to come up with one problem
18:38:42 <TabAtkins> krit: We have an *XML* parser in Blink, no?
18:38:58 <krit> TabAtkins: yes, and?
18:39:10 <TabAtkins> Then I don't understand your response.
18:39:26 <krit> TabAtkins: What I mean is that we still need XML as a requirement unless we write everything on our own (in the spec)
18:39:29 <TabAtkins> There's no such thing as "an SVG parser".  SVG-as-XML is parsed with the XML parser.
18:39:54 <krit> TabAtkins: right, and if you use XML parser you require XML valid documents
18:40:16 <TabAtkins> No, you don't.  *XML* requires XML valid documents.  The language built on top of XML doesn't have to care.
18:40:40 <TabAtkins> So you can drop any *explicit* requirements for a valid XML document from SVG.  That comes for free when you write SVG in the XML serialization.
18:41:47 <krit> TabAtkins: you can not take an external thing without following the requirement of it
18:42:09 <TabAtkins> ...I know. That's what I'm saying.
18:42:12 <krit> TabAtkins: using XML parser requires a valid XML document, SVG can't get away with it wihtout this requirement
18:42:48 <TabAtkins> I'm saying that SVG, *the spec document*, doesn't need to *explicitly require* that the XML document be valid.  Because that's a requirement of XML *already*.
18:43:16 <TabAtkins> An invalid XML document isn't an XML document at all.  It's a meaningless sequence of bytes, per the XML spec.
18:44:04 <TabAtkins> (Or it's an XML document that has recovered from an error, if the XML Error-Recovery effort ever gets serious.  And in that case there's no longer a requirement to be valid anyway.)
18:44:46 <TabAtkins> Requirements are transitive over references, basically.
18:50:07 <krit> TabAtkins: I guess I am ok with removing the XML valid requirement if we keep the SVG as XML document thing for stand alone SVGs and  allow host documents to set other requirements
18:51:36 <TabAtkins> You just have to say that the only standalone format the SVG spec currently defines is XML (and describe how that is changed into the SVG DOM; there's probably Infoset->DOM algo somewhere handy).  Any host language can define their own syntax for SVG whenever they want; the SVG spec doesn't have to care.
20:26:01 <heycam> krit, I agree with removing that "Feature strings for the hasFeature method call" given the DOM spec says hasFeature unconditionally returns true
21:36:22 <nikos> nikos has joined #svg
23:54:49 <jdaggett> jdaggett has joined #svg
01:15:54 <shepazu_> shepazu_ has joined #svg
02:31:57 <AlexD> AlexD has joined #svg
04:18:18 <nikos> I'm thinking we should move the definition of z-index to the rendering chapter - the painting chapter is more about painting individual elements rather than the document as a whole. Also I think it would be preferable to have it in one place rather than have it mentioned briefly in rendering and the detail in another chapter. Are others cool with this?
04:21:54 <heycam> nikos, sounds ok to me
04:24:41 <nikos> It rather neatly sorts out the 'should mention z-index here' issue in the rendering chapter ;)
04:39:42 <heycam> ah good :)
05:09:01 <heycam> krit, is that true (your retweet of gwhitworth)?
05:09:44 <krit> heycam: gwhitworth is an IE engineer
05:09:54 <heycam> krit, yes I know :)
05:10:08 <heycam> krit, that's why it would be big news if IE edge supported SMIL!
05:10:10 <krit> heycam: it is CSS animations/transitions
05:10:20 <krit> heycam: he didn't say that
05:10:22 <heycam> oh
05:10:48 <heycam> CSS targetting SVG elements, is it?
05:10:57 <heycam> *CSS Animations
05:11:18 <krit> heycam: right
05:12:02 <heycam> krit, ok that's more believeable
05:12:05 <heycam> time to calm down ;)
05:12:19 <krit> https://twitter.com/gregwhitworth/status/567914337018314755
05:12:32 <krit> which is cool too
05:21:49 <heycam> it is
05:42:23 <jdaggett_> jdaggett_ has joined #svg
05:45:56 <shepazu_> shepazu_ has joined #svg
08:17:35 <jdaggett_> jdaggett_ has joined #svg
10:50:00 <jdaggett> jdaggett has joined #svg