SVG Working Group Teleconference -- 28 Oct 2011

<heycam> ... there was a level of zoom requirement item too

<heycam> ... just put an attribute for minimum/maximum zoom level on any element

<heycam> CM: the Tiling/Layering will be a separate document, right?

<heycam> CL: that won't allow you to do the complex/simpler path kind of level of detail though

<heycam> [discussion of differences between tiling, LoD, auto fetch/discard]

<heycam> RESOLUTION: We won't include automatic fetch/discard in SVG2.

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Level_of_detail_control

<heycam> CM: this one sounds more interesting to me

<ChrisL> http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/#VisibilityControllingAccordingToZooming

<heycam> RESOLUTION: We will support Level of Detail control in SVG2.

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Templating_for_controls.2Fwidgets

<heycam> CC: now the one we should go back to is templating for controls and widgets

<ed> ED: already resolved earlier this morning

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_transform.3D.22.22_to_.3Csvg.3E

<heycam> ED: next, transform on svg elements

<heycam> CL: what does that help with?

<heycam> ED: nested svg elements

<heycam> CM: seemed odd to me not to allow transform on svg

<heycam> ... but it might be confusing for authors wrt order of application of transform and viewBox

<heycam> RESOLUTION: We will allow transform on <svg> in SVG2.

<heycam> ED: next, allowReorder on switch

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Add_.40allowReorder_to_.3Cswitch.3E_for_improved_language-based_switching

<heycam> CL: this came out of a request from mozilla that switch with requireLanguage is less useful when you have a list of ordered preferred user languages

<heycam> ... it got added in SMIL3

<heycam> CM: it has a bad name

<heycam> RESOLUTION: We will support a mechanism like or the same as allowReorder from SMIL3 in SVG2.

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Allow_referencing_root_external_files_with_.3Cuse.3E

<heycam> ED: next, allow referencing root external files with use

<ChrisL> ISSUE-2238:

<heycam> DH: with <use>, you get the same animation timeline, vs if you use image

<heycam> CM: also with events you can distinguish which shadow tree elements was clicked, for example

<heycam> DH: would this apply to other things that reference external elements, like mask?

<heycam> ED: maybe wouldn't make sense there

<heycam> CC: there is the animation element in 1.2T, is that relevant here?

<heycam> ED: but that only references a whole document anyway

<heycam> CL: in 1.2T we split it up into <image> for more static images, and <animation> for animated ones

<heycam> ... with <animation> you can use the SMIL timing attribtues on it, so you can control its timeline separately

<heycam> ... but you can't do that with animated SVG referenced from <image>

<heycam> ... the name animation is confusing though, compared to animate

<heycam> ... in the end though image was able to point to svg content

<heycam> ... so we may or may not want to keep <animation>, possibly renamed

<heycam> RESOLUTION: We will relax referencing requirements to particular elements to allow dropping fragments to mean referencing root element, where it makes sense, such as with use, in SVG2.

<heycam> ACTION: Cyril to investigate whether more than use would benefit from relaxing reference requirements so that "blah.svg" refers to the root element [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action01]

<trackbot> Created ACTION-3157 - Investigate whether more than use would benefit from relaxing reference requirements so that "blah.svg" refers to the root element [on Cyril Concolato - due 2011-11-04].

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Parameters

<heycam> ED: next, in the Attributes section, is Parameters

<heycam> CC: we need this

<heycam> DS: we decided last time that we would not make this general

<heycam> CC: in what sense?

<heycam> DS: in the sense that this would not be a CSS thing, it's an SVG thing

<heycam> ... although people are going to want to pass things in to CSS

<heycam> ... in CSS embedded in SVG, you would want a legal value to be a param

<heycam> ... I think we thought it would take too long to get into CSS as well

<heycam> ... but having it attribute only would have this downside

<heycam> ... especially if people are using SVG and CSS together more

<heycam> CM: I would really like to see if we can use CSS Variable as the in-CSS way to reference parameters

<heycam> DS: maybe we should move ahead with it as a separate spec

<heycam> CL: Tab is in general happy to add new values to CSS Values

<heycam> DS: it's effectively like calc, in terms of scope

<heycam> ... I see param working with calc really well

<heycam> CC: do we want to allow params to work with presentation attributes, style properties, geometry attributes, SMIL attributes...?

<heycam> DS: I want it to apply to every SVG attribtue, and maybe property values as well

<heycam> CC: how about using them in script?

<heycam> DS: there's the DOM interface that exposes params and their values

<heycam> ... anything I do with params I would like to decompose a shorthand for Component Model

<heycam> [discuss some details of Params]

<heycam> DH: I would be a bit concerned about being gated on CSS work

<heycam> DS: we could say that for now, it works only in attributes, but that we're open to the CSS WG allowing this in property values

