IRC log of svg on 2012-09-19

Timestamps are in UTC.

01:16:15 [jet]
jet has joined #svg
01:44:42 [thorton]
thorton has joined #svg
02:41:50 [glenn]
glenn has joined #svg
03:18:54 [glenn]
glenn has joined #svg
05:10:53 [Tav]
Tav has joined #svg
06:27:15 [birtles]
birtles has joined #svg
06:32:03 [konno]
konno has joined #svg
06:32:25 [cabanier]
cabanier has joined #svg
06:35:26 [Tav]
Tav has joined #svg
06:36:29 [heycam]
trackbot, start telcon
06:36:31 [trackbot]
RRSAgent, make logs public
06:36:31 [Zakim]
Zakim has joined #svg
06:36:33 [heycam]
Chair: Cameron
06:36:33 [trackbot]
Zakim, this will be GA_SVGWG
06:36:33 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
06:36:34 [trackbot]
Meeting: SVG Working Group Teleconference
06:36:35 [trackbot]
Date: 19 September 2012
06:36:46 [heycam]
06:39:02 [stakagi]
stakagi has joined #svg
06:39:06 [Cyril]
Cyril has joined #svg
06:39:14 [TabAtkins]
TabAtkins has joined #svg
06:39:57 [nikos]
nikos has joined #svg
06:40:03 [nikos]
scribenick: nikos
06:40:38 [nikos]
Topic: radialGradient @fr
06:41:02 [nikos]
ed: I have a couple of questions about the spec
06:41:15 [nikos]
... 1: is fr allowed to be negative?
06:41:19 [nikos]
... I think the thread decided no
06:41:29 [nikos]
2: should the focal point be constrained to be in the circle?
06:41:35 [nikos]
... do we want to be fully compatible with canvas or not?
06:41:44 [nikos]
TabAtkins: I think Canvas behaviour is bad
06:41:51 [nikos]
... whatever we do here I'd like to do it there too
06:42:10 [nikos]
cabanier: in Canvas you get a cone if drawing outside
06:42:35 [nikos]
TabAtkins: that behaviour doesn't make sense - there's a discontinuity in the behaviour for no good reason
06:43:24 [nikos]
heycam: would you ever want that effect?
06:43:27 [nikos]
TabAtkins: I don't think so
06:43:49 [andreas]
andreas has joined #svg
06:44:12 [nikos]
cabanier: all implementations come from PDF
06:44:38 [nikos]
cabanier: I think you should match what most people do
06:44:52 [nikos]
... you should do it in CSS as well
06:45:10 [nikos]
TabAtkins: it'
06:45:17 [nikos]
... s not good behaviour
06:46:04 [nikos]
cabanier: so how would you define radial gradients?
06:46:11 [nikos]
TabAtkins: I think the last colour should extend outside the plane
06:46:24 [nikos]
... or restrict them to clamp
06:46:33 [nikos]
cabanier: I think SVG should match Canvas
06:46:38 [nikos]
heycam: we do clamp right?
06:46:41 [nikos]
ed: yes
06:47:00 [nikos]
TabAtkins: radial gradients are too complex for CSS
06:47:08 [nikos]
... so what is ill defined about the clamping right now?
06:47:18 [TabAtkins]
s/radial gradients/mesh gradients/
06:48:01 [nikos]
TabAtkins: I don't think authors want it to extend, so I think it's better that we clamp
06:48:21 [nikos]
ed: a secondary issue - what happens if the radius cuts through the circle
06:48:51 [nikos]
TabAtkins: project out where the focal point would be. The definition should be in terms of the focal point and the fill shape
06:49:11 [nikos]
... which behaviour do we want? turn it into a cone or clamp?
06:49:31 [ed]
s/radius cuts through the circle/focal circle radius cuts through the other circle/
06:49:40 [nikos]
cabanier: I think it should match what everybody else is doing
06:50:33 [nikos]
ed: even if we wanted to have canvas behaviour we have to keep old behaviour when it's exactly on the circle
06:50:38 [nikos]
... so we don't break old content
06:51:42 [heycam]
06:54:37 [nikos]
heycam: I'm leaning towards allowing it outside the circle
06:56:05 [nikos]
TabAtkins: I'm not a fan of the cone effect
06:56:13 [nikos]
cabanier: I agree, but I think consistency is important
06:56:52 [nikos]
heycam: what happens when you put the focal point on the edge in Canvas?
06:57:12 [nikos]
cabanier: they don't have repeat so it's not a problem
06:57:35 [nikos]
ed: I think I agree that consistency with Canvas is important
06:58:45 [nikos]
Resolution: SVG radial gradients will align with Canvas for behaviour where the focal point is outside the circle
06:59:06 [nikos]
ed: for the case where it's exactly on the circle we are going to keep the old clamping behaviour for backwards compatibility?
06:59:21 [nikos]
... when the focal point is exactly on the circle
06:59:38 [nikos]
Tav: what colour space do you do the averaging in ?
06:59:48 [nikos]
TabAtkins: CSS takes the easy answer and converts to sRGBA
07:00:09 [nikos]
Tav: optically you would want to use linear
07:00:42 [nikos]
cabanier: the gradient doesn't interpolate linearly
07:00:59 [nikos]
TabAtkins: the averaging should be in the same colour space as the rest
07:01:48 [nikos]
... I think to get correct colours you average in the same colour space as you interpolate
07:03:37 [TabAtkins__]
TabAtkins__ has joined #svg
07:03:42 [TabAtkins__]
07:05:02 [nikos]
Action: Tav to specify radial gradient behaviour when the focal point is outside the circle
07:05:02 [trackbot]
Created ACTION-3374 - Specify radial gradient behaviour when the focal point is outside the circle [on Tavmjong Bah - due 2012-09-26].
07:05:16 [nikos]
Topic: Mesh Gradients
07:05:36 [Tav]
07:06:56 [nikos]
Tav: The basic issue with the gradients right now is how to handle non-smooth transitions between boundaries
07:06:58 [nikos]
... they cause banding
07:07:12 [nikos]
... that point of the transition looks brighter
07:07:26 [nikos]
... Adobe and Corel draw handle this by doing smoothing that's hidden from the user
07:07:34 [nikos]
... it gets exported as 8x8 patches in the PDF
07:07:42 [nikos]
... we could do what they do, but that would end with lots of patches
07:07:46 [nikos]
... or we try some kind of smoothing
07:08:09 [nikos]
... either automatic smoothing or we allow a more complex syntax that allows colours to be set at points on the handles or tensor points
07:08:20 [nikos]
heycam: is it like specifying easing?
07:09:07 [nikos]
Cyril: if you have two patches next to each other and you specify the colour derivatives at the shared points, then you have a continuous derivative and no banding
07:09:15 [nikos]
Tav drawing on board
07:09:37 [nikos]
Tav: If you have two patches, you want to smooth the join
07:10:16 [nikos]
... what I did is use auto smoothing by looking at the slope and use that to construct a curve
07:10:31 [nikos]
Cyril: the problem with that is the rendering of patches is not isolated
07:12:23 [nikos]
Tav: You could define colours at the control points and add tensor points
07:12:35 [nikos]
Cyril: generally that's not what people do, the colour is separate from the geometry
07:13:01 [nikos]
shepazu: If you're trying to do patches you are probably trying to match them to a geometric shape - in most uses
07:13:41 [nikos]
Cyril drawing on board
07:14:26 [nikos]
Cyril: typically a coon's patch is something where you start with a unit square, with parameters u and v. You have a colour aspect where you have 4 colours on the corners, you have a bilinear interpolation inside
07:14:47 [nikos]
... then you have a transformation, from u &v you get x & y on one side and a colour value on the other side
07:15:51 [nikos]
... what you are proposing is the difference between coon's patches and tensor patches
07:15:57 [nikos]
... there is also a ferguson patch
07:16:11 [nikos]
... from simplest to more complex - coons, tensor and then ferguson
07:16:27 [victor]
victor has joined #svg
07:16:41 [nikos]
... what you are proposing is something like what PDF does with tensor patches but in the colour dimension and not the geometric dimensions
07:18:38 [nikos]
Tav: in 1 dimension, you interpolate the colours using a bezier
07:19:00 [nikos]
Cyril: I don't think that is a simple transition to 2 dimensions
07:20:08 [nikos]
Cyril: I would need to think about it
07:20:31 [nikos]
Tav: I am always proposing to have the extra points at 1/3rd and 2/3rd
07:20:47 [nikos]
TabAtkins__: I'm ok as long as there's an automatic way to do the interpolation
07:21:18 [nikos]
heycam: Are you describing extra things the author has to specify?
07:21:30 [nikos]
Tav: yes. Or if it's not specified you get the linear interpolation
07:21:58 [nikos]
heycam: I would like a boolean that enables a way for us to specify the method of smoothing
07:22:12 [nikos]
shepazu: I'd like to see this proposal in terms of a syntax
07:22:20 [nikos]
Tav: for auto smoothing it would simply be a flag
07:22:47 [Cyril_]
Cyril_ has joined #svg
07:22:55 [nikos]
Tav: I have a proposal syntax
07:23:19 [nikos]
... I think we really need the tensor points as they allow you to draw how the colours spread inside and helps to remove some of the banding effects
07:23:40 [nikos]
... <mesh><meshrow><meshpatch><stops>
07:24:08 [Cyril_]
Cyril_ has joined #svg
07:24:22 [nikos]
... when defining tensor points, you could replace that with an array of rows by columns with a colour array as well
07:25:27 [nikos]
Tav: one mesh consists of 16 points. These points could be described in an array of points.
07:26:08 [nikos]
shepazu: I don't know if that's simpler
07:26:18 [Cyril__]
Cyril__ has joined #svg
07:26:52 [nikos]
Tav: The points and handles defining the patch map into the array
07:27:46 [nikos]
Tav: if you are going to add the tensor points inside the patch, you cannot define them using the path syntax
07:28:54 [nikos]
Tav: slide 33 has an example syntax
07:34:10 [nikos]
shepazu: I'd like to see real world examples of how this is used and how many patches are needed
07:34:13 [nikos]
Cyril: it's heavily used
07:35:02 [nikos]
... requires many many patches to make an image
07:35:07 [nikos]
shepazu: is this a good use for SVG?
07:35:26 [nikos]
TabAtkins__: it's a very good use for an SVG viewer
07:38:23 [nikos]
shepazu: is this something you could see being added CSS?
07:38:36 [Cyril]
rrsagent, pointer?
07:38:36 [RRSAgent]
07:38:46 [nikos]
TabAtkins__: no.
07:39:20 [TabAtkins]
TabAtkins has joined #svg
07:40:23 [nikos]
shepazu: what we want is output that is consistent with the author's view in illustrator and inkscape
07:40:45 [nikos]
heycam: I'd like to avoid having the subdivision in the SVG
07:41:05 [shepazu]
s/output/browser output/
07:42:21 [nikos]
shepazu: This is unique and attention grabbing which are good criteria for inclusion in SVG
07:42:52 [nikos]
TabAtkins: is this a paint server or just geometry?
07:43:08 [nikos]
Tav: we decided if it's in the defs section it's a paint server, if it's not then it's geometry
07:43:16 [nikos]
... you need to be able to clip if it's a paint server
07:44:36 [nikos]
Resolution: SVG mesh gradients should have a method for enabling smoothing and smoothing should be default behaviour
07:44:58 [shepazu]
s/This is unique and attention grabbing which are good criteria for inclusion in SVG/This seems like something that 1) can't be done elsewhere in the web platform 2) couldn't be done in CSS (needs markup) and 3) will meet the real-world needs of authors, which are good criteria for inclusion in SVG 2/
07:45:22 [nikos]
Action: Rik to find out what method Adobe uses for smoothing mesh gradients and report to group
07:45:22 [trackbot]
Created ACTION-3375 - Find out what method Adobe uses for smoothing mesh gradients and report to group [on Rik Cabanier - due 2012-09-26].
07:46:08 [nikos]
cabanier: if the patches are not hand editable then why not just make them really compact
07:46:34 [nikos]
shepazu: even if they're not hand editable they still need to be animatable
07:47:36 [nikos]
ed: One of my main concerns is a lot of details are missing from the spec at the moment
07:47:39 [nikos]
Tav: they will be added
07:48:07 [nikos]
ed: I'd like references to the algorithms used - they should be in the spec
07:48:21 [nikos]
Cyril: I'm not sure all the algorithms are royalty free
07:48:39 [nikos]
... at least one has a patent
07:49:05 [nikos]
... I think we won't be mandating a specific algorithm
07:49:17 [nikos]
TabAtkins: that's right, you require a certain output
07:49:33 [nikos]
... it just has to be black box compatible
07:50:59 [nikos]
ed: My other point is about hand authoring - it doesn't seem to be really possible
07:51:26 [nikos]
... if we were to have a simplified syntax that wouldn't give the same accuracy but gives something that could be manipulated would be useful
07:52:21 [ed]
s/that wouldn't give/that (perhaps) wouldn't provide
07:52:48 [nikos]
shepazu: so it's common for people to use multiple meshes to create an object
07:52:51 [nikos]
... what's the bounding box?
07:53:05 [nikos]
TabAtkins: if it's geometry then the bounding box is the edges
07:53:18 [nikos]
cabanier: they fold over themselves
07:53:34 [nikos]
TabAtkins: that would be as if any path folds over itself
07:54:02 [nikos]
shepazu: this is different to SVG in some ways - normally in SVG you have a shape which is the geometry and it might be affected by properties
07:54:11 [nikos]
... then you fill it with some other thing that doesn't have geometery/size
07:54:31 [nikos]
cabanier: well we resolved that now radial gradients will have a boundary
07:54:38 [nikos]
shepazu: but you can't use getBBox on it
07:55:04 [nikos]
heycam: I think doug is saying it can be a mesh object as well as a paint server
07:55:22 [nikos]
shepazu: under what circumstances would you use it as a paint server?
07:55:32 [andreas]
andreas has joined #svg
07:55:54 [nikos]
... I don't think it is the primary purpose
07:56:52 [nikos]
shepazu: we have talked several times about integrating canvas and svg and having a similar path model
07:57:00 [nikos]
... now we are introducing a new element where you can't do that path stuff
07:57:09 [nikos]
... for the pepper, I might want to just get the outline
07:57:12 [nikos]
Cyril: you can
07:58:08 [nikos]
cabanier: what about when it folds over itself?
07:58:15 [nikos]
... the outline may not be the outermost path
07:58:44 [nikos]
heycam: if we had this method on circles, etc then it should work on the patch geometry as well
07:59:09 [nikos]
Cyril: if a patch overlaps itself the path would also, that's fine
08:00:31 [nikos]
shepazu: if I had line art and I want to colour it using mesh gradients how would I do that?
08:01:13 [nikos]
TabAtkins: you would use a paint server to contain the colour, the patches wouldn't match the geometry
08:01:22 [jet]
jet has joined #svg
08:01:24 [nikos]
... effectively, you would need to trace over the line art
08:01:41 [nikos]
shepazu: I think this has path like characteristics so it should have path like powers
08:02:52 [nikos]
Tav: I talked to the NVidia guy about HW acceleration and he said no problem.
08:02:55 [nikos]
Cyril: it's very simple
08:04:42 [victor]
victor has left #svg
08:06:14 [nikos]
Cyril: When we selected Coon's patches, we also considered triangle patches.
08:06:23 [nikos]
... the more I read about vectorisation, the more I see this being used
08:07:13 [nikos]
... I am suggesting we add the triangular representation for meshes to SVG
08:07:36 [nikos]
heycam: is it wasteful to do the triangles using bezier paths?
08:07:43 [nikos]
Cyril: I would have to investigate but I suspect so
08:07:56 [nikos]
shepazu: Cyril, could you come up with a concrete proposal that shows syntax and outputs
08:08:34 [nikos]
Action: Cyril to write up a proposal for a triangular representation for gradient meshes
08:08:34 [trackbot]
Created ACTION-3376 - Write up a proposal for a triangular representation for gradient meshes [on Cyril Concolato - due 2012-09-26].
08:09:16 [nikos]
Topic: GetSVGDocument deprecation/removal
08:09:31 [nikos]
Topic: SVGDocument interface (alias to Document?)
08:09:49 [nikos]
ed: this is a bout merging all the interfaces of SVGDocument onto document
08:09:55 [nikos]
... this is the direction HTML is going
08:10:26 [nikos]
... we would want a minimal representation for backwards compatibility
08:10:43 [nikos]
shepazu: what is the syntax in HTML5
08:10:49 [ed]
08:10:59 [nikos]
TabAtkins: HTMLDocument is an alias for document
08:11:49 [nikos]
heycam: if you create a document, the type is defined by the root element, it can't change mid-life so whatever functionality for SVGDocument and HTMLDocument should be available on all documents
08:12:47 [nikos]
shepazu: in HTML, when you try to get forms and there are no forms, would the result be different in SVG compared to a HTML doc that has no forms
08:12:59 [nikos]
heycam: document.forms would be a HTML collection object with length zero
08:13:29 [nikos]
heycam: HTML collection is named HTML collection but it's really just a collection of any element
08:13:42 [nikos]
shepazu: what difference would this make to authors?
08:14:59 [nikos]
heycam: the difference will be additional properties
08:15:55 [nikos]
shepazu: we can remove details from our specification and refer to HTML5
08:16:30 [nikos]
... I'm in favour of this, we can special case things as we find them
08:16:51 [nikos]
TabAtkins: i.e. SVG links are returned as well as HTML links
08:17:47 [nikos]
heycam: we need to discuss the alias
08:18:03 [nikos]
... firstly in the IDL it becomes a partial interface for document
08:18:33 [nikos]
... the aliasing of the interface, presumably HTML does that for HTMLDocument
08:19:30 [nikos]
TabAtkins: it just aliases to document. We would use the same line in SVG
08:19:40 [TabAtkins]
"For historical reasons, Window objects must also have a writable, configurable, non-enumerable property named HTMLDocument whose value is the Document interface object."
08:19:55 [nikos]
heycam: we will do the same thing
08:20:14 [nikos]
Resolution: SVGDocument will be an alias for document
08:20:29 [nikos]
Action: ed make SVGDocument into an alias for document
08:20:30 [trackbot]
Created ACTION-3377 - Make SVGDocument into an alias for document [on Erik Dahlström - due 2012-09-26].
08:20:54 [nikos]
Topic: XLink deprecation
08:21:05 [nikos]
heycam: We might have already decided on this
08:21:23 [nikos]
... whether all attributes become href or whether some become source and some become href
08:21:37 [nikos]
TabAtkins: I think they should be whatever they all are right now
08:21:43 [nikos]
... we shouldn't change it, just drop the xlink prefix
08:22:19 [nikos]
... I think we should align script
08:22:47 [nikos]
heycam: there are quite a number of elements that have xlink:href
08:23:02 [nikos]
shepazu: the idea was that we use xlink:href for any external resource
08:23:10 [nikos]
... I don't mind if you can use href or src
08:23:35 [nikos]
... we are going to have to xlink:href and href so we might as well allow src too
08:23:48 [heycam]
08:23:56 [nikos]
list of things that use xlink:href
08:24:43 [nikos]
a - makes sense
08:25:00 [nikos]
alt-glyph is a reference to an element so should be href
08:25:09 [nikos]
animate elements - makes sense
08:25:21 [nikos]
color-profile - being removed
08:25:42 [nikos]
cursor - represents an external image so could be src, but cursor is probably not similar to anything in HTML so can be left as href
08:26:14 [nikos]
image - should allow src
08:26:37 [nikos]
TabAtkins: the ones I'm concerned about are image and script
08:28:25 [nikos]
shepazu: with image, it behaves differently in SVG than in HTML, so they don't have to align
08:28:32 [nikos]
TabAtkins: script is the one I feel really strongly about
08:30:05 [nikos]
... I might want script to accept 3 attributes, if there are not strong objections
08:30:22 [nikos]
shepazu: we resolved that href overrides xlink:href
08:30:37 [nikos]
... but there's more to it - i.e. how it is represented in the DOM
08:30:41 [ed]
08:31:11 [nikos]
heycam: I like allowing src for script
08:31:39 [nikos]
shepazu: users expect src
08:31:44 [nikos]
08:31:57 [nikos]
heycam: I propose that src overrides everything
08:32:10 [nikos]
TabAtkins: I'd put src between href and xlink:href
08:32:17 [nikos]
heycam: I'd like to encourage src
08:32:19 [nikos]
shepazu: me too
08:34:40 [nikos]
heycam: set always sets 'src' and 'get' gets the attribute that exists with the highest precedence.
08:34:59 [nikos]
shepazu: this makes me reconsider image, why are we doing src in some things and not src in others?
08:35:13 [nikos]
... we could align on src but say there's a couple of quirks with SVG image.
08:35:40 [nikos]
... so anywhere that HTML has a general kind of element that uses src instead of href, SVG will also allow src and it will be the default
08:36:12 [nikos]
heycam: feImage should remain href because it can point to trees
08:36:34 [nikos]
TabAtkins: I'd like to stay doing what we currently do unless aligning with HTML
08:37:08 [nikos]
heycam: all the remaining elements in the list are href
08:37:48 [nikos]
... one final issue - on image the href DOM property is an animated string
08:38:35 [Zakim]
Zakim has left #svg
08:39:10 [nikos]
... we should make .src be a DOM string that just reflects the base value, not the animated value
08:45:00 [nikos]
TabAtkins: There's 3 things
08:45:09 [nikos]
... firstly the xlink:href gain a plain href
08:45:18 [nikos]
... secondly, script and image gain a src attribute
08:45:48 [nikos]
thirdly, when getting from any, you get the highest precedence (src -> href -> xlink:href), when setting you set the highest that is available
08:46:46 [nikos]
Resolution: We will allow href on all elements that have xlink:href and allow src on image and script. With details as in the minutes.
08:47:07 [nikos]
Action: Cameron to add href on all elements with xlink:href and add src to image and script
08:47:07 [trackbot]
Created ACTION-3378 - Add href on all elements with xlink:href and add src to image and script [on Cameron McCormack - due 2012-09-26].
08:56:13 [andreas]
andreas has joined #svg
09:27:42 [Cyril]
scribeNick: Cyril
09:27:51 [Cyril]
Topic: Cameron's stuff
09:28:21 [Cyril]
heycam: we have previously described ways of determining whether pointer-events were within the stroke region or the fill region or hte marker
09:28:36 [Cyril]
... we settled on a method to tell you which region was hit
09:28:40 [Cyril]
... I have done that
09:28:43 [Cyril]
... it's in the spec
09:28:52 [Cyril]
09:28:55 [heycam]
09:29:12 [Cyril]
... I took upon myself to add a new interface
09:29:22 [Cyril]
... on elements that can be filled and stroke
09:29:28 [Cyril]
... there are 2 methods:
09:29:32 [Cyril]
09:29:35 [Cyril]
09:29:50 [Cyril]
... initially it is taking a Point object in user space
09:30:26 [Cyril]
... because often you will have a mouse event and you want to take the coordintes of hte mouseevent and translate them into the user space
09:31:04 [Cyril]
... that's a separate thing that's handy to do
09:31:16 [Cyril]
... oh, I forgot to make that change
09:31:34 [Cyril]
... SVGPoint should have a constructor that takes an element and a mouse event
09:31:47 [Cyril]
... if the element is not provided, it is assumed to be the target of the event
09:32:12 [Cyril]
... I had the conversion integrated but this is cleaner this way
09:32:22 [Cyril]
... I also worked on markers
09:32:37 [Cyril]
... there is a separate interface
09:32:46 [heycam]
09:33:16 [Cyril]
... it's implemented on elements that can have markers on
09:33:36 [Cyril]
... rahter than having a method is point in markers, which doesn't tell you whjich marker is used
09:33:40 [Cyril]
... it uses a marker index
09:34:03 [Cyril]
... this covers the automatic marker and the children marker
09:34:29 [cabanier]
scribenick: cabanier
09:34:51 [Cyril]
scribeNick: Cyril
09:35:03 [Cyril]
... in the same order as the rendering order
09:35:25 [Cyril]
first the automatic ones and then the positioned ones
09:35:43 [Cyril]
... SVGMarkerList gives you a list of marker instances
09:35:49 [heycam]
09:36:02 [Cyril]
... giving you the marker, its position ...
09:37:18 [Cyril]
... as a length along the path
09:37:24 [Cyril]
... the actual point that it's at and the angle
09:37:40 [Cyril]
andreas: can you get the segment it's on?
09:37:49 [Cyril]
heycam: there is a method for that in PathSegment
09:38:07 [Cyril]
... in fact angle and point are not strictly needed, but they are convenient
09:38:24 [Cyril]
rik; can you change hte marker that you get?
09:38:35 [Cyril]
heycam: yes, you can change the definition
09:38:59 [Cyril]
andreas: sometimes you want to highlight hte marker that is selected
09:39:19 [Cyril]
heycam: that would be difficult for the automatic markers, because you can't change just one
09:39:27 [birtles]
(the method for getting the segment is SVGPathElement.getPathSegAtLength)
09:39:28 [Cyril]
... you probably need to use child markers
09:40:31 [Cyril]
tab: I agree
09:41:17 [Cyril]
heycam: the marker has now two new attributes: position and reference
09:41:40 [Cyril]
... the SVGMarkerList does not let you add new markers
09:41:48 [Cyril]
... it's only access to the computed list of all markers
09:41:56 [Cyril]
... it might be a bit tricky to change that
09:42:08 [Cyril]
... if this was useful for adding/removing makers
09:42:31 [Cyril]
... we could have markers and childMarkers
09:43:03 [Cyril]
brian: I noticed that the PathSegList throws an exception
09:43:12 [Cyril]
... it is not consistent
09:43:37 [Cyril]
heycam: if you use the squared brackets you will not get exceptions
09:44:13 [Cyril]
brian: on marker list the getter is defined to return null if the index is out of range
09:44:30 [Cyril]
... but other interfaces SVGPathSegList it is defined to throw an Index Size Error
09:44:41 [Cyril]
... so we need to make them consistent
09:45:07 [Cyril]
... one detail of that is that if you use square brackets syntax, you won't get an exception regardless of the index and range
09:45:20 [Cyril]
... that's due to the behavior defined in WebIDL
09:45:47 [Cyril]
heycam: you could use path.markers[n]
09:46:18 [Cyril]
... if you use that even if me make the method throw an exception this won't
09:46:26 [Cyril]
... but I'll add the exception to the method
09:46:57 [Cyril]
ACTION: heycam to make SVGMarkerList item method return an exception when the index is out of range
09:46:57 [trackbot]
Created ACTION-3379 - Make SVGMarkerList item method return an exception when the index is out of range [on Cameron McCormack - due 2012-09-26].
09:47:21 [Cyril]
ACTION: heycam to make the SVGPoint changes to take a mouse event in the constructor
09:47:21 [trackbot]
Created ACTION-3380 - Make the SVGPoint changes to take a mouse event in the constructor [on Cameron McCormack - due 2012-09-26].
09:47:58 [Cyril]
Topic: Hatchings
09:48:48 [Tav]
09:49:17 [Cyril]
tav: this is a fairly common technical drawing in maps
09:49:33 [Cyril]
... but you can use patterns but there are anomalies at boundarys
09:49:54 [Cyril]
... but there is also a problem for plotters, because the pen goes up and down at each boundary
09:50:01 [Cyril]
... open source plotters use SVG for that
09:50:11 [Cyril]
... I'd like to have some feedback on a new syntax
09:50:33 [Cyril]
... you specify an angle, origin, pitch and width
09:50:54 [Cyril]
... if you want multiple fills you want to use multiple elements
09:51:16 [Cyril]
tab: you are using the line element and it should probably a path element
09:51:30 [Cyril]
tav: yes you could specify a pattern that gets extruded (slide 18)
09:51:58 [Cyril]
heycam: dasharray is pitch: gap and width and gap ...
09:52:59 [Cyril]
tav: by using the path syntax you can have more complicated hatchings
09:53:39 [Cyril]
tab: would you do a line to if start and end don't match
09:53:41 [Cyril]
tav: yes
09:54:03 [Cyril]
tab: you determine how large the tile is by using the bounding box
09:54:23 [Cyril]
cyril: how is it different from a pattern
09:54:54 [Cyril]
tab: when you tile patterns you should paint each tile separately
09:55:10 [Cyril]
... and that's not what you want for engravers for instance
09:55:45 [Cyril]
cyril: what makes this behavior not possible with pattern?
09:56:26 [Cyril]
(heycam drawing)
09:57:56 [Cyril]
cyril: I don't understand why we need to introduce a new element just to change the rendering algorithm
09:58:42 [Cyril]
doug: this makes it simpler to define a pattern that has overlaps with other pattern elements
09:59:45 [Cyril]
... because it overlaps with itself
10:00:08 [Cyril]
(doug drawing example of the zig-zag pattern)
10:00:33 [Cyril]
brian: in some cases, when you have cross hatching
10:00:40 [Cyril]
tab: I like the syntax on the second slide
10:00:53 [Cyril]
... I don't like the more compact representation using the dash syntax
10:01:45 [birtles]
brian: this would make it more easy to detect the situations andreas showed us yesterday when you want to rotate the cross-hatching so that the lines don't end up parallel with the edges of the shape
10:01:48 [Cyril]
doug: it would easier to animate this kind of pattern
10:02:09 [Cyril]
(andreas showing point hatching)
10:03:54 [Cyril]
tab: I like the idea, this is good!
10:04:10 [Cyril]
doug: especially given the parameters that control the pattern repetition
10:05:04 [Cyril]
brian: cross-hatching?
10:05:14 [Cyril]
tav: easily done with multiple fills
10:05:28 [Cyril]
cyril: what about nested hatchings?
10:06:02 [Cyril]
tab: no, this just accepts paths
10:06:22 [Cyril]
... what happens if you put more complex strokes?
10:06:36 [Cyril]
... filling a stroke with a gradient or an image
10:06:50 [Cyril]
... does it repeat on a per tile basis or more
10:06:59 [Cyril]
... what is the gradientUnit
10:07:08 [Cyril]
tav: I haven't thought about it
10:07:43 [Cyril]
brian: how important is it to specify colors?
10:07:51 [Cyril]
... couldn't you do it on the referencing?
10:09:00 [Cyril]
... if you want a gradient, you could do it in a mask
10:09:33 [Cyril]
tab: maybe we need to change line to hatchline so that its stroke property takes only a color and not a paint server
10:09:49 [Cyril]
heycam: I'm nto sure it's impossible to have it work for gradients
10:10:14 [Cyril]
... but I can see that so that markers don't go on there
10:10:24 [Cyril]
tab: and also filling would be a non-sense
10:10:34 [Cyril]
heycam: but it could be made consistent for the model
10:11:48 [Cyril]
... I would still be fine with path and line instead of hatchpath and hatchline
10:12:05 [Cyril]
brian: clip-path has restrictions
10:12:14 [Cyril]
... already
10:12:28 [Cyril]
heycam: it is analogous to clip-path
10:12:34 [Cyril]
rik: yes, it's the opposite
10:12:46 [birtles]
(that is, children of the clipPath element)
10:12:58 [Cyril]
tab: if we say that some attributes are ignored, I would be fine with it
10:13:22 [Cyril]
tav: offset tells you where you start with the pitch
10:14:12 [Cyril]
tab: you could use the x,y attributes to encode the offset
10:14:57 [Cyril]
brian: how do multiple fills work?
10:15:08 [Cyril]
tab: we have to work that out yet
10:15:58 [Cyril]
heycam: at some points, we want to allow multiple fills and multiple strokes without vector effect
10:16:20 [Cyril]
tab: that is copy what CSS has done with background and that's the wrong way
10:16:30 [Cyril]
... having a compound fill would be better
10:16:42 [Cyril]
rik: I agree
10:17:07 [Cyril]
brian: you could bundle a cross-patch with a background for instance
10:17:19 [birtles]
10:18:19 [Cyril]
RESOLUTION: SVG 2 will have a modified version Tav's hatch proposal
10:18:54 [Cyril]
ACTION: Tav to work out the details of the modifications of the initial proposal
10:18:54 [trackbot]
Created ACTION-3381 - Work out the details of the modifications of the initial proposal [on Tavmjong Bah - due 2012-09-26].
10:19:33 [Cyril]
ACTION: Tab to think about a compound paint server proposal
10:19:33 [trackbot]
Created ACTION-3382 - Think about a compound paint server proposal [on Tab Atkins Jr. - due 2012-09-26].
10:23:23 [Cyril]
(andreas showing a marker centroid example)
10:24:13 [TabAtkins]
ScribeNick: TabAtkins
10:24:33 [TabAtkins]
andreas: [shows a mapping example where patterns are placed at the centroid of the various geometric objects]
10:24:49 [TabAtkins]
TabAtkins: You could do that maybe as a marker positioned at the centroid?
10:25:06 [TabAtkins]
shepazu: If we exposed that kind of thing, you'd want an explicit DOM API on <path> returning the centroid as well.
10:25:13 [TabAtkins]
ScribeNick: Cyril
10:25:38 [Cyril]
doug: centroid is actually not trivial to calculate
10:26:06 [Cyril]
heycam: we could make the hatching large enough so that it does not repeat
10:26:18 [Cyril]
... actually you can use a pattern for that
10:26:52 [Cyril]
doug: do we add a keyword for centroid
10:28:55 [shepazu]
10:28:59 [stakagi]
10:29:53 [Cyril]
(discussion on the centroid properties)
10:32:18 [Cyril]
10:42:19 [andreas]
11:16:02 [andreas]
andreas has joined #svg
11:43:27 [TabAtkins]
TabAtkins has joined #svg
11:44:23 [stakagi]
stakagi has joined #svg
11:45:06 [Cyril]
Cyril has joined #svg
11:46:25 [nikos]
nikos has joined #svg
11:48:16 [TabAtkins]
TabAtkins has joined #svg
11:54:32 [cabanier]
cabanier has left #svg
11:54:47 [cabanier]
cabanier has joined #svg
11:56:00 [Cyril]
11:56:03 [Tav]
11:56:12 [heycam]
ScribeNick: heycam
11:56:16 [heycam]
Topic: extrapolated line join
11:56:26 [Tav]
11:56:42 [heycam]
Tav: we talked about this last time
11:56:50 [heycam]
… the question at that point was "what about the math"
11:56:53 [heycam]
… so I've provided it here
11:56:57 [heycam]
… it's straightforward
11:57:09 [heycam]
… you're looking at the curvature at the end of the path where the two segments join
11:57:33 [heycam]
… using that to draw circles, and you shrink or expand circles to the edges of the path, and extrapolate from there
11:58:14 [heycam]
TabAtkins: it's just expanding the circle so that it matches the edge of the path, rather than the center of the path
11:58:41 [heycam]
Tav: you can have a straight line, and then displace that by half a stroke width
11:58:50 [heycam]
… because sometimes these lines aren't going to intersect
11:58:55 [heycam]
… you might also want to apply a miter limit
11:59:20 [heycam]
TabAtkins: seems reasonable, thanks for working out the math
11:59:32 [heycam]
Cyril: the curvature doesn't take into account the stroke, just the path?
11:59:34 [heycam]
TabAtkins: correct
11:59:37 [heycam]
Tav: it's going to be the same thing
12:00:15 [heycam]
Cyril: is this implemented somewhere?
12:00:27 [heycam]
TabAtkins: Inkscape has something similar but not quite the same
12:00:34 [heycam]
… the person implementing it just mirrored the path to get the curvature
12:00:37 [heycam]
… which I don't think you want to do
12:00:44 [heycam]
12:00:50 [heycam]
12:02:13 [heycam]
cabanier: if they become a line, you miter them?
12:02:26 [heycam]
Tav: there are cases where the circles won't intersect, or if they're both lines
12:02:55 [heycam]
… then you fall back to miter
12:03:35 [heycam]
heycam: would you want to apply miter-limit to this join, and also to the fallback to a miter-limited miter?
12:03:44 [heycam]
TabAtkins: no, if the extrapolation doesn't work you fall back to bevel
12:03:55 [heycam]
… but yes apply miter-limit to extrapolated join
12:06:20 [heycam]
RESOLUTION: We will add extrapolated line joins to SVG 2, using Tav's proposal.
12:06:29 [heycam]
ACTION: Tav to add extrapolated line joins to the spec.
12:06:30 [trackbot]
Created ACTION-3383 - Add extrapolated line joins to the spec. [on Tavmjong Bah - due 2012-09-26].
12:07:12 [heycam]
Topic: GetSVGDocument interface
12:08:00 [heycam]
heycam: [explains what GetSVGDocument]
12:08:06 [heycam]
12:08:13 [heycam]
ed: getSVGDocument doesn't work on embed
12:08:17 [heycam]
12:10:33 [heycam]
12:11:31 [heycam]
heycam: from my testing there it looks like it is consistently not implemented on embed, yes
12:11:46 [heycam]
TabAtkins: I'm fine with keeping it in, for legacy purposes
12:12:00 [heycam]
… would be good to amend the spec to say that it returns the same as contentDocument for legacy purposes
12:13:00 [ed]
from the spec: "This interface is deprecated and may be dropped from future versions of the SVG specification. Authors are suggested to use the contentDocument attribute on the EmbeddingElement interface to obtain a referenced SVG document, if that interface is available."
12:13:28 [heycam]
RESOLUTION: Keep GetSVGDocument in SVG 2.
12:14:19 [heycam]
Topic: spaces/commas in SVG view specification
12:14:51 [heycam]
heycam: just wanted to confirm what our decision was
12:15:43 [heycam]
ed: we decided to allow commas and spaces in viewBox and preserveAspectRatio parts of the view specification
12:15:45 [heycam]
heycam: ok
12:16:58 [heycam]
Topic: HTML integration
12:17:09 [heycam]
TabAtkins: I've started to push on getting html elements directly in svg
12:17:12 [heycam]
… but not the other way around
12:17:26 [ed]
s/viewBox and preserveAspectRatio parts of the view specification/viewBox and preserveAspectRatio attributes, and to only allow comma separation in the view specification (for fragments)
12:17:28 [heycam]
…but I will do that just for the resource-like elements (like clipPath)
12:20:36 [heycam]
[for view fragments, heycam has an action to check if spaces would work after unescaping url fragments, and then allow spaces in there if that works]
12:21:06 [heycam]
Topic: SVG DOM improvements
12:21:32 [heycam]
heycam: I've added some constructors to SVG type interfaces
12:21:39 [heycam]
… for example
12:22:08 [heycam]
… three constructors there
12:22:12 [heycam]
… one initializes it to 0
12:22:32 [heycam]
… another takes the separate value and unit types
12:22:35 [heycam]
… and another takes a string
12:22:48 [heycam]
TabAtkins: the direction for CSS OM values api, is a constructor named "px"
12:24:02 [TabAtkins] = CSS.px(5)
12:24:43 [heycam]
TabAtkins: then the length object has attributes for converting into various units
12:24:54 [heycam]
birtles: we had a proposal like that already
12:25:20 [heycam]
TabAtkins: this part of the CSS OM proposal is uncontroversial
12:25:53 [heycam]
heycam: how do SVGLength and CSSLengthComponentValue relate then?
12:25:58 [heycam]
TabAtkins: don't care, but they should behave the same
12:27:41 [heycam]
TabAtkins: you could also have CSS.length("20px")
12:28:29 [heycam]
heycam: would we use CSS.px() objects in place of SVGLength?
12:30:01 [heycam]
TabAtkins: you could make SVGAnimatedLength inherit from CSSLengthComponentValue
12:30:09 [heycam]
… and then add your baseVal animVal on there
12:30:32 [heycam]
ACTION: Tab to write up how SVG types should work with CSS OM objects
12:30:33 [trackbot]
Created ACTION-3384 - Write up how SVG types should work with CSS OM objects [on Tab Atkins Jr. - due 2012-09-26].
12:31:12 [heycam]
Topic: rendering-mode: animate
12:31:33 [heycam]
shepazu: there are various rendering modes like geometricPrecision
12:32:20 [heycam]
… when you try to snap to pixels, this affects the rendering
12:32:24 [heycam]
… they're optional anyway, it's a hint
12:32:41 [heycam]
… one of the cases we talked about is when you're animating
12:33:01 [heycam]
… if you use crispEdges for text animation, it'll be jerky
12:33:27 [heycam]
… I'm proposing a hint "animate" so that the user agent know that this is going to be animated
12:33:32 [heycam]
TabAtkins: so it can switch to a low cost rendering mode?
12:33:34 [heycam]
cabanier: it's higher cost
12:33:43 [heycam]
shepazu: you should switch to a mode that gives the best visual effect for being animated
12:34:15 [heycam]
ed: if you render a rectangle slowly across the screen you'll see the snapping happening
12:34:20 [heycam]
… or the blurring if you use the normal one
12:34:27 [heycam]
cabanier: how would you solve it? draw half pixels?
12:34:41 [heycam]
heycam: how is it different from geometricPrecision?
12:34:58 [heycam]
shepazu: an author won't know that the way to make text look good when you're animating is "geometricPrecision"
12:35:09 [heycam]
… but if you have a mode called "animate", the author will know
12:35:32 [heycam]
… you could say in the spec "if you're animating, use geometricPrecision", but it will be hard for authors to discover
12:36:08 [heycam]
… I don't feel too strongly about it, just thought it would be easier to use
12:38:49 [heycam]
birtles: I think most UAs already detect if something is being animated and optimize it
12:39:14 [heycam]
Cyril: I think the difference is geometricPrecision, some heuristic could not detect what the user would prefer
12:39:21 [heycam]
… the browser can detect it's going to be animated
12:39:41 [heycam]
shepazu: maybe we should add in for crispEdges that browsers may wish to disregard this when animating text
12:39:58 [heycam]
ed: I think it depends on the device
12:40:39 [heycam]
heycam: we could add a note for "auto" to say that text shouldn't be pixel snapped when it is being animated
12:41:37 [Cyril]
12:41:46 [heycam]
RESOLUTION: {shape,text}-rendering should say that "auto" means that pixel snapping shouldn't be done when animating
12:42:13 [Zakim]
Zakim has joined #svg
12:42:37 [Cyril]
12:42:48 [Cyril]
12:42:50 [TabAtkins]
Gotta hand it to Zakim, he's pretty weird
12:42:58 [TabAtkins]
On the other hand
12:42:58 [heycam]
ACTION: Doug to add notes to {shape,text}-rendering auto to mention not doing pixel snapping when animating
12:42:58 [trackbot]
Created ACTION-3385 - Add notes to {shape,text}-rendering auto to mention not doing pixel snapping when animating [on Doug Schepers - due 2012-09-26].
12:42:59 [Cyril]
12:43:04 [TabAtkins]
12:43:14 [Cyril]
12:44:05 [heycam]
Topic: SVG documentation
12:44:31 [heycam]
shepazu: for W3C's documentation, I'd like to automatically extract element/attribute/property names and values from the spec
12:44:39 [heycam]
… if you could also send me tutorials you'd like to see
12:49:11 [heycam]
Topic: CSS Variables and Params
12:49:19 [heycam]
shepazu: params should use the variable mechanism for substituting values
12:49:31 [heycam]
… for text content, we need something to render it into the DOM, possibly <tref>
12:49:40 [heycam]
TabAtkins: make it accept a var() function in addition to a url()
12:50:47 [heycam]
shepazu: I'll work with Tab on this
12:50:52 [heycam]
Topic: rounded corners
12:51:05 [heycam]
shepazu: [draws a star with rounded corners]
12:51:20 [heycam]
… [but only on the outer points]
12:51:54 [heycam]
shepazu: my proposal is that you bisect the angle, the center point of the circle is the point on that line in which a circle of that radius will fit
12:52:02 [heycam]
… you specify a radius
12:52:26 [heycam]
TabAtkins: this is like a custom line join?
12:52:41 [heycam]
shepazu: yes, basically
12:52:47 [heycam]
… a comma separated list that repeats like dash array
12:52:56 [heycam]
… you give a list of radii, and it applies them in sequence when a corner is encountered
12:53:58 [heycam]
TabAtkins: this is the arcTo from canvas
12:55:50 [heycam]
heycam: is this like a line join?
12:55:54 [heycam]
shepazu: but this should affect the fill
12:57:16 [glenn]
glenn has joined #svg
12:57:31 [heycam]
shepazu: with my proposal, you would say r="5", with Tab's proposal you'd have to change each edge in the path data
14:06:41 [stakagi]
stakagi has joined #svg
14:07:08 [TabAtkins]
TabAtkins has joined #svg
14:10:03 [birtles]
birtles has joined #svg
14:18:36 [nikos]
nikos has joined #svg
14:18:45 [ChrisL]
ChrisL has joined #svg
14:19:07 [ChrisL]
rrsagent, here
14:19:07 [RRSAgent]
14:19:22 [heycam]
heycam: is this only straight line segments?
14:19:29 [heycam]
shepazu: no any segments
14:19:59 [heycam]
TabAtkins: you want to preserve curve continuity when you come into the arc
14:20:42 [heycam]
shepazu: Tab's counterproposal is better than what you can do in path today
14:20:46 [heycam]
TabAtkins: yes because you have to do trig
14:21:09 [heycam]
shepazu: this proposal could also apply to rect, polyline, polygon, star, connector
14:21:20 [glenn]
glenn has joined #svg
14:21:21 [heycam]
… on a connector, you might want it to go through an intermediate point (with an orthogonal connector)
14:21:30 [heycam]
… but with a rounded corner there
14:22:03 [heycam]
… this proposal reduces the amount that you have to type
14:22:12 [heycam]
… even on a <path>, it's easy then to style it differently
14:22:17 [heycam]
… rather than tweaking the path data
14:22:26 [heycam]
TabAtkins: sounds good to me
14:22:56 [heycam]
… the math shouldn't be hard to describe
14:23:02 [heycam]
shepazu: I also want there to be a way to pull this out
14:23:12 [heycam]
… toPathData() on a shape
14:24:06 [glenn]
glenn has joined #svg
14:24:20 [heycam]
… I'm not sure I want to see it on path, but on all other polygon-like elements
14:24:23 [krit]
krit has joined #svg
14:24:24 [heycam]
… on straight lines it's really easy
14:24:36 [heycam]
… but there could be some odd beziers that would have a bad effect with this
14:24:44 [heycam]
… so for paths leave it to arcTo, but r on other elements
14:25:14 [heycam]
… this property wouldn't give you control of x and y, just a single radius
14:25:29 [heycam]
… I'd like to see the difficulties it would introduce to path, because I'd like to see it there
14:25:47 [heycam]
TabAtkins: there will be some cases that will be difficult to translate into paths, and some that will look weird
14:28:27 [heycam]
shepazu: I don't mind about the edge cases
14:28:42 [heycam]
shepazu: sometimes it will add to the fill and sometimes it will remove from the fill
14:29:23 [heycam]
heycam: it always goes on the smaller angle? (<180 degrees?)
14:29:24 [heycam]
shepazu: yes
14:30:01 [heycam]
shepazu: the property would be dasharray-like, a sequence of radii
14:30:12 [glenn]
glenn has joined #svg
14:31:09 [heycam]
TabAtkins: if the r argument on a rect applied in the same order as border-radius that would be good
14:31:28 [heycam]
heycam: what about applying this to <rect rx ry>?
14:31:34 [heycam]
shepazu: rx ry should win
14:31:56 [heycam]
shepazu: if it's not possible to fit the circle between the segments, then it gets skipped
14:32:06 [heycam]
TabAtkins: is this an attribute or a property?
14:32:08 [heycam]
shepazu: property
14:34:51 [TabAtkins]
also a presentation attribute
14:34:53 [heycam]
TabAtkins: just call the property "r"
14:35:22 [ChrisL]
@tab all properties are also presentation attributes, in svg
14:35:52 [heycam]
ed: I want to allow the same thing that border-radius could do on rect
14:35:56 [heycam]
… different x/y radii
14:37:02 [ChrisL]
@ed but then you need to specify how to align the major and minor axes of the ellipses. circular radii are much easier for rounding arbitrary shapes
14:37:51 [heycam]
shepazu: ellipses would be hard
14:37:55 [ed]
ChrisL, yes, I meant to make <rect> a specialcase
14:37:56 [heycam]
TabAtkins: and you'd have to worry about rotation
14:37:58 [heycam]
shepazu: let's not do radii
14:38:07 [heycam]
s/radii/different x and radii/
14:38:11 [heycam]
*x and y
14:39:27 [heycam]
shepazu: the only element it wouldn't be allowed on is ellipse
14:40:03 [krit]
Why not on a per element basis in general
14:40:23 [krit]
circle, rect, ellipse doesn't make sense for me with a new r
14:40:41 [heycam]
rect does, since you can have different things at different corners
14:40:46 [heycam]
circle and ellipse I don't think it's needed
14:41:07 [krit]
heycam: Isn't rx and ry enough on rect?
14:41:28 [birtles]
krit: they set the same radii on all vertices
14:41:33 [ChrisL]
@krit only one value for the whole rect, though
14:41:45 [krit]
14:42:46 [ChrisL]
although we could extend rx and ry on rect to allow (1..4) values
14:43:07 [heycam]
that's also an option, but if we allow this new property on polygon, polyline, etc. I think it makes sense to use it on rect too
14:43:28 [heycam]
birtles: when do you want to set different radii on different points?
14:43:38 [heycam]
TabAtkins: for the star example, you want radius, no radius, radius, no radius, ...
14:43:57 [ChrisL]
as noted earlier, rect differs by allowing elliptical arc (already). only circluar arc on plyline, polygon and path though
14:44:42 [heycam]
elliptical arcs make less sense (at least, they're harder) on non 90-degree angles
14:44:44 [ChrisL]
so, i thnk it does not make sense on rect and instead, the existing rx and ry should be extended to take a list
14:44:44 [heycam]
i.e. not rect
14:45:25 [shepazu]
ChrisL, we're proposing both
14:45:25 [heycam]
TabAtkins: we can extend rx/ry attributes too
14:45:25 [ChrisL]
while adding the new r property on path, polygon, polyline and star
14:45:37 [ChrisL]
14:47:26 [heycam]
RESOLUTION: We add Doug's r="" proposal for rounded corners for shape-y elements, and pending the math, for paths too.
14:48:07 [heycam]
RESOLUTION: We also allow rx/ry to extend to multiple values on rect.
14:48:26 [heycam]
ACTION: Doug to add the r="" proposal to SVG 2.
14:48:26 [trackbot]
Created ACTION-3386 - Add the r="" proposal to SVG 2. [on Doug Schepers - due 2012-09-26].
14:49:07 [ChrisL]
i can take the rx ry extending action
14:50:00 [heycam]
ACTION: Chris to extend rx/ry on rect to allow lists of values.
14:50:00 [trackbot]
Created ACTION-3387 - Extend rx/ry on rect to allow lists of values. [on Chris Lilley - due 2012-09-26].
14:50:23 [heycam]
there might be some complications with the DOM there, they're SVGAnimatedLengths now -- would they become SVGAnimatedLengthLists? not sure.
14:50:52 [ChrisL]
yes I suspect so
14:51:01 [ChrisL]
do people depend on that in code?
14:51:16 [heycam]
it's possible
14:51:20 [ed]
since we're making them properties we'd need to probably change the DOM somehow anyway
14:51:23 [heycam]
less likely than x/y/width/height but certainly possible
14:51:34 [ChrisL]
so that could be a script breaking change
14:51:51 [heycam]
could be
14:51:55 [heycam]
it should be thought about ):
14:52:03 [heycam]
14:53:10 [heycam]
Topic: JSON serialization
14:53:12 [shepazu]
14:53:46 [heycam]
TabAtkins: the one change I made to your page was removing the ability to do multiple segments with the one command letter
14:54:37 [heycam]
cabanier: you could make x/y/etc. into an array
14:55:27 [heycam]
shepazu: you could have p[0].x, p[0].y, p[1].x, p[1].y
14:55:33 [heycam]
TabAtkins: what does that buy you?
14:55:47 [Zakim]
Zakim has left #svg
14:55:58 [krit]
what? ZAKIM!!!
14:56:07 [heycam]
cabanier: it would help you iterate over them
14:56:13 [Zakim]
Zakim has joined #svg
14:56:22 [heycam]
TabAtkins: you would never want to do that
14:56:38 [heycam]
shepazu: you also changed sweepFlag to clockwise
14:56:41 [heycam]
TabAtkins: yes
14:57:25 [heycam]
birtles: what's wrong with an array of points in each command?
14:57:29 [heycam]
TabAtkins: it's a bit harder to work with
14:57:49 [heycam]
… for a MoveTo, for example, instead of blah.x you have to do blah.p[0].x
14:57:57 [krit]
couldn't it also mean that the number of input elements is unpredictable?
14:58:17 [heycam]
birtles: if you take this and turn it back into a string, it's easier if it's an array
14:58:39 [heycam]
birtles: there was one library I was using...
14:59:05 [TabAtkins]
15:00:28 [heycam]
… it uses points
15:00:33 [heycam]
… but I can see that could be cumbersome
15:00:46 [heycam]
heycam: if you have a fixed number of points per command (<= 4) which we do, then I think not use an array is better
15:01:48 [heycam]
shepazu: one downside to this is that it doesn't map to the existing path command letters
15:01:49 [krit]
paper.js also has a Path API you could look at
15:02:36 [heycam]
shepazu: this current proposal it's more verbose but clearer
15:02:45 [heycam]
cabanier: it doesn't use more memory really
15:02:57 [heycam]
ed: will we have path commands that take arbitrary parameter lists?
15:03:10 [heycam]
TabAtkins: you can't, because you can't do the automatic segment repetition that the existing commands do
15:04:19 [heycam]
TabAtkins: the catmull-rom command takes a list of points though
15:04:30 [heycam]
shepazu: yes I wanted to have a new "p" start a separate catmull-rom curve
15:11:23 [heycam]
ACTION: Tab to investigate paper.js' arcThrough
15:11:23 [trackbot]
Created ACTION-3388 - Investigate paper.js' arcThrough [on Tab Atkins Jr. - due 2012-09-26].
15:15:12 [cabanier]
*krit: we're looking at the paper.js stuff *
15:23:12 [heycam]
Topic: JSON serialization of SVG
15:24:38 [heycam]
shepazu: there are some reasons to want a standardised JSON serialisation of markup in general, including SVG
15:24:43 [heycam]
… this is something that some script libraries do anyway
15:25:09 [heycam]
… it would be good to have a unified way for them to use JSON serializations of SVG
15:25:15 [heycam]
… rather than each have an ad hoc one
15:25:23 [heycam]
… another thing is it would be useful for postMessage
15:25:28 [heycam]
… this is more general than SVG really
15:25:36 [heycam]
… it wants to be able to serialise any given markup
15:25:48 [heycam]
… this is not recommended for browsers to implement
15:26:08 [heycam]
15:26:34 [heycam]
TabAtkins: we would attach a toJSON to Element, and a fromJSON to Document
15:28:05 [heycam]
-- end --
15:28:12 [heycam]
RRSAgent, make minutes
15:28:12 [RRSAgent]
I have made the request to generate heycam
15:28:38 [heycam]
Present: Erik, Cameron, Nikos, Doug, Tab, Rik, Cyril, Takagi-san, Tav, Konno-san, Brian
15:28:41 [heycam]
RRSAgent, make minutes
15:28:41 [RRSAgent]
I have made the request to generate heycam
15:28:59 [stakagi]
15:31:47 [heycam]
stakagi: for the JSON path syntax, the names should align with the proposal for expanded path segment elements
15:31:51 [heycam]
RRSAgent: make minutes
15:31:51 [RRSAgent]
I have made the request to generate heycam
15:51:10 [jet]
jet has joined #svg
16:56:18 [Zakim]
Zakim has left #svg
17:09:08 [konno_]
konno_ has joined #svg