乐胖代购免代理版

<heycam> trackbot, start telcon

<trackbot> Date: 19 September 2012

<nikos> scribenick: nikos

radialGradient @fr

ed: I have a couple of questions about the spec
... 1: is fr allowed to be negative?
... I think the thread decided no

2: should the focal point be constrained to be in the circle?
... do we want to be fully compatible with canvas or not?

TabAtkins: I think Canvas behaviour is bad
... whatever we do here I'd like to do it there too

cabanier: in Canvas you get a cone if drawing outside

TabAtkins: that behaviour doesn't make sense - there's a discontinuity in the behaviour for no good reason

heycam: would you ever want that effect?

TabAtkins: I don't think so

cabanier: all implementations come from PDF
... I think you should match what most people do
... you should do it in CSS as well

TabAtkins: it'
... s not good behaviour

cabanier: so how would you define radial gradients?

TabAtkins: I think the last colour should extend outside the plane
... or restrict them to clamp

cabanier: I think SVG should match Canvas

heycam: we do clamp right?

ed: yes

TabAtkins: mesh gradients are too complex for CSS
... so what is ill defined about the clamping right now?
... I don't think authors want it to extend, so I think it's better that we clamp

ed: a secondary issue - what happens if the focal circle radius cuts through the other circle

TabAtkins: project out where the focal point would be. The definition should be in terms of the focal point and the fill shape
... which behaviour do we want? turn it into a cone or clamp?

cabanier: I think it should match what everybody else is doing

ed: even if we wanted to have canvas behaviour we have to keep old behaviour when it's exactly on the circle
... so we don't break old content

<heycam> http://jaspervdg.wordpress.com/2012/09/03/specifying-radial-gradients/

heycam: I'm leaning towards allowing it outside the circle

TabAtkins: I'm not a fan of the cone effect

cabanier: I agree, but I think consistency is important

heycam: what happens when you put the focal point on the edge in Canvas?

cabanier: they don't have repeat so it's not a problem

ed: I think I agree that consistency with Canvas is important

Resolution: SVG radial gradients will align with Canvas for behaviour where the focal point is outside the circle

ed: for the case where it's exactly on the circle we are going to keep the old clamping behaviour for backwards compatibility?
... when the focal point is exactly on the circle

Tav: what colour space do you do the averaging in ?

TabAtkins: CSS takes the easy answer and converts to sRGBA

Tav: optically you would want to use linear

cabanier: the gradient doesn't interpolate linearly

TabAtkins: the averaging should be in the same colour space as the rest
... I think to get correct colours you average in the same colour space as you interpolate

<TabAtkins__> http://dev.w3.org/csswg/css3-images/#find-the-average-color-of-a-gradient