<heycam> ... and I'd expect there'd be experimental implementations to see if there are any issues with allowing that

<heycam> CL: we did already talk about this within FX

<heycam> RESOLUTION: We will have Parameters in SVG2, worked on in a normatively referenced separate spec.

<ChrisL> Meeting; SVG WG f2f Mountain View

<heycam> shepazu, http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/

1075 La Avenida

Mountain View, CA 94043

Tel: (650) 693-1005

Building 5

<shepazu> thanks

<trackbot> Date: 28 October 2011

<heycam> Meeting: SVG Working Group Mountain View F2F 2011, day 2

<heycam> Chair: Cameron

<ChrisL> Scribenick: ChrisL

SVG2 Requirements Input

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Custom_data-.2A_attributes

Custom data attributes

heycam: this is to align with HTML5
... confusing to not be abletodio this in mixed html5/svg

(general agreement)

resolution: we willadd data-* attributes in SVG2 to align with HTML5

randomisation

ed: this could be done in script

cc: there is not much of a proposal here

resolution: we will not add declarative randomisation functionality in SVG2

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_certain_HTML_attributes_used_in_microformats

Consider adding certain HTML attributes used in microformats

ISSUE-2048?

<trackbot> ISSUE-2048 -- Consider adding certain HTML attributes used in microformats -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2048

ChrisL: ARIA isalso somethig that should be supported - related

heycam: higher level goal is to bring across globalattributes thatmake sense, ratherthan thesespecific ones
... consider together with aria

resolution: we will align with HTML5 globalsemantic attributes wherethese make sense for SVG

<scribe> ACTION: ChrisL to look at global attributes [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action02]

<trackbot> Created ACTION-3158 - Look at global attributes [on Chris Lilley - due 2011-11-04].

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_relaxing_case_sensitivity_of_presentation_attribute_values

Consider relaxing case sensitivity of presentation attribute values

heycam: there were complaints about this at svgopen

vhardy: the complaint was actually attribute and element names being case sensitive
... we could deprecate oneset of names and introduce new ones

ChrisL: makes more confusion than it helps

vhardy: example is textPath, cant search for getElementbyTagName

ChrisL: so it does work as long as you spell it consistently

heycam: tested just now, it recognises the statndard spelling but does not recognised the fixed-up name

<heycam> If you have `<!DOCTYPE html>...<textpath ...>` then you do document.getElementsByTagName("textpath"), it won't find the element

<heycam> but if you do ...getElementsByTagName("textPath") it will

<heycam> If you have `<!DOCTYPE html>...<textPath ...>` and you do document.getElementsByTagName("textPath"), it will find it

ChrisL: it only fixes up when parsing, not in script

heycam: wonder about adding magic to getElementsByTagName

cyril: two issues,values and element/attribute names.

heycam: any objections to making property values as attributes case insensitive?

cyril: IDs are case sensitive

erik: all presentation attributes are safe to do this with

resolution: make property values case insensitive

ChrisL: so in the dom the case is preserved?

heycam: yes

ChrisL: sad that the dom is still required to preserve whatever case combination was used each time, in case you ask for it back
... could this be normalised like we did in udom?

heycam: hellno

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Fluorescent_colours.2Fextended_colour_specifiers

Fluorescent colours/extended colour specifiers

(chris talks at lemngth and forgets to minute)

<heycam> http://dev.w3.org/SVG/modules/color/publish/SVGColor.html

<scribe> ACTION: chris to reply to alex explaining how wide gamut colours and flourewscent/metallic printing are accomodated in SVG color [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action03]

<trackbot> Created ACTION-3159 - Reply to alex explaining how wide gamut colours and flourewscent/metallic printing are accomodated in SVG color [on Chris Lilley - due 2011-11-04].

http://dev.w3.org/SVG/modules/color/master/SVGColor.html

ChrisL: have several offers of reviews for this. would like to publish, get the review, then go to w3c last call

heycam: should this be normatively required by SVG2

this is something operating systems all do not (but not onmobile)

cyril: name is confusing can we rename to color-management
... intro shouldsay it is a supersetof SVG color chapter and of CSS3 color

ChrisL: yes it should state that explicitly

ed: what t do with css3 images and css gradients as they affect paint?
... ok with the conformance class that does color managed images

heycam: we can have several conformance clasees in this spec then decide later which ones svg2 requires

ChrisL: happy with that

resolution: svg2 will depend on svg colormanagement subject to deciding the exact conformance classes required

ChrisL: this could be a separte module or it could be a chapter, its written as a drop-in replacement actually
... makes more sense to have this as the color chapter in fact

(agreed)

resolution: svg colormanagement becomes a chapter in SVG2

<scribe> ACTION: ChrisL to edit the svg colormanagemtn spec into a chapter in SVG2 [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action04]

