W3C home > Mailing lists > Public > public-svg-wg@w3.org > July to September 2012

minutes, Rigi-Kaltbad SVG WG F2F 2012 - Day 3

From: Cameron McCormack <cam@mcc.id.au>
Date: Wed, 19 Sep 2012 17:34:45 +0200
Message-ID: <5059E615.5090300@mcc.id.au>
To: SVG WG <public-svg-wg@w3.org>
http://www.w3.org/2012/09/19-svg-minutes.html


    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                     SVG Working Group Teleconference

19 Sep 2012

    [2]Agenda

       [2] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/Agenda

    See also: [3]IRC log

       [3] http://www.w3.org/2012/09/19-svg-irc

Attendees

    Present
           Erik, Cameron, Nikos, Doug, Tab, Rik, Cyril, Takagi-san,
           Tav, Konno-san, Brian

    Regrets
    Chair
           Cameron

    Scribe
           nikos, Cyril, cabanier, TabAtkins, heycam

Contents

      * [4]Topics
          1. [5]radialGradient @fr
          2. [6]Mesh Gradients
          3. [7]GetSVGDocument deprecation/removal
          4. [8]SVGDocument interface (alias to Document?)
          5. [9]XLink deprecation
          6. [10]Cameron's stuff
          7. [11]Hatchings
          8. [12]extrapolated line join
          9. [13]GetSVGDocument interface
         10. [14]spaces/commas in SVG view specification
         11. [15]HTML integration
         12. [16]SVG DOM improvements
         13. [17]rendering-mode: animate
         14. [18]SVG documentation
         15. [19]CSS Variables and Params
         16. [20]rounded corners
         17. [21]JSON serialization
         18. [22]JSON serialization of SVG
      * [23]Summary of Action Items
      __________________________________________________________

    <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>
    [24]http://jaspervdg.wordpress.com/2012/09/03/specifying-radial
    -gradients/

      [24] 
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__>
    [25]http://dev.w3.org/csswg/css3-images/#find-the-average-color
    -of-a-gradient

      [25] 
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
    [26]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>
    [27]http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_ar
    tists.svg#36_0

      [27] 
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
    [28]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
    [29]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>
    [30]http://www.whatwg.org/specs/web-apps/current-work/multipage
    /dom.html#document

      [30] 
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
    [31]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> [32]https://svgwg.org/svg2-draft/attindex.html

      [32] 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> [33]http://www.w3.org/Graphics/SVG/WG/wiki/Href

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

    [35]http://lists.w3.org/Archives/Public/public-svg-wg/2012JulSe
    p/0194.html

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

    <heycam>
    [36]https://svgwg.org/svg2-draft/types.html#InterfaceSVGGeometr
    yElement

      [36] 
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>
    [37]https://svgwg.org/svg2-draft/painting.html#InterfaceSVGMark
    ableElement

      [37] 
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>
    [38]https://svgwg.org/svg2-draft/painting.html#InterfaceSVGMark
    erInstance

      [38] 
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
    [39]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
    [40]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>
    [41]http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_ar
    tists.svg#15_0

      [41] 
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
    [42]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
    [43]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>
    [44]http://mathforum.org/library/drmath/view/57665.html

      [44] http://mathforum.org/library/drmath/view/57665.html

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

      [45] http://www.georeference.org/doc/transform_centroids.htm

    (discussion on the centroid properties)

    lunch!!

    <andreas> Centroid:
    [46]http://user.gs.rmit.edu.au/rod/files/publications/MSIA_Cent
    roid.pdf

      [46] 
http://user.gs.rmit.edu.au/rod/files/publications/MSIA_Centroid.pdf

    [47]http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_ar
    tists.svg#19_0

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

    <Tav>
    [48]http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_ar
    tists.svg#19_0

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

    <heycam> ScribeNick: heycam

extrapolated line join

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

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

    [51]http://lists.w3.org/Archives/Public/www-svg/2012Aug/0095.ht
    ml

      [51] 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
    [52]https://svgwg.org/svg2-draft/types.html#InterfaceSVGLength

      [52] 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
    [53]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
    [54]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
    [55]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
    [56]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>
    [57]http://www.w3.org/Graphics/SVG/WG/wiki/Path_toJSON

      [57] 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[$1\47].x, p[$1\47].y, p[$1\47].x,
    p[$1\47].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[$1\47].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
    [58]http://paperjs.org/reference/

      [58] 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
    [59]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>
    [60]http://www.w3.org/Graphics/SVG/WG/track/issues/2050

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

Summary of Action Items

    [NEW] ACTION: Cameron to add href on all elements with
    xlink:href and add src to image and script [recorded in
    [61]http://www.w3.org/2012/09/19-svg-minutes.html#action05]
    [NEW] ACTION: Chris to extend rx/ry on rect to allow lists of
    values. [recorded in
    [62]http://www.w3.org/2012/09/19-svg-minutes.html#action14]
    [NEW] ACTION: Cyril to write up a proposal for a triangular
    representation for gradient meshes [recorded in
    [63]http://www.w3.org/2012/09/19-svg-minutes.html#action03]
    [NEW] ACTION: Doug to add notes to {shape,text}-rendering auto
    to mention not doing pixel snapping when animating [recorded in
    [64]http://www.w3.org/2012/09/19-svg-minutes.html#action12]
    [NEW] ACTION: Doug to add the r="" proposal to SVG 2. [recorded
    in [65]http://www.w3.org/2012/09/19-svg-minutes.html#action13]
    [NEW] ACTION: ed make SVGDocument into an alias for document
    [recorded in
    [66]http://www.w3.org/2012/09/19-svg-minutes.html#action04]
    [NEW] ACTION: heycam to make SVGMarkerList item method return
    an exception when the index is out of range [recorded in
    [67]http://www.w3.org/2012/09/19-svg-minutes.html#action06]
    [NEW] ACTION: heycam to make the SVGPoint changes to take a
    mouse event in the constructor [recorded in
    [68]http://www.w3.org/2012/09/19-svg-minutes.html#action07]
    [NEW] ACTION: Rik to find out what method Adobe uses for
    smoothing mesh gradients and report to group [recorded in
    [69]http://www.w3.org/2012/09/19-svg-minutes.html#action02]
    [NEW] ACTION: Tab to investigate paper.js' arcThrough [recorded
    in [70]http://www.w3.org/2012/09/19-svg-minutes.html#action15]
    [NEW] ACTION: Tab to think about a compound paint server
    proposal [recorded in
    [71]http://www.w3.org/2012/09/19-svg-minutes.html#action09]
    [NEW] ACTION: Tab to write up how SVG types should work with
    CSS OM objects [recorded in
    [72]http://www.w3.org/2012/09/19-svg-minutes.html#action11]
    [NEW] ACTION: Tav to add extrapolated line joins to the spec.
    [recorded in
    [73]http://www.w3.org/2012/09/19-svg-minutes.html#action10]
    [NEW] ACTION: Tav to specify radial gradient behaviour when the
    focal point is outside the circle [recorded in
    [74]http://www.w3.org/2012/09/19-svg-minutes.html#action01]
    [NEW] ACTION: Tav to work out the details of the modifications
    of the initial proposal [recorded in
    [75]http://www.w3.org/2012/09/19-svg-minutes.html#action08]

    [End of minutes]
Received on Wednesday, 19 September 2012 15:35:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 19 September 2012 15:35:36 GMT