<scribe> ACTION: Tav to specify radial gradient behaviour when the focal point is outside the circle [recorded in http://www.w3.org/2012/09/19-svg-minutes.html#action01]

<trackbot> Created ACTION-3374 - Specify radial gradient behaviour when the focal point is outside the circle [on Tavmjong Bah - due 2012-09-26].

Mesh Gradients

<Tav> http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_artists.svg#36_0

Tav: The basic issue with the gradients right now is how to handle non-smooth transitions between boundaries
... they cause banding
... that point of the transition looks brighter
... Adobe and Corel draw handle this by doing smoothing that's hidden from the user
... it gets exported as 8x8 patches in the PDF
... we could do what they do, but that would end with lots of patches
... or we try some kind of smoothing
... either automatic smoothing or we allow a more complex syntax that allows colours to be set at points on the handles or tensor points

heycam: is it like specifying easing?

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

Tav drawing on board

Tav: If you have two patches, you want to smooth the join
... what I did is use auto smoothing by looking at the slope and use that to construct a curve

Cyril: the problem with that is the rendering of patches is not isolated

Tav: You could define colours at the control points and add tensor points

Cyril: generally that's not what people do, the colour is separate from the geometry

shepazu: If you're trying to do patches you are probably trying to match them to a geometric shape - in most uses

Cyril drawing on board

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
... then you have a transformation, from u &v you get x & y on one side and a colour value on the other side
... what you are proposing is the difference between coon's patches and tensor patches
... there is also a ferguson patch
... from simplest to more complex - coons, tensor and then ferguson
... what you are proposing is something like what PDF does with tensor patches but in the colour dimension and not the geometric dimensions

Tav: in 1 dimension, you interpolate the colours using a bezier

Cyril: I don't think that is a simple transition to 2 dimensions
... I would need to think about it

Tav: I am always proposing to have the extra points at 1/3rd and 2/3rd

TabAtkins__: I'm ok as long as there's an automatic way to do the interpolation

heycam: Are you describing extra things the author has to specify?

Tav: yes. Or if it's not specified you get the linear interpolation

heycam: I would like a boolean that enables a way for us to specify the method of smoothing

shepazu: I'd like to see this proposal in terms of a syntax

Tav: for auto smoothing it would simply be a flag
... I have a proposal syntax
... 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
... <mesh><meshrow><meshpatch><stops>
... when defining tensor points, you could replace that with an array of rows by columns with a colour array as well
... one mesh consists of 16 points. These points could be described in an array of points.

shepazu: I don't know if that's simpler

Tav: The points and handles defining the patch map into the array
... if you are going to add the tensor points inside the patch, you cannot define them using the path syntax
... slide 33 has an example syntax

shepazu: I'd like to see real world examples of how this is used and how many patches are needed

Cyril: it's heavily used
... requires many many patches to make an image

shepazu: is this a good use for SVG?

TabAtkins__: it's a very good use for an SVG viewer

shepazu: is this something you could see being added CSS?

TabAtkins__: no.

shepazu: what we want is browser output that is consistent with the author's view in illustrator and inkscape

heycam: I'd like to avoid having the subdivision in the SVG

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

TabAtkins: is this a paint server or just geometry?

Tav: we decided if it's in the defs section it's a paint server, if it's not then it's geometry
... you need to be able to clip if it's a paint server

Resolution: SVG mesh gradients should have a method for enabling smoothing and smoothing should be default behaviour

<scribe> ACTION: Rik to find out what method Adobe uses for smoothing mesh gradients and report to group [recorded in http://www.w3.org/2012/09/19-svg-minutes.html#action02]

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

cabanier: if the patches are not hand editable then why not just make them really compact

shepazu: even if they're not hand editable they still need to be animatable

ed: One of my main concerns is a lot of details are missing from the spec at the moment

Tav: they will be added

ed: I'd like references to the algorithms used - they should be in the spec

Cyril: I'm not sure all the algorithms are royalty free
... at least one has a patent
... I think we won't be mandating a specific algorithm

TabAtkins: that's right, you require a certain output
... it just has to be black box compatible

ed: My other point is about hand authoring - it doesn't seem to be really possible
... if we were to have a simplified syntax that (perhaps) wouldn't provide the same accuracy but gives something that could be manipulated would be useful

shepazu: so it's common for people to use multiple meshes to create an object
... what's the bounding box?

TabAtkins: if it's geometry then the bounding box is the edges

cabanier: they fold over themselves

TabAtkins: that would be as if any path folds over itself

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
... then you fill it with some other thing that doesn't have geometery/size

cabanier: well we resolved that now radial gradients will have a boundary

shepazu: but you can't use getBBox on it

heycam: I think doug is saying it can be a mesh object as well as a paint server

shepazu: under what circumstances would you use it as a paint server?
... I don't think it is the primary purpose
... we have talked several times about integrating canvas and svg and having a similar path model
... now we are introducing a new element where you can't do that path stuff
... for the pepper, I might want to just get the outline

Cyril: you can

cabanier: what about when it folds over itself?
... the outline may not be the outermost path

heycam: if we had this method on circles, etc then it should work on the patch geometry as well

Cyril: if a patch overlaps itself the path would also, that's fine

shepazu: if I had line art and I want to colour it using mesh gradients how would I do that?

TabAtkins: you would use a paint server to contain the colour, the patches wouldn't match the geometry
... effectively, you would need to trace over the line art

shepazu: I think this has path like characteristics so it should have path like powers

Tav: I talked to the NVidia guy about HW acceleration and he said no problem.

Cyril: it's very simple
... When we selected Coon's patches, we also considered triangle patches.
... the more I read about vectorisation, the more I see this being used
... I am suggesting we add the triangular representation for meshes to SVG

heycam: is it wasteful to do the triangles using bezier paths?

Cyril: I would have to investigate but I suspect so

shepazu: Cyril, could you come up with a concrete proposal that shows syntax and outputs

<scribe> ACTION: Cyril to write up a proposal for a triangular representation for gradient meshes [recorded in http://www.w3.org/2012/09/19-svg-minutes.html#action03]

<trackbot> Created ACTION-3376 - Write up a proposal for a triangular representation for gradient meshes [on Cyril Concolato - due 2012-09-26].

GetSVGDocument deprecation/removal

SVGDocument interface (alias to Document?)

ed: this is a bout merging all the interfaces of SVGDocument onto document
... this is the direction HTML is going
... we would want a minimal representation for backwards compatibility

shepazu: what is the syntax in HTML5

<ed> http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#document

TabAtkins: HTMLDocument is an alias for document

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

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

heycam: document.forms would be a HTML collection object with length zero
... HTML collection is named HTML collection but it's really just a collection of any element

shepazu: what difference would this make to authors?

heycam: the difference will be additional properties

shepazu: we can remove details from our specification and refer to HTML5
... I'm in favour of this, we can special case things as we find them

TabAtkins: i.e. SVG links are returned as well as HTML links

heycam: we need to discuss the alias
... firstly in the IDL it becomes a partial interface for document
... the aliasing of the interface, presumably HTML does that for HTMLDocument

TabAtkins: it just aliases to document. We would use the same line in SVG

<TabAtkins> "For historical reasons, Window objects must also have a writable, configurable, non-enumerable property named HTMLDocument whose value is the Document interface object."

heycam: we will do the same thing

Resolution: SVGDocument will be an alias for document

<scribe> ACTION: ed make SVGDocument into an alias for document [recorded in http://www.w3.org/2012/09/19-svg-minutes.html#action04]

<trackbot> Created ACTION-3377 - Make SVGDocument into an alias for document [on Erik Dahlström - due 2012-09-26].

XLink deprecation

heycam: We might have already decided on this
... whether all attributes become href or whether some become source and some become href

TabAtkins: I think they should be whatever they all are right now
... we shouldn't change it, just drop the xlink prefix
... I think we should align script

heycam: there are quite a number of elements that have xlink:href

shepazu: the idea was that we use xlink:href for any external resource
... I don't mind if you can use href or src
... we are going to have to xlink:href and href so we might as well allow src too

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

list of things that use xlink:href

a - makes sense

alt-glyph is a reference to an element so should be href

animate elements - makes sense

color-profile - being removed

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

image - should allow src

TabAtkins: the ones I'm concerned about are image and script

shepazu: with image, it behaves differently in SVG than in HTML, so they don't have to align

TabAtkins: script is the one I feel really strongly about
... I might want script to accept 3 attributes, if there are not strong objections

shepazu: we resolved that href overrides xlink:href
... but there's more to it - i.e. how it is represented in the DOM

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Href

heycam: I like allowing src for script

shepazu: authors expect src

heycam: I propose that src overrides everything

TabAtkins: I'd put src between href and xlink:href

heycam: I'd like to encourage src

shepazu: me too

heycam: set always sets 'src' and 'get' gets the attribute that exists with the highest precedence.

shepazu: this makes me reconsider image, why are we doing src in some things and not src in others?
... we could align on src but say there's a couple of quirks with SVG image.
... 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

heycam: feImage should remain href because it can point to trees

TabAtkins: I'd like to stay doing what we currently do unless aligning with HTML

heycam: all the remaining elements in the list are href
... one final issue - on image the href DOM property is an animated string
... we should make .src be a DOM string that just reflects the base value, not the animated value

TabAtkins: There's 3 things
... firstly the xlink:href gain a plain href
... secondly, script and image gain a src attribute

thirdly, when getting from any, you get the highest precedence (src -> href -> xlink:href), when setting you set the highest that is available

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.

<scribe> ACTION: Cameron to add href on all elements with xlink:href and add src to image and script [recorded in http://www.w3.org/2012/09/19-svg-minutes.html#action05]

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

<Cyril> scribeNick: Cyril

Cameron's stuff

heycam: we have previously described ways of determining whether pointer-events were within the stroke region or the fill region or hte marker
... we settled on a method to tell you which region was hit
... I have done that
... it's in the spec

http://lists.w3.org/Archives/Public/public-svg-wg/2012JulSep/0194.html

<heycam> https://svgwg.org/svg2-draft/types.html#InterfaceSVGGeometryElement

scribe: I took upon myself to add a new interface
... on elements that can be filled and stroke
... there are 2 methods:

isPointInFill

isPointInStroke

scribe: initially it is taking a Point object in user space
... 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
... that's a separate thing that's handy to do
... oh, I forgot to make that change
... SVGPoint should have a constructor that takes an element and a mouse event
... if the element is not provided, it is assumed to be the target of the event
... I had the conversion integrated but this is cleaner this way
... I also worked on markers
... there is a separate interface

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

scribe: it's implemented on elements that can have markers on
... rahter than having a method is point in markers, which doesn't tell you whjich marker is used
... it uses a marker index
... this covers the automatic marker and the children marker

<cabanier> scribenick: cabanier

<Cyril> scribeNick: Cyril

scribe: in the same order as the rendering order

first the automatic ones and then the positioned ones

scribe: SVGMarkerList gives you a list of marker instances

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

scribe: giving you the marker, its position ...
... as a length along the path
... the actual point that it's at and the angle

andreas: can you get the segment it's on?

heycam: there is a method for that in PathSegment
... in fact angle and point are not strictly needed, but they are convenient

rik; can you change hte marker that you get?

heycam: yes, you can change the definition

andreas: sometimes you want to highlight hte marker that is selected

heycam: that would be difficult for the automatic markers, because you can't change just one

<birtles> (the method for getting the segment is SVGPathElement.getPathSegAtLength)

heycam: you probably need to use child markers

tab: I agree

heycam: the marker has now two new attributes: position and reference
... the SVGMarkerList does not let you add new markers
... it's only access to the computed list of all markers
... it might be a bit tricky to change that
... if this was useful for adding/removing makers
... we could have markers and childMarkers

brian: I noticed that the PathSegList throws an exception
... it is not consistent

heycam: if you use the squared brackets you will not get exceptions

brian: on marker list the getter is defined to return null if the index is out of range
... but other interfaces SVGPathSegList it is defined to throw an Index Size Error
... so we need to make them consistent
... one detail of that is that if you use square brackets syntax, you won't get an exception regardless of the index and range
... that's due to the behavior defined in WebIDL

heycam: you could use path.markers[n]
... if you use that even if me make the method throw an exception this won't
... but I'll add the exception to the method

<scribe> ACTION: heycam to make SVGMarkerList item method return an exception when the index is out of range [recorded in http://www.w3.org/2012/09/19-svg-minutes.html#action06]

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

<scribe> ACTION: heycam to make the SVGPoint changes to take a mouse event in the constructor [recorded in http://www.w3.org/2012/09/19-svg-minutes.html#action07]

<trackbot> Created ACTION-3380 - Make the SVGPoint changes to take a mouse event in the constructor [on Cameron McCormack - due 2012-09-26].

Hatchings

<Tav> http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_artists.svg#15_0

tav: this is a fairly common technical drawing in maps
... but you can use patterns but there are anomalies at boundarys
... but there is also a problem for plotters, because the pen goes up and down at each boundary
... open source plotters use SVG for that
... I'd like to have some feedback on a new syntax
... you specify an angle, origin, pitch and width
... if you want multiple fills you want to use multiple elements

tab: you are using the line element and it should probably a path element

tav: yes you could specify a pattern that gets extruded (slide 18)

heycam: dasharray is pitch: gap and width and gap ...

tav: by using the path syntax you can have more complicated hatchings

tab: would you do a line to if start and end don't match

tav: yes

tab: you determine how large the tile is by using the bounding box

cyril: how is it different from a pattern

tab: when you tile patterns you should paint each tile separately
... and that's not what you want for engravers for instance

cyril: what makes this behavior not possible with pattern?

(heycam drawing)

cyril: I don't understand why we need to introduce a new element just to change the rendering algorithm

doug: this makes it simpler to define a pattern that has overlaps with other pattern elements
... because it overlaps with itself

(doug drawing example of the zig-zag pattern)

brian: in some cases, when you have cross hatching

tab: I like the syntax on the second slide
... I don't like the more compact representation using the dash syntax

<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

doug: it would easier to animate this kind of pattern

(andreas showing point hatching)

tab: I like the idea, this is good!

doug: especially given the parameters that control the pattern repetition

brian: cross-hatching?

tav: easily done with multiple fills

cyril: what about nested hatchings?

tab: no, this just accepts paths
... what happens if you put more complex strokes?
... filling a stroke with a gradient or an image
... does it repeat on a per tile basis or more
... what is the gradientUnit

tav: I haven't thought about it

brian: how important is it to specify colors?
... couldn't you do it on the referencing?
... if you want a gradient, you could do it in a mask

tab: maybe we need to change line to hatchline so that its stroke property takes only a color and not a paint server

heycam: I'm nto sure it's impossible to have it work for gradients
... but I can see that so that markers don't go on there

tab: and also filling would be a non-sense

heycam: but it could be made consistent for the model
... I would still be fine with path and line instead of hatchpath and hatchline

brian: clip-path has restrictions
... already

heycam: it is analogous to clip-path

rik: yes, it's the opposite

<birtles> (that is, children of the clipPath element)

tab: if we say that some attributes are ignored, I would be fine with it

tav: offset tells you where you start with the pitch

tab: you could use the x,y attributes to encode the offset

brian: how do multiple fills work?

tab: we have to work that out yet

heycam: at some points, we want to allow multiple fills and multiple strokes without vector effect

tab: that is copy what CSS has done with background and that's the wrong way
... having a compound fill would be better

rik: I agree

brian: you could bundle a cross-hatch with a background for instance

RESOLUTION: SVG 2 will have a modified version Tav's hatch proposal

<scribe> ACTION: Tav to work out the details of the modifications of the initial proposal [recorded in http://www.w3.org/2012/09/19-svg-minutes.html#action08]

<trackbot> Created ACTION-3381 - Work out the details of the modifications of the initial proposal [on Tavmjong Bah - due 2012-09-26].

<scribe> ACTION: Tab to think about a compound paint server proposal [recorded in http://www.w3.org/2012/09/19-svg-minutes.html#action09]

<trackbot> Created ACTION-3382 - Think about a compound paint server proposal [on Tab Atkins Jr. - due 2012-09-26].

(andreas showing a marker centroid example)

<TabAtkins> ScribeNick: TabAtkins

andreas: [shows a mapping example where patterns are placed at the centroid of the various geometric objects]

TabAtkins: You could do that maybe as a marker positioned at the centroid?

shepazu: If we exposed that kind of thing, you'd want an explicit DOM API on <path> returning the centroid as well.

<scribe> ScribeNick: Cyril

doug: centroid is actually not trivial to calculate

heycam: we could make the hatching large enough so that it does not repeat
... actually you can use a pattern for that

doug: do we add a keyword for centroid

<shepazu> http://mathforum.org/library/drmath/view/57665.html

<stakagi> http://www.georeference.org/doc/transform_centroids.htm

(discussion on the centroid properties)

lunch!!

<andreas> Centroid: http://user.gs.rmit.edu.au/rod/files/publications/MSIA_Centroid.pdf

http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_artists.svg#19_0

<Tav> http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_artists.svg#19_0

<heycam> ScribeNick: heycam

extrapolated line join

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

Tav: we talked about this last time

… the question at that point was "what about the math"

… so I've provided it here

… it's straightforward

… you're looking at the curvature at the end of the path where the two segments join

… using that to draw circles, and you shrink or expand circles to the edges of the path, and extrapolate from there

TabAtkins: it's just expanding the circle so that it matches the edge of the path, rather than the center of the path

Tav: you can have a straight line, and then displace that by half a stroke width

… because sometimes these lines aren't going to intersect

… you might also want to apply a miter limit

TabAtkins: seems reasonable, thanks for working out the math

Cyril: the curvature doesn't take into account the stroke, just the path?

TabAtkins: correct

Tav: it's going to be the same thing

Cyril: is this implemented somewhere?

Tav: Inkscape has something similar but not quite the same

… the person implementing it just mirrored the path to get the curvature

… which I don't think you want to do

s/TabTakins/Tav/

cabanier: if they become a line, you miter them?

Tav: there are cases where the circles won't intersect, or if they're both lines

… then you fall back to miter

heycam: would you want to apply miter-limit to this join, and also to the fallback to a miter-limited miter?

TabAtkins: no, if the extrapolation doesn't work you fall back to bevel

… but yes apply miter-limit to extrapolated join

RESOLUTION: We will add extrapolated line joins to SVG 2, using Tav's proposal.

<scribe> ACTION: Tav to add extrapolated line joins to the spec. [recorded in http://www.w3.org/2012/09/19-svg-minutes.html#action10]

<trackbot> Created ACTION-3383 - Add extrapolated line joins to the spec. [on Tavmjong Bah - due 2012-09-26].

GetSVGDocument interface

heycam: [explains what GetSVGDocumentdoes]

ed: contentDocument doesn't work on embed

http://lists.w3.org/Archives/Public/www-svg/2012Aug/0095.html

heycam: from my testing there it looks like it is consistently not render on embed, yes

TabAtkins: I'm fine with keeping it in, for legacy purposes

… would be good to amend the spec to say that it returns the same as contentDocument for legacy purposes

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

RESOLUTION: Keep GetSVGDocument in SVG 2.

spaces/commas in SVG view specification

heycam: just wanted to confirm what our decision was

ed: we decided to allow commas and spaces in viewBox and preserveAspectRatio attributes, and to only allow comma separation in the view specification (for fragments)

heycam: ok

HTML integration

TabAtkins: I've started to push on getting html elements directly in svg

… but not the other way around

…but I will do that just for the resource-like elements (like clipPath)

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

SVG DOM improvements

heycam: I've added some constructors to SVG type interfaces

… for example https://svgwg.org/svg2-draft/types.html#InterfaceSVGLength

… three constructors there

… one initializes it to 0

… another takes the separate value and unit types

… and another takes a string

TabAtkins: the direction for CSS OM values api, is a constructor named "px"

<TabAtkins> el.style.width = CSS.px(5)

TabAtkins: then the length object has attributes for converting into various units

birtles: we had a proposal like that already

TabAtkins: this part of the CSS OM proposal is uncontroversial

heycam: how do SVGLength and CSSLengthComponentValue relate then?

TabAtkins: don't care, but they should behave the same
... you could also have CSS.length("20px")

heycam: would we use CSS.px() objects in place of SVGLength?

TabAtkins: you could make SVGAnimatedLength inherit from CSSLengthComponentValue

… and then add your baseVal animVal on there

<scribe> ACTION: Tab to write up how SVG types should work with CSS OM objects [recorded in http://www.w3.org/2012/09/19-svg-minutes.html#action11]

<trackbot> Created ACTION-3384 - Write up how SVG types should work with CSS OM objects [on Tab Atkins Jr. - due 2012-09-26].

rendering-mode: animate

shepazu: there are various rendering modes like geometricPrecision

… when you try to snap to pixels, this affects the rendering

… they're optional anyway, it's a hint

… one of the cases we talked about is when you're animating

… if you use crispEdges for text animation, it'll be jerky

… I'm proposing a hint "animate" so that the user agent know that this is going to be animated

TabAtkins: so it can switch to a low cost rendering mode?

cabanier: it's higher cost

shepazu: you should switch to a mode that gives the best visual effect for being animated

ed: if you render a rectangle slowly across the screen you'll see the snapping happening

… or the blurring if you use the normal one

cabanier: how would you solve it? draw half pixels?

heycam: how is it different from geometricPrecision?

shepazu: an author won't know that the way to make text look good when you're animating is "geometricPrecision"

… but if you have a mode called "animate", the author will know

… you could say in the spec "if you're animating, use geometricPrecision", but it will be hard for authors to discover

… I don't feel too strongly about it, just thought it would be easier to use

birtles: I think most UAs already detect if something is being animated and optimize it

Cyril: I think the difference is geometricPrecision, some heuristic could not detect what the user would prefer

… the browser can detect it's going to be animated

shepazu: maybe we should add in for crispEdges that browsers may wish to disregard this when animating text

ed: I think it depends on the device

heycam: we could add a note for "auto" to say that text shouldn't be pixel snapped when it is being animated

<Cyril> hand

RESOLUTION: {shape,text}-rendering should say that "auto" means that pixel snapping shouldn't be done when animating

<Cyril> hand

<Cyril> hand-

<TabAtkins> Gotta hand it to Zakim, he's pretty weird

<TabAtkins> On the other hand

<scribe> ACTION: Doug to add notes to {shape,text}-rendering auto to mention not doing pixel snapping when animating [recorded in http://www.w3.org/2012/09/19-svg-minutes.html#action12]

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

<Cyril> -hand

SVG documentation

shepazu: for W3C's documentation, I'd like to automatically extract element/attribute/property names and values from the spec

… if you could also send me tutorials you'd like to see

CSS Variables and Params

shepazu: params should use the variable mechanism for substituting values

… for text content, we need something to render it into the DOM, possibly <tref>

TabAtkins: make it accept a var() function in addition to a url()

shepazu: I'll work with Tab on this

rounded corners

shepazu: [draws a star with rounded corners]

… [but only on the outer points]

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

… you specify a radius

TabAtkins: this is like a custom line join?

shepazu: yes, basically

… a comma separated list that repeats like dash array

… you give a list of radii, and it applies them in sequence when a corner is encountered

TabAtkins: this is the arcTo from canvas

heycam: is this like a line join?

shepazu: but this should affect the fill
... with my proposal, you would say r="5", with Tab's proposal you'd have to change each edge in the path data

heycam: is this only straight line segments?

shepazu: no any segments

TabAtkins: you want to preserve curve continuity when you come into the arc

shepazu: Tab's counterproposal is better than what you can do in path today

TabAtkins: yes because you have to do trig

shepazu: this proposal could also apply to rect, polyline, polygon, star, connector

… on a connector, you might want it to go through an intermediate point (with an orthogonal connector)

… but with a rounded corner there

… this proposal reduces the amount that you have to type

… even on a <path>, it's easy then to style it differently

… rather than tweaking the path data

TabAtkins: sounds good to me

… the math shouldn't be hard to describe

shepazu: I also want there to be a way to pull this out

… toPathData() on a shape

… I'm not sure I want to see it on path, but on all other polygon-like elements

… on straight lines it's really easy

… but there could be some odd beziers that would have a bad effect with this

… so for paths leave it to arcTo, but r on other elements

… this property wouldn't give you control of x and y, just a single radius

… I'd like to see the difficulties it would introduce to path, because I'd like to see it there

TabAtkins: there will be some cases that will be difficult to translate into paths, and some that will look weird

shepazu: I don't mind about the edge cases
... sometimes it will add to the fill and sometimes it will remove from the fill

heycam: it always goes on the smaller angle? (<180 degrees?)

shepazu: yes
... the property would be dasharray-like, a sequence of radii

TabAtkins: if the r argument on a rect applied in the same order as border-radius that would be good

heycam: what about applying this to <rect rx ry>?

shepazu: rx ry should win
... if it's not possible to fit the circle between the segments, then it gets skipped

TabAtkins: is this an attribute or a property?

shepazu: property

<TabAtkins> also a presentation attribute

TabAtkins: just call the property "r"

<ChrisL> @tab all properties are also presentation attributes, in svg

ed: I want to allow the same thing that border-radius could do on rect

… different x/y radii

<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

shepazu: ellipses would be hard

<ed> ChrisL, yes, I meant to make <rect> a specialcase

TabAtkins: and you'd have to worry about rotation

shepazu: let's not do radii

s/radii/different x and radii/

*x and y

shepazu: the only element it wouldn't be allowed on is ellipse

<krit> Why not on a per element basis in general

<krit> circle, rect, ellipse doesn't make sense for me with a new r

rect does, since you can have different things at different corners

circle and ellipse I don't think it's needed

<krit> heycam: Isn't rx and ry enough on rect?

<birtles> krit: they set the same radii on all vertices

<ChrisL> @krit only one value for the whole rect, though

<krit> ok

<ChrisL> although we could extend rx and ry on rect to allow (1..4) values

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

birtles: when do you want to set different radii on different points?

TabAtkins: for the star example, you want radius, no radius, radius, no radius, ...

<ChrisL> as noted earlier, rect differs by allowing elliptical arc (already). only circluar arc on plyline, polygon and path though

elliptical arcs make less sense (at least, they're harder) on non 90-degree angles

<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

i.e. not rect

<shepazu> ChrisL, we're proposing both

TabAtkins: we can extend rx/ry attributes too

<ChrisL> while adding the new r property on path, polygon, polyline and star

<ChrisL> ok

RESOLUTION: We add Doug's r="" proposal for rounded corners for shape-y elements, and pending the math, for paths too.
... We also allow rx/ry to extend to multiple values on rect.

<scribe> ACTION: Doug to add the r="" proposal to SVG 2. [recorded in http://www.w3.org/2012/09/19-svg-minutes.html#action13]

<trackbot> Created ACTION-3386 - Add the r="" proposal to SVG 2. [on Doug Schepers - due 2012-09-26].

<ChrisL> i can take the rx ry extending action

<scribe> ACTION: Chris to extend rx/ry on rect to allow lists of values. [recorded in http://www.w3.org/2012/09/19-svg-minutes.html#action14]

<trackbot> Created ACTION-3387 - Extend rx/ry on rect to allow lists of values. [on Chris Lilley - due 2012-09-26].

there might be some complications with the DOM there, they're SVGAnimatedLengths now -- would they become SVGAnimatedLengthLists? not sure.

<ChrisL> yes I suspect so

<ChrisL> do people depend on that in code?

it's possible

<ed> since we're making them properties we'd need to probably change the DOM somehow anyway

less likely than x/y/width/height but certainly possible

<ChrisL> so that could be a script breaking change

could be

it should be thought about ):

s/):/:)/

JSON serialization

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

TabAtkins: the one change I made to your page was removing the ability to do multiple segments with the one command letter

cabanier: you could make x/y/etc. into an array

shepazu: you could have p[0].x, p[0].y, p[1].x, p[1].y

TabAtkins: what does that buy you?

<krit> what? ZAKIM!!!

cabanier: it would help you iterate over them

TabAtkins: you would never want to do that

shepazu: you also changed sweepFlag to clockwise

TabAtkins: yes

birtles: what's wrong with an array of points in each command?

TabAtkins: it's a bit harder to work with

… for a MoveTo, for example, instead of blah.x you have to do blah.p[0].x

<krit> couldn't it also mean that the number of input elements is unpredictable?

birtles: if you take this and turn it back into a string, it's easier if it's an array
... there was one library I was using...

<TabAtkins> s/p\[0\].x/p\[0\]/

… it uses points

… but I can see that could be cumbersome

heycam: if you have a fixed number of points per command (<= 4) which we do, then I think not use an array is better

shepazu: one downside to this is that it doesn't map to the existing path command letters

<krit> paper.js also has a Path API you could look at http://paperjs.org/reference/

shepazu: this current proposal it's more verbose but clearer

cabanier: it doesn't use more memory really

ed: will we have path commands that take arbitrary parameter lists?

TabAtkins: you can't, because you can't do the automatic segment repetition that the existing commands do
... the catmull-rom command takes a list of points though

shepazu: yes I wanted to have a new "p" start a separate catmull-rom curve

<scribe> ACTION: Tab to investigate paper.js' arcThrough [recorded in http://www.w3.org/2012/09/19-svg-minutes.html#action15]

<trackbot> Created ACTION-3388 - Investigate paper.js' arcThrough [on Tab Atkins Jr. - due 2012-09-26].

<cabanier> *krit: we're looking at the paper.js stuff *

JSON serialization of SVG

shepazu: there are some reasons to want a standardised JSON serialisation of markup in general, including SVG

… this is something that some script libraries do anyway

… it would be good to have a unified way for them to use JSON serializations of SVG

… rather than each have an ad hoc one

… another thing is it would be useful for postMessage

… this is more general than SVG really

… it wants to be able to serialise any given markup

… this is not recommended for browsers to implement

TabAtkins: we would attach a toJSON to Element, and a fromJSON to Document

-- end --

<stakagi> http://www.w3.org/Graphics/SVG/WG/track/issues/2050

stakagi: for the JSON path syntax, the names should align with the proposal for expanded path segment elements

RRSAgent: make minutes

- DRAFT -

SVG Working Group Teleconference

19 Sep 2012

Attendees

Contents