<trackbot> Created ACTION-3160 - Edit the svg colormanagemtn spec into a chapter in SVG2 [on Chris Lilley - due 2011-11-04].

<scribe> scribenick: dholbert

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Non-scaling_stroke

non-scaling stroke

CM: lots of people want this, and it's not too hard to implement

CL: Yes

<tbah> Hi, phone?

resolution: svg2 will include non-scaling stroke

<ChrisL> tbah: inkscape has non scalingstroke and non scalling patterns

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Non-scaling_rounded_rect_corners

non-scaling rounded rect corners

ED: maybe things in general that are non-scaling could go into another coordinate system

CM: might be interesting to look into other things that you might want to not scale

CC: e.g. rectangle with radius=5 on the corner, you might want to grow the rectangle but not grow the radius of the corner
... there's also non-scaling whole objects, e.g. legends in a map

CL: doesn't tiny 1.2 let you do something like that, by saying "this part is in the coordinate system over there"?

CC: we also have the transformBehavior attribute, for video

<stakagi> ref(svg,x,y)?

CC: it has the value 'pinned' which would help with this as well

ED: it'd be nice to hear more about the non-scaling things in inkscape

CL: non-scaling patterns (inkscape option) sounds interesting

CM: perhaps tav can write up a summary of inkscape's non-scaling features

TB: sure

<scribe> ACTION: tav to write up summary of inkscape's non-scaling features, as possible candidates for svg2 [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action05]

<trackbot> Created ACTION-3161 - Write up summary of inkscape's non-scaling features, as possible candidates for svg2 [on Tavmjong Bah - due 2011-11-04].

resolution: svg2 should include non-scaling features, aside from non-scaling stroke. (2 separate components: non-scaling part of the object, and non-scaling entire object)

variable stroke-width

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Variable_stroke_width

CL: we're lacking a fully fleshed-out proposal for this
... we don't want to be forced to put stroke-width "stops" only at the nodes
... more like a gradient, with stops that can be specified
... and each stop has a stroke-width specified

VH: how do you author variable stroke-width in inkscape?

TB: there are 2 ways. the one in inkscape is
... you draw a path, and then a second path the "skeleton", and the first path is warped along the skeleton
... one path describes the width, and that gets put along the other path.
... e.g. you could draw a lizard, and bend the lizard along the path
... so that's the first method. the second method is: you add nodes along the path, and manipulate those (like what CL described with "stops")

<tbah> http://tavmjong.free.fr/SVG/SVGOpen2011/INKSCAPE/svg_2011_inkscape.svg

VH: warping is interesting, since we need to do that for text anyway

CL: but the "stops" way is more natural for e.g. drawing with a pressure-sensitive pen

resolution: svg2 shall include variable stroke-width

perpendicular stroke

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Perpendicular_stroke

ED: I think this is roughly the same as stroke-position

CM: This is something many people want to be able to do

resolved: svg2 shall include a way to specify stroke-position

resolution: svg2 shall include a way to specify stroke-position

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Stroke_position

define behavior of stroke-dasharray

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Define_behaviour_of_stroke-dasharray

CM: what isn't defined at the moment?

CL: the start point of the dashing on basic shapes like circles
... and on multi-segment paths, e.g. if you're partway through a dash at the end of one segment, do you start the next segment with just a partial dash

resolution: svg2 shall specify stroke dashing more precisely

adaptive stroking

<CM> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Adaptive_stroking

CM, to be able to do things like align dashes exactly on corner of a rectangle

resolution: svg2 shall allow more author control over positions of dashes

hatch fills

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Hatch_fills

TB: Couple problems with trying to use patterns for this. one is, if you use a diagonal line, you'll often get misalignments
... also, SVG is used for e.g. engravers, who want to be able to do one continuous stroke across a background.

CL: same applies to plotters

CM: not sure if this would have a predefined set of hatches, or let you define your own

CC: could be useful for cartoons

ED: though in that case you could probably just use a pattern

<ChrisL> Hatching (hachure in French) is an artistic technique used to create tonal or shading effects by drawing (or painting or scribing) closely spaced parallel lines

<ChrisL> http://en.wikipedia.org/wiki/Hatching

VH: I've encountered the issue with patterns. the main convincing argument to me is TB/CL's points about one needing continuous lines for certain use-cases

CM: It seems like something worth looking into

resolution: svg2 should support hatching without the artifacts that patterns currently impose

<ChrisL> http://fr.wikipedia.org/wiki/Hachure has more detail actually

arbitrary fill

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Arbitrary_fill

CM: sounds like we've got this already solved by CSS image-values

CL: seems like this could be simpler than that though, just expanding the types of things that are allowed as paint servers

CC: would we need to specify preserveAspectRatio=meet|slice?

JY: would we need the background-* properties? e.g. background-position, background-size

