- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 28 Oct 2011 18:05:42 -0700
- To: www-svg <www-svg@w3.org>
Minutes here:
http://www.w3.org/2011/10/28-svg-minutes.html
and below as text:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
28 Oct 2011
[2]Agenda
[2] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda
See also: [3]IRC log
[3] http://www.w3.org/2011/10/28-svg-irc
Attendees
Present
Chris, Erik, Daniel_Holbert, Jen, Jun, Takagi-san, Cyril,
Vincent, Cameron
Regrets
Chair
Erik, Cam
Scribe
cyril
Contents
* [4]Topics
1. [5]SVG2 Requirements Input
2. [6]Custom data attributes
3. [7]randomisation
4. [8]Consider adding certain HTML attributes used in
microformats
5. [9]Consider relaxing case sensitivity of presentation
attribute values
6. [10]Fluorescent colours/extended colour specifiers
7. [11]non-scaling stroke
8. [12]non-scaling rounded rect corners
9. [13]variable stroke-width
10. [14]perpendicular stroke
11. [15]define behavior of stroke-dasharray
12. [16]adaptive stroking
13. [17]hatch fills
14. [18]arbitrary fill
15. [19]SVG using webgl filters
16. [20]consider adding an href to style element to link to
external stylesheets
17. [21]add HTML5 style-element attributes to SVG's style
element
18. [22]alternative transforms
19. [23]other 2.5D effects
20. [24]Support getting bounding boxes that include stroke
and/or markers
21. [25]Consider allowing rotations to be relative to their
bounding box center
22. [26]vector effects
23. [27]stroke-related feature requests
24. [28]stroke-dash adjustments
25. [29]SVG Params
26. [30]Catmull-Rom curves
27. [31]stroke-dash-corner
28. [32]SVG 2 Requirements
29. [33]shared paths
30. [34]Connectors
31. [35]Skeleton frames
32. [36]Declarative drawing
33. [37]Turtle graphics
34. [38]Smooth curve through points
* [39]Summary of Action Items
_________________________________________________________
<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>
[40]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#L
evel_of_detail_control
[40]
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>
[41]http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/#Visibilit
yControllingAccordingToZooming
[41]
http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/#VisibilityControllingAccordingToZooming
<heycam> RESOLUTION: We will support Level of Detail control in
SVG2.
<ed>
[42]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#T
emplating_for_controls.2Fwidgets
[42]
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>
[43]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#C
onsider_adding_transform.3D.22.22_to_.3Csvg.3E
[43]
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>
[44]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A
dd_.40allowReorder_to_.3Cswitch.3E_for_improved_language-based_switc
hing
[44]
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>
[45]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A
llow_referencing_root_external_files_with_.3Cuse.3E
[45]
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
[46]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>
[47]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#P
arameters
[47]
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,
[48]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/
[48] 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>
[49]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#C
ustom_data-.2A_attributes
[49]
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>
[50]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#C
onsider_adding_certain_HTML_attributes_used_in_microformats
[50]
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> [51]http://www.w3.org/Graphics/SVG/WG/track/issues/2048
[51] 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
[52]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>
[53]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#C
onsider_relaxing_case_sensitivity_of_presentation_attribute_values
[53]
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>
[54]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#F
luorescent_colours.2Fextended_colour_specifiers
[54]
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>
[55]http://dev.w3.org/SVG/modules/color/publish/SVGColor.html
[55] 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
[56]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].
[57]http://dev.w3.org/SVG/modules/color/master/SVGColor.html
[57] 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
[58]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>
[59]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#N
on-scaling_stroke
[59]
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>
[60]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#N
on-scaling_rounded_rect_corners
[60]
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
[61]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>
[62]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#V
ariable_stroke_width
[62]
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>
[63]http://tavmjong.free.fr/SVG/SVGOpen2011/INKSCAPE/svg_2011_inksca
pe.svg
[63]
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>
[64]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#P
erpendicular_stroke
[64]
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>
[65]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#S
troke_position
[65]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Stroke_position
define behavior of stroke-dasharray
<heycam>
[66]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#D
efine_behaviour_of_stroke-dasharray
[66]
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>
[67]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A
daptive_stroking
[67]
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>
[68]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#H
atch_fills
[68]
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> [69]http://en.wikipedia.org/wiki/Hatching
[69] 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> [70]http://fr.wikipedia.org/wiki/Hachure has more detail
actually
[70] http://fr.wikipedia.org/wiki/Hachure
arbitrary fill
<heycam>
[71]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A
rbitrary_fill
[71]
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>
[72]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#S
VG_using_WebGL_filters
[72]
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>
[73]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#C
onsider_adding_an_href_to_the_style_element_to_link_to_external_styl
esheets
[73]
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>
[74]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A
dd_HTML5_style-element_attributes_to_SVG.27s_style_element
[74]
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>
[75]http://www.whatwg.org/specs/web-apps/current-work/multipage/sema
ntics.html#the-style-element
[75]
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-style-element
<ChrisL>
[76]http://www.w3.org/TR/html5/semantics.html#the-style-element
[76] 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>
[77]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A
lternative_transforms
[77]
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> [78]http://blockses.appspot.com/1246403
[78] 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>
[79]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#O
ther_2.5D_effects
[79]
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>
[80]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#S
upport_getting_bounding_boxes_that_include_stroke_and.2For_markers
[80]
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>
[81]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#C
onsider_allowing_rotations_to_be_relative_to_their_bounding_box_cent
er
[81]
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>
[82]http://www.w3.org/TR/SVGMobile12/single-page.html#coords-Constra
inedTransformations
[82]
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>
[83]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_position
[83] 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>
[84]http://lists.w3.org/Archives/Public/www-svg/2011Sep/0057.html
[84] http://lists.w3.org/Archives/Public/www-svg/2011Sep/0057.html
<heycam>
[85]http://lists.w3.org/Archives/Public/www-svg/2011Sep/0062.html
[85] 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:
[86]http://www.google.com/url?sa=t&rct=j&q=%22fast%20precise%20flatt
ening%20of%22&source=web&cd=1&sqi=2&ved=0CCUQFjAA&url=http%3A%2F%2Fc
iteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.106.5344%26
rep%3Drep1%26type%3Dpdf&ei=ZyOrTsIsiJiIApDevLML&usg=AFQjCNFc8ypX4PbN
IvPWtcd-Wg7yrHWxDg&sig2=lu_5yuGGUnHREOhkSlPOgg&cad=rja
[86]
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
[87]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
[88]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>
[89]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_dash_adj
ustment
[89]
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_dash_adjustment
<heycam>
[90]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_dash_adj
ustment
[90]
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
[91]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> [92]http://www.w3.org/TR/SVGParam/
[92] http://www.w3.org/TR/SVGParam/
<shepazu>
[93]http://dev.w3.org/SVG/modules/param/master/SVGParam.html
[93] 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
[94]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>
[95]http://www.w3.org/Graphics/SVG/WG/wiki/Path_Enhancements
[95] 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
[96]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
[97]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
[98]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_dash_adj
ustment
[98]
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
[99]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input
[99] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input
shared paths
<heycam>
[100]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#
Shared_paths
[100]
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
[101]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:
[102]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Resolutions#We.27ll
_consider_the_connector_proposal
[102]
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> [103]http://cs.sru.edu/~ddailey/svg/lizard2.svg
[103] http://cs.sru.edu/~ddailey/svg/lizard2.svg
CM: how is this different from mesh transforms?
CL: it's affecting the underlying geometry
<cyril>
[104]http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Paths-LivePathEffe
cts-PatternAlongPath.html
[104]
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
<ChrisL> <script type ="text/logo" />
s/Web Components/Component Model/
<ChrisL>
[105]http://en.wikipedia.org/wiki/Logo_%28programming_language%29
[105] 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>
[106]http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicat
e.htm
[106]
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.
Summary of Action Items
[NEW] ACTION: cameron to put the stroke-position proposal into the
SVG2 spec [recorded in
[107]http://www.w3.org/2011/10/28-svg-minutes.html#action07]
[NEW] ACTION: cameron to update the stroke-dash-adjust proposal to
address the edge-cases mentioned in the above resolution [recorded
in [108]http://www.w3.org/2011/10/28-svg-minutes.html#action08]
[NEW] ACTION: chris to reply to alex explaining how wide gamut
colours and flourewscent/metallic printing are accomodated in SVG
color [recorded in
[109]http://www.w3.org/2011/10/28-svg-minutes.html#action03]
[NEW] ACTION: Chris to talk to map and CGM people about requirements
for dashing and shared path edges [recorded in
[110]http://www.w3.org/2011/10/28-svg-minutes.html#action12]
[NEW] ACTION: ChrisL to edit the svg colormanagemtn spec into a
chapter in SVG2 [recorded in
[111]http://www.w3.org/2011/10/28-svg-minutes.html#action04]
[NEW] ACTION: ChrisL to look at global attributes [recorded in
[112]http://www.w3.org/2011/10/28-svg-minutes.html#action02]
[NEW] ACTION: CM to put the stroke-position proposal into the SVG2
spec [recorded in
[113]http://www.w3.org/2011/10/28-svg-minutes.html#action06]
[NEW] ACTION: Cyril to edit the Advanced Gradients requirements
document to include support for smooth gradients [recorded in
[114]http://www.w3.org/2011/10/28-svg-minutes.html#action10]
[NEW] 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
[115]http://www.w3.org/2011/10/28-svg-minutes.html#action01]
[NEW] ACTION: heycam to add all resolutions of the pre-TPAC F2F
meeting minutes to the SVG 2 Req document [recorded in
[116]http://www.w3.org/2011/10/28-svg-minutes.html#action11]
[NEW] ACTION: heycam to review the Parameters specs and comment
appropriately [recorded in
[117]http://www.w3.org/2011/10/28-svg-minutes.html#action09]
[NEW] ACTION: tav to write up summary of inkscape's non-scaling
features, as possible candidates for svg2 [recorded in
[118]http://www.w3.org/2011/10/28-svg-minutes.html#action05]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [119]scribe.perl version 1.136
([120]CVS log)
$Date: 2011/10/29 01:04:09 $
_________________________________________________________
[119] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[120] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43
Check for newer version at [121]http://dev.w3.org/cvsweb/~checkout~/200
2/scribe/
[121] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/CC/CM/
Succeeded: s/heycam/CM/
Succeeded: s/heycam/CM/
Succeeded: s/transforming a curve/transforming a straight line/
FAILED: s/round vs ceil)/round vs ceil) is accepted/
FAILED: s/and Bessetti people/and Ann Bassetti/
FAILED: s/could not be stroke/could not be dashed/
FAILED: s/Web Components/Component Model/
Succeeded: s/that/the performance concern/
Found ScribeNick: ChrisL
Found ScribeNick: dholbert
Found ScribeNick: ed
Found Scribe: cyril
Inferring ScribeNick: cyril
Found ScribeNick: heycam
ScribeNicks: ChrisL, dholbert, ed, cyril, heycam
WARNING: Replacing list of attendees.
Old list: +1.650.693.aaaa [IPcaller] AD
New list: Doug_Schepers +1.650.693.aaaa
WARNING: Replacing list of attendees.
Old list: Doug_Schepers +1.650.693.aaaa
New list: +1.650.693.aaaa tbah
WARNING: Replacing list of attendees.
Old list: +1.650.693.aaaa tbah
New list: tbah
Default Present: tbah
Present: Chris Erik Daniel_Holbert Jen Jun Takagi-san Cyril Vincent Cam
eron
Agenda: [122]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agend
a
Found Date: 28 Oct 2011
Guessing minutes URL: [123]http://www.w3.org/2011/10/28-svg-minutes.htm
l
People with action items: cameron chris chrisl cm cyril heycam tav
[122] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda
[123] http://www.w3.org/2011/10/28-svg-minutes.html
End of [124]scribe.perl diagnostic output]
[124] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Saturday, 29 October 2011 01:06:35 UTC