CM: SVG doesn't really know about background images at the moment

CL: but we could model the behavior off of that, perhaps

resolution: svg2 shall support filling and stroking from arbitrary elements

SVG using webgl filters

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SVG_using_WebGL_filters

ED: I think it's covered by CSS shaders, depending on the outcome of the discussion there

CM: there's a question of whether that's a hard dependency

CL: the ability to write custom shaders is pretty important

resolution: svg2 shall support custom filters (shaders)

consider adding an href to style element to link to external stylesheets

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_an_href_to_the_style_element_to_link_to_external_stylesheets

CM: I wouldn't like to be different from HTML's syntax for this
... and note that you can already @import from inside of style

<ChrisL> ISSUE-2049: this would diverge ftom HTML, better to add the link element. Can also do @import

<trackbot> ISSUE-2049 Consider adding an href to the style element to link to external stylesheets notes added

JY: perhaps this is wanting to bring in the <link> element? (that's what is used for this in HTML)

resolution: svg2 shall not add href to the <style> element

add HTML5 style-element attributes to SVG's style element

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Add_HTML5_style-element_attributes_to_SVG.27s_style_element

CM: this is e.g. 'media' and 'scoped' attributes

<heycam> http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-style-element

<ChrisL> http://www.w3.org/TR/html5/semantics.html#the-style-element

resolution: svg2's style element shall be aligned with the html5 style element

alternative transforms

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Alternative_transforms

CC: jasper proposed nonlinear transforms; that's what vertex shaders are about

VH: you actually deform a texture; you're not deforming the geometry itself

<tbah> Conference timed out, could you restart?

<tbah> Thanks

CC: jasper wanted to separate the gradient map from the transformation map
... the transformation map could be used for text warping or object warping
... I think it's very similar to vertex shaders; you have an initial object, you give the end object, and you interpolate in between

CM: If we have vertex shaders, do we need this?

CL: Shaders are about transforming the rendered result; this is about transforming the geometry

VH: For example, if you're transforming a straight line into a curve, a vertex shader would transform it into small line segments - not actually transform the geometry

CM: we're already getting perspective transforms from CSS3 transforms, right?

VH: yes, but that's transforming the rendered output, not the geometry
... in SVG, with geometry transforms, we think about it transforming the bounding box. With a warp filter, you wouldn't get the bounding box from the resulting rendered output

TB: How do you define these transforms?

CM: That's an open question

TB: mathematical equations?

CC: or you provide a grid before/after
... I'm concerned in terms of authoring, that you'd end up with lots of shaders, lots of GLSL - not really declarative.
... it should be possible to specify a transformation without writing a shader

CM: In some ways I'd like to be able to do fancy warping, but it seems like a really open-ended/big feature

CL: mercator was one of the suggested transformations; if we were to make a fixed list of allowed transformations, someone's always going to want a different one
... so it'd need to be customizable
... so I have concerns over complexity & extensibility

<ed> http://blockses.appspot.com/1246403

CM: we also haven't seen people using script to do these kinds of effects
... but with a nicer API, we might see people doing more of this

ED: that example I just pasted is a 3D projection of a world map, so people are doing that kind of thing

(demo of spinning globe, with SVG countries painted onto it)

CC: It'd be really cool to be able to animate a globe like this with declarative animation, without needing any script

CM: to be happy moving forward with something, I'd want some kind of proposal & people really championing it / wanting to implement it

resolution: svg2 shall not include alternative transforms, in the absence of a convincing proposal

other 2.5D effects

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Other_2.5D_effects

CM: <replicate> is listed here, but that belongs under 'declarative drawing'
... and the other things fall under the previous topic
... and in fact the next one as well ('non-rectilinear layout models') -- that sounds like arbitrary warping transforms as well.
... that sound like the same use-case as like the mesh transforms

Support getting bounding boxes that include stroke and/or markers

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Support_getting_bounding_boxes_that_include_stroke_and.2For_markers

CL: I think we went over this in the 1.1 timeframe; we decided not to put it in 1.1 but we thought we'd put it in 2
... we definitely decided to add it, and it's been asked for since
... [expresses displeasure for markers]

resolution: svg2 shall include better bounding-box querying functions

Consider allowing rotations to be relative to their bounding box center

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_allowing_rotations_to_be_relative_to_their_bounding_box_center

TB: this is a good idea; you also need to be able to specify the center of rotation

CL: We get this for free in the CSS transforms

CM: hopefully all the CSS properties we support will have presentational attributes, too

CL: yes

CC: So in CSS, this is the "transform-origin" property?

CL: yes. CSS defaults to rotating about the center, whereas SVG defaults to rotating about upper-left corner

TB: how do you get the center of e.g. a rotating 5-pointed star, where the bounding box changes as it rotates?

VH: the center of rotation would be chosen pre-transform

resolution: we will ensure there is a way to specify rotations around particular points and shapes

TB: Inkscape stores a transformation center; used for scaling, for skewing
... not just for rotations

VH: something similar in illustrator, too

<ed> scribeNick: ed

vector effects

CL: geometry api?

CM: vincent wanted to talk about that
... maybe we can have that discussion later

<ChrisL> action-1?

<trackbot> ACTION-1 does not exist

<ChrisL> action-100?

<trackbot> ACTION-100 does not exist

CM: we were discussing having better interfaces for points, paths, and combining and offsetting

CL: the other one was stroke-below-fill
... assuming this ends up as a vector-effect value

DS: i suspect that CSS ppl are going to think it's like an underline

CL: fill then stroke then markers

DS: what if it's the middle thing?

CL: markers, fill, then stroke?

DS: it's not the full functionality, it's a shorthand

CC: what if you wanted to have both non-scaling-stroke AND stroke-below-fill?
... what's the philosophy behind the vector-effects property?

CL: it's like a filter effect
... I could do add combination value keyword

CM: concerned about using vector-effect for this

CL: most things in filter effects are called 'feSomething', and in vector effects 'veSomething'

DS: is the property vector-effect appropriate and intuitive to what ppl would expect?
... what if you wanted the fill on top of the stroke for text in html?
... do we have the same mechanism for that?

CM: so you want a slightly differnt way to express this, rihgt?
... mapping the "i want stroke under the fill" to using "vector-effects" perhaps is not so intuitive
... though having them separate might make it harder for linking it to vector-effects
... we have existing stroke and fill, and that's input to the vector effects

CL: plus the styling

<ChrisL> stroke-order: above-fill (default) | below-fill

CM: it's not the order that's below the fill

DS: maybe we could have a poll to what's most intuitive?

CM: but maybe we could resolve on separating the property out, not making it a vector-efffect shorthand

<ChrisL> paint-order: fill-stroke-marker| stroke-fill-marker | and so on

RESOLUTION: we will have a property that means stroke underneath fill vector-effect shorthand, but not using the vector-effect property

CL: do we want to use vector-effects=non-scaling-stroke as is, or separate it out?

DS: could be a threshold, scale up as much as it can go, but min value is 1

CM: would like to see this as a separate property for non-scaling-stroke

DS: helps discoverability

ED: so vector-effects would only be the url() syntax?

CM: if we don't come up with something else that we can use as shorthands

ED: slight concern about backwards compat, since it's implemented as a vector-effect shorthand already
... also non-scaling-stroke="yes|no"? seems a bit silly
... and all other stroke properties are prefixed 'stroke-'

DS: to me it's a vector-effect, underneath it's the same thing
... doesn't need to be called vector effect...

CM: it's not terrible in vector-effects, but i'd prefer it as a separate attribute
... the painting order is a simple thing compared to the vector effects

RESOLUTION: we will keep vector-effect=non-scaling-stroke as is

<stakagi> Initially, I thought that ref (svg, x, y) made it satisfied for non-scaling-whole-objects.

<stakagi> But, another fixed-size-shapes may be required.

<stakagi> Differ from the ref(svg,x,y), for map usecase totally fixed-size-shape are required, such as line-width of vector effects. By ref(svg,x,y), shape size is fixed but initial size is not fixed according to ( SVG user agent viewport and viewBox))

<heycam> stakagi, I think the performance concern's true, as long as the appropraite coordinate space is the root element

CL: yes, we mentioned ref before, it's on the requirements list right?

<stakagi> This matter is pointed by Alex

CM: so you want to get around the outermost svg scaling and get a fixed pixel size for the scaling to screen

<ChrisL> http://www.w3.org/TR/SVGMobile12/single-page.html#coords-ConstrainedTransformations

CM: thinking about viewBox, lack of viewBox, and how wide things are in screen pixels
... just sizing the viewport to the size of the window

DS: things that are meant to be a fixed size could be optimized, render to that size and then cached
... like buffered-rendering

CM: right, like how "position: absolute" in css means it's usually a hardware layer
... we can leave the details of the mapping and layering until next week at TPAC

stroke-related feature requests

CM: first, stroke-position, proposed by Jeremie
... we already resolved to include the feature in SVG2

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_position

CC: what's the lneght valiue?

CM: positive means outwards, negative inwards

[CL draws stroke on whiteboard]

CM: length is in user units

CC: it doesn't say what the range of the length, where is e.g 1, 0 and -1

CL: you could have a percentage which is relative to stroke-width
... or an absolute value in user units

CM: there are some image attachments on the page above, showing different scenarios

<cyril> http://lists.w3.org/Archives/Public/www-svg/2011Sep/0057.html

<heycam> http://lists.w3.org/Archives/Public/www-svg/2011Sep/0062.html

DS: i can imagine having a stroke around and then wanting a second stroke
... multiple strokes could be very useful

CM: that's possible with vector effects

DS: the figleaf example is nice
... if there was a way to fill the space beween the fill and the stroke

CC: so what is the conclusion?

DS: i'm in favor of this proposal

CM: we should put it in draft

CC: some drawing APIs don't have the capability to do this I think

CM: is it too much to ask?

DS: in the 0062.html mail, the third image seems intuitive, and the figleaf is intuitive... the first one though, how do you get that?

[CC draws on whiteboard]

<heycam> Path flattening/offsetting algorithm: http://www.google.com/url?sa=t&rct=j&q=%22fast%20precise%20flattening%20of%22&source=web&cd=1&sqi=2&ved=0CCUQFjAA&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.106.5344%26rep%3Drep1%26type%3Dpdf&ei=ZyOrTsIsiJiIApDevLML&usg=AFQjCNFc8ypX4PbNIvPWtcd-Wg7yrHWxDg&sig2=lu_5yuGGUnHREOhkSlPOgg&cad=rja

DS: do we need something like stroke-rule, similar to fill-rule?

CC: what happens with miter-limit?
... are the definitions we have capable of handling these new functionality when strokes are outside or inside?
... it's probably not so easy to define what's inside and outside

CM: we already know for a path what the stroke will be
... so to get the new stroke just offset the stroke more or less than is currently done with stroke middle
... the paper just looks at left and right sides of a stroke, for determining what parts should disappear when the stroke folds over itself

CC: let's say you want to animate the stroke-distance

[CC draws a star, with a hole in the middle]

scribe: i think it uses fill-rule=non-zero
... you don't use even-odd when you're filling the strokepath
... but we're talking about different things, the stroke isn't the fill

CM: in the end what you get from a stroking operation is a normal path that you can fill
... might be interesting to experiment with implementing
... for the syntax of the proposal, no specific suggestions for improvments?

DS: we should play with it and see how well it works

CL: paper addresses performance of this, and it's just as good as any other stroking operation

CM: are you likely to get seams if you offset from the fill?
... that is, the space between the fill and the stroke, if you have stroke-position=outside

DS: think people would like this situation to produce no seams

CC: should we also have a more general shape-offset that offsets the shape geometry by a certain amount?
... i think that's a vector effect

CM: yes, I think this might be a less common operation, so that's probably fine

CL: you do get a problem if the tesselation is dfifferent for the stroke and the fill
... some pixles may end up with less coverage and the background might bleed through

<scribe> ACTION: CM to put the stroke-position proposal into the SVG2 spec [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action06]

<trackbot> Sorry, amibiguous username (more than one match) - CM

<trackbot> Try using a different identifier, such as family name or username (eg. charles, cmccorma)

<scribe> ACTION: cameron to put the stroke-position proposal into the SVG2 spec [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action07]

<trackbot> Created ACTION-3162 - Put the stroke-position proposal into the SVG2 spec [on Cameron McCormack - due 2011-11-04].

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_dash_adjustment

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_dash_adjustment

stroke-dash adjustments

CM: i wrote this proposal to address adaptive stroke-dashing

[CM draws on whiteboard]

CM: to adjust the dashes to e.g get a dash at the start and the end of a path, and then space the rest out along the curve

CL: another case is for rectangles, where you want the corners to have dashes

CC: if you have percentages for stroke-dasharray / dashoffset maybe it would address some part of this

CL: stroke-dasharray-adjust

CM: either stretch the gaps, or stretch the dashes, or both

CC: or compress

CM: maybe what this proposes is too much control

DS: yes, DWIM or auto might be better

CC: i think having stretch and compress is enough
... so compress, take an integer number, say you have 2.5 times the dashes, it would do 3 and the compress it to fit

CL: in some cases you don't want to change the lenght of the dashes

CC: if it's closed you keep the last gap, otherwise remove it

CM: my proposal is a little bit different

[general discussion and drawing on whiteboard]

CC: so maybe it's more about keeping the last gap or not

DS: which case are you optimizing for CM?

CM: maybe we should get rid of compress, and just have stretch?

CC: both are useful, if you end in the middle of a dashpattern
... it's like a rounding

CL: whichever one has the least change

DS: people probably rather want dashes that are of equal size
... and the rect corner thing

CM: my proposal addresses that, bottom half of the page
... i'm unconfortable with having 4 options

CL: people that are pushing for this want more control

DH: as long as there's good fallback behavior

CM: you want auto to be something like round gaps

CL: you want auto to do what is done currently, otherwise it would change current behaviour

CC: are dashes fixed? if you increase length of path, you get more and more dashes and gaps, right?
... if you animate it it will blip when it does the rounding to an integer number of dashes/gaps

CM/CL: yes, that's unavoidable

CC: maybe we can start with this proposal, even if it's too much control

RESOLUTION: the proposal for stroke-dash-adjust pending modification for edge-cases (open path vs closed path, impossible compression of gaps, round vs ceil)

<scribe> ACTION: cameron to update the stroke-dash-adjust proposal to address the edge-cases mentioned in the above resolution [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action08]

<trackbot> Created ACTION-3163 - Update the stroke-dash-adjust proposal to address the edge-cases mentioned in the above resolution [on Cameron McCormack - due 2011-11-04].

<cyril> s/round vs ceil)/round vs ceil) is accepted/

<cyril> scribe: cyril

SVG Params

CL: Sairus Patel was yet another person who raised the problem that colors are baked in, and Params could be a solution

DS: I thougt about this use case before

CM: I'm curious how the params would be set
... in the font URL or on the text element

ED: it would be nice to pass it on the whole font face

CC: what's the status of the spec right now? stable ?

DS: no, there are 2 models and I can't decide which one is the best
... I don't define what happens when the types are wrong, it's not strongly typed

CM: in the first you declare the params that the document is expected and you provide fallback
... in the second, you don't provide fallback but the use of the param has to provide fallback

DS: I think the one implemented by Adobe is the one in TR, with one level of indirection

<shepazu> http://www.w3.org/TR/SVGParam/

<shepazu> http://dev.w3.org/SVG/modules/param/master/SVGParam.html

CM: I can go through the specs and give my opinion

<scribe> ACTION: heycam to review the Parameters specs and comment appropriately [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action09]

<trackbot> Created ACTION-3164 - Review the Parameters specs and comment appropriately [on Cameron McCormack - due 2011-11-04].

Catmull-Rom curves

CM: We've resolved that's a req for SVG 2
... but Chris found some conflicting pages

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Path_Enhancements

CL: we agreed to have CatmullRom Curves with a tension parameter
... but for CR curves the tension is 0
... if not 0, it's a Cardinal curve
... but no one implements that
... can we resolve CR without tension ?

DS: yes

CL: it fits better in the path syntax

RESOLUTION: We will have Catmull Rom Curves (with 0 tension) in SVG 2

CC: can you close smoothly a CR curve, without a Z ?

DS: I don't know

CL: (drawing a gradient interpolation on board)
... linear interpolation of color creates a band
... as well as using a path syntax, we could add smoothness

CC: we should add this to the Advanced Gradients Req doc

CL: in our interpolation methods for animation, we don't guarantee that there is no discontinuity in the speed

<scribe> ACTION: Cyril to edit the Advanced Gradients requirements document to include support for smooth gradients [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action10]

<trackbot> Created ACTION-3165 - Edit the Advanced Gradients requirements document to include support for smooth gradients [on Cyril Concolato - due 2011-11-04].

CL: for animation, we have ease-in and ease-out but that's it
... I'm proposing that we have a way to have smooth interpolation for animations
... in 2d, we could have a motion path
... with smooth animation

CC: the general idea of having a better interpolation, smoother, is interesting

CL: the advantage is reusing the same syntax as CR curves

JY: in the context of CSS animations, there are problems with smooth interpolation, CR curves could be a solution

RESOLUTION: SVG 2 should have smooth interpolation of animation values and gradient stuff, such as Catmull Rom curves

<scribe> ACTION: heycam to add all resolutions of the pre-TPAC F2F meeting minutes to the SVG 2 Req document [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action11]

<trackbot> Created ACTION-3166 - Add all resolutions of the pre-TPAC F2F meeting minutes to the SVG 2 Req document [on Cameron McCormack - due 2011-11-04].

DS: that could be interesting to interpolate between paths that don't have the same number of segments

CL: rather that adding nurbs into path, we could have a conversion

CC: According to Tav, we could have S-basis curves

stroke-dash-corner

CM: in the cases of dash a path with corners, like a rectangle, we want to control the dash

CC: how do you define a corner

CM: I don't think we can reuse existing dash, so I came up with a new one

http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_dash_adjustment

CL: we have to see with users of dashes how much distortion of the path is acceptable

DS: in his original proposal, the dashes start at the corner, and to have it balanced on both sides of the corner, you have to use offset
... I'm proposing that the default is when the center of the dash is on the corner
... and the offset can still be used
... I agree with Chris, we need to check with people using dashes\

CM: graphics libraries tend to not support dashes adjustment and you have to do it yourself
... this is very similar to marker start, mid and end

DS: this would work well with rounded rectangles

CL: we should put this as a starting proposal

CM: I'll put more examples on the wiki page
... and mail Andreas and CGM people

CL: and Bessetti people

<heycam> s/and Bessetti people/and Ann Bassetti/

SVG 2 Requirements

http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input

shared paths

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Shared_paths

<heycam> ScribeNick: heycam

<cyril> CM: wondering about the stroking of a shared path

<cyril> CL: the vector effect constructs the fill and the stroking is done afterwards

<cyril> ... so stroking should not happen twice

<cyril> (drawing on the board)

<cyril> CM: the issue I see is how the stroke happens on joining paths

<cyril> CL: you could use vector effect (union, intersection) to define the right stroke

<cyril> ... but the result would be a path and could not be stroke

<cyril> s/could not be stroke/could not be dashed/

DS: you may also want to dash the different edges of the countries, how do you control that?

RESOLUTION: We will have a solution to shared path segments in SVG2.

<scribe> ACTION: Chris to talk to map and CGM people about requirements for dashing and shared path edges [recorded in http://www.w3.org/2011/10/28-svg-minutes.html#action12]

<trackbot> Created ACTION-3167 - Talk to map and CGM people about requirements for dashing and shared path edges [on Chris Lilley - due 2011-11-05].

Connectors

<ed> previous resolution: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Resolutions#We.27ll_consider_the_connector_proposal

CC: We already have a resolution to consider it

DS: we will leave it open

Skeleton frames

[doug draws examples on board]

<ed> http://cs.sru.edu/~ddailey/svg/lizard2.svg

CM: how is this different from mesh transforms?

CL: it's affecting the underlying geometry

<cyril> http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Paths-LivePathEffects-PatternAlongPath.html

CM: I am still wondering how this is different from general e.g. mesh transforms
... I don't know if this is a subset of mesh transforms, which we said no on
... if this is a sufficiently subset of functionality, that is simpler enough, then maybe we can say yes to this
... but it's not clear to me that is the case

DS: I would be happy with it in a separate specification

CC: can we have a separate spec with these skeleton frames, and mesh transforms?

RESOLUTION: We will not have skeleton paths in SVG2, but we will work on it in a separate module.

Declarative drawing

DS: I have seen some really cool things done with replicate

CC: I think it's almost too powerful
... the problem I can see is that the browser will have difficulties handling the result and optimising it
... if you end up with many paths, you can do an extrusion, but there are many ways you can do an extrusion

ED: depends if you generate DOM nodes
... could be cheaper not to generate additional exposed DOM nodes

CC: the replicate proposal is just a single element AIUI

CL: it effectively makes a bunch of shadow dom elements

DS: it makes me wonder if it can be done with Web Components

s/Web Components/Component Model/

<ChrisL> http://en.wikipedia.org/wiki/Logo_%28programming_language%29

CM: I share that concern

JY: it makes it a lot easier to do something ridiculous
... like replicate a trillion times

CL: if you are adding 1000s, it would be better if it's not in the DOM

CM: there's a balance between usefulness and complexity here, and I'm not really sure it lies on the right side of that to include in SVG2

<cyril> http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicate.htm

DS: all these things on the page look really cool
... the tubefy thing interests me

CM: but I think this is the wrong solution to achieve that gradient effect

ED: the tubefy thing is what I've heard the most requests for

DS: the extruded text also interests me
... but I don't see people wanting to do this in production apps
... for 3D things they would use WebGL

CM: I love these effects, but I am worried about this not being practical enough for the complexity of a performant implementation

ED: the script library is very small

JY: have other people been using his script?

DS: that tubefy example is Israel Eisenberg redoing his gradient worm with replicate
... I think that is a good point, is anyone else doing stuff with it?

JY: if people use this script library, then it's a good hint to include the functionality, because you get the advantage of not needing DOM nodes in the native implementation

DS: two things would change my mind
... one, if we saw an uptake of people using the script library to solve the problems they have
... and two, if we saw more concrete examples of practical uses of the library
... using it to solve a problem

CC: we have browsers, and authoring tools in the group, and we haven't had any people crying out that they really want this

RESOLUTION: We will not include replicate in SVG2 unless accompanied by concrete use cases and demonstration of author/implementor interest.

DS: I would like to see a spec just to see if it can yield other solutions, to see what emerges from it

Turtle graphics

DS: there are two aspects of turtle graphics
... there's the replicating patterns, which is more ambitious
... and the other is Cameron's proposal, which does not include repetition

CM: I think we need to see some justification for extending my turtle graphics to the more general form
... since mine are grounded in particular use cases, for example animating angles between path segments, easily creating pie chart shapes, etc.
... general logo-like graphics, I'm not sure what the practical reason to include that

RESOLUTION: We will not include general turtle graphics in SVG2 without examples of practical reasons to do so.

Smooth curve through points

CM: this is just catmull-rom curves
... which we have already decided to include

RESOLUTION: We will include smooth path between points functionality in SVG2.

- DRAFT -

SVG Working Group Teleconference

28 Oct 2011

Attendees

Contents