- From: Cameron McCormack <cam@mcc.id.au>
- Date: Wed, 1 Jul 2009 18:44:08 +1000
- To: www-svg@w3.org
Hello www-svg.
The minutes from the 01 July 2009 SVG WG telcon are here:
http://www.w3.org/2009/07/01-svg-minutes.html
and below as text so that tracker can harvest them nom nom nom:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
01 Jul 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0247.html
See also: [3]IRC log
[3] http://www.w3.org/2009/07/01-svg-irc
Attendees
Present
Doug_Schepers, ed, heycam, anthony, jwatt, ChrisL
Regrets
Chair
Erik
Scribe
Cameron
Contents
* [4]Topics
1. [5]svg color
2. [6]ISSUE-2287 - Consider clarifying empty clipPath
behaviour
3. [7]ISSUE-2283 - Make it possible to get the bounding box of
an element in a particular coordinate system
4. [8]ISSUE-2282 - Consider adding new path syntax for points
on path
5. [9]ISSUE-2274 - Consider adding drag and drop functionality
6. [10]SVG 1.1 test suite template conversion
7. [11]RNG for 1.1
* [12]Summary of Action Items
_________________________________________________________
<trackbot> Date: 01 July 2009
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
svg color
<ChrisL> [13]http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html
[13] http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html
CL: all of the commentors are in green now, they agree with our
changes
<ChrisL>
[14]http://dev.w3.org/SVG/modules/color/master/SVGColor.html
[14] http://dev.w3.org/SVG/modules/color/master/SVGColor.html
[we agree to publish fpwd]
<ChrisL>
[15]http://dev.w3.org/SVG/modules/color/master/SVGColorPrimer.html
[15] http://dev.w3.org/SVG/modules/color/master/SVGColorPrimer.html
RESOLUTION: We will publish SVG Color as a FPWD
CM: how about the syntax for icc named colours?
CL: i don't mind restricting it to XML Name (though you can't start
with a digit there)
... same thing with IDs
... not sure what CSS has for ident, how restricted that is
... i'm happy to restrict it down
... what i put in was what erik suggested, which was anything that
didn't clash with the other syntax
<ChrisL> [16]http://www.w3.org/TR/CSS21/grammar.html
[16] http://www.w3.org/TR/CSS21/grammar.html
[17]http://www.w3.org/TR/CSS21/syndata.html
[17] http://www.w3.org/TR/CSS21/syndata.html
[-]?{nmstart}{nmchar}*
nmstart [_a-z]|{nonascii}|{escape}
nmchar [_a-z0-9-]|{nonascii}|{escape}
CL: so the same as an xml name, can't have digits at the beginning
... we should document that you can't start with a digit
... i can live with that
ED: that'll go in before publication?
CL: yes
... i'll respond to anne saying we agree
ISSUE-2287 - Consider clarifying empty clipPath behaviour
ISSUE-2287?
<trackbot> ISSUE-2287 -- Consider clarifying empty clipPath
behaviour -- RAISED
<trackbot> [18]http://www.w3.org/Graphics/SVG/WG/track/issues/2287
[18] http://www.w3.org/Graphics/SVG/WG/track/issues/2287
ED: this is an issue i can across from some test cases
... seems that implementations differ on how empty clip paths behave
... i made a ua test
... and tested the four cases i found
... i think we should consider adding this to 1.1 second edition
spec
... i can go through each of the cases
... the first to agree on is what should happen if you have an empty
clip path
... most impls agree that that would mean everything is clipped away
... not sure why batik thinks that it means nothing is clipped
CM: yes i think it should clip everything away
ED: the spec doesn't say anything about the case
... but it's logical
... if you have an empty area, you'll have nothing left
... we could consider adding a note there
... second case is similar to the first, when you have children that
have display:none set
... third is visibility:hidden
... those are interpreted differently in safari
... where visibility:hidden objects contribute to the clipping path
... which i think is a bit strange
CM: does the spec say anything about display:none?
... i thought all objects contribute to the clip path regardless of
display/visibility
<ed>
[19]http://www.w3.org/TR/SVG11/masking.html#EstablishingANewClipping
Path
[19] http://www.w3.org/TR/SVG11/masking.html#EstablishingANewClippingPath
ED: i think it's just talking about the <clipPath> element itself
"The 'display' property does not apply to the 'clipPath' element;
thus, 'clipPath' elements are not directly rendered even if the
'display' property is set to a value other than none, and 'clipPath'
elements are available for referencing even when the 'display'
property on the 'clipPath' element or any of its ancestors is set to
none."
ED: but it doesn't talk about children of the clipPath
... and sometimes it's useful to remove elements from the clipPath
easily with display:none
"The raw geometry of each child element exclusive of rendering
properties such as 'fill', 'stroke', 'stroke-width' within a
'clipPath' conceptually defines a 1-bit mask..."
ED: depends what rendering properties includes
AG: does 1.2T say something about this?
CM: tiny doesn't have clipping
AG: but i think we had some wording in there that relates to this
ED: there's a definition for rendering tree, but that's the closest
i could find
CM: perhaps "rendering tree" is what we could reference
... if it's in 1.1
... what's your suggestion on which ones contribute to clipping
paths?
ED: i'd prefer the more graphical sense of it
... it's intuitive to me that the things that show up and render (if
not in a clipPath) would contribute
... and if you hide them in any way they wouldn't
AG: so visibility would affect it?
ED: i think visibility:hidden should contribute to the clip path
... but we could try to list all of the rendering properties
... if fill/stroke/stroke-width are not the only ones
CL: tends to trip us up if we list them all, harder to add new ones
in other specs
CM: i would think intuitively that visibility:hidden wouldn't make a
difference
... but that display:none would prevent contribution to the clip
path
JW: i think visibility:hidden shouldn't contribute
... the only place i can think of it being useful is if you're
referencing geometry that is the thing you're clipping
... trying to think of scenarios where it matters
DS: from the perspective of authoring, what's the most intuitive
behaviour? what happens if for some reason that thing is not there.
... i think it would be easier to debug if it would be ignored
ED: when i debug clippath i find it easier to remove the clippath
element and to draw it, to visualise how it gets applied
... so in that sense i think it's easier to understand what it does
if it's the same as the rendering
... so visibility:hidden wouldn't contribute to the clippath
JW: the only time it would matter is if you're clipping something
that's visually on the screen
... otherwise the author could use display:none
... maybe using visibility:hidden for some reason in referenced
geometry
CM: ah so if you're referencing clippath geometry that has some
visibility:hidden stuff already
AG: i'm leaning towards erik's side
<anthony>
[20]http://www.w3.org/TR/SVGTiny12/painting.html#VisibilityControl
[20] http://www.w3.org/TR/SVGTiny12/painting.html#VisibilityControl
<ChrisL> (message re IDENT sent ...
[21]http://lists.w3.org/Archives/Public/www-svg/2009Jul/0000.html )
[21] http://lists.w3.org/Archives/Public/www-svg/2009Jul/0000.html
ED: i think the first one we can conclude that empty clippaths mean
everything is clipped away
... we can also agree that any children with display:none do not
contribute to the clipping path
... and we're not concluded on visibility:hidden
AG: is it pain for implementations?
ED: just an if statement, not a huge deal
JW: all implementations other than safari do that?
ED: safari lets visibility:hidden contribute to the clipping path,
batik too
... opera and firefox don't
JW: i'm struggling to think of a use case either way, and preventing
visibility:hidden from contributing seems intuitive to me
ED: ok we'll go with that
... the last case is clip-path="url(#brokenlink)"
... would that mean everything is clipped or nothing is clipped?
... batik thinks a broken link there is an error, while the others
don't agree
AG: IMO nothing should be clipped
ED: don't know what's meant to happen for other CSS properties with
invalid urls in SVG 1.1
... such as fill="url(#bad)"
AG: i think it's intuitive that it doens't clip
... if it doesn't work, then it's obvious if everything renders
ED: for fill you would use the initial value
JW: as if it weren't specified
ED: so for clip-path that would be none
... so no clipping
CM: i agree
<scribe> ACTION: Erik to add these decisions to the 1.1SE spec, and
make the clippath example into a test case [recorded in
[22]http://www.w3.org/2009/07/01-svg-minutes.html#action01]
<trackbot> Created ACTION-2628 - Add these decisions to the 1.1SE
spec, and make the clippath example into a test case [on Erik
Dahlström - due 2009-07-08].
ISSUE-2283 - Make it possible to get the bounding box of an element in
a particular coordinate system
ISSUE-2283?
<trackbot> ISSUE-2283 -- Make it possible to get the bounding box of
an element in a particular coordinate system -- RAISED
<trackbot> [23]http://www.w3.org/Graphics/SVG/WG/track/issues/2283
[23] http://www.w3.org/Graphics/SVG/WG/track/issues/2283
CM: [essentially reads out the issue]
ED: suggestion on how to do this?
CM: three ways
... have SVGRect be transformable
... extend getBBox() with an argument
... or introduce a new getBBoxInAnotherElementsCoordSystem(elt)
ED: people have asked for transformable SVGRect before
CM: transforming an SVGRect might give you a quadrangle
... so the return type couldn't be another SVGRect
ED: you could return a rectangle but it wouldn't be the transformed
rectangle
CL: you could return a path
JW: the first option, having SVGRect be transformable, i was
dismissing out of hand
... you've no longer got tight bounds, if you want to still return a
SVGRect
... for getBBox() i was hoping to pass in an argument for the
different type of bounds (including fill, stroke, clipping)
... so i didn't want to pass in an Element argument to that
... i was thinking of something like the third option, but more like
otherElement.getBBoxOf(firstElement)
... that allows getBBoxOf() to have the type-of-bounds argument
CM: getBBoxOf() seems like the simplest solution
<scribe> ACTION: Cameron to add a proposal for getBBoxOf() to the
proposals directory [recorded in
[24]http://www.w3.org/2009/07/01-svg-minutes.html#action02]
<trackbot> Created ACTION-2629 - Add a proposal for getBBoxOf() to
the proposals directory [on Cameron McCormack - due 2009-07-08].
ISSUE-2282 - Consider adding new path syntax for points on path
ISSUE-2282?
<trackbot> ISSUE-2282 -- Consider adding new path syntax for points
on path -- RAISED
<trackbot> [25]http://www.w3.org/Graphics/SVG/WG/track/issues/2282
[25] http://www.w3.org/Graphics/SVG/WG/track/issues/2282
ED: this is about new path syntax/interpolation
CL: patrick gave us a bunch of math, but not sure that's good to go
with
... not sure it's helps us concretely enough
DS: yep
CL: otoh he does have some java code that implements it
AG: there is quite a bit to specify for it
... for example, when you have a bend in the curve where abouts in
the curve does it go through the point
... or if you're trying to fit paths to points it can be tricky
CL: normally with this kind of thing you can allow an amount of
error, because it's not always possible get a solution
... which might be ok for a new element, but to add into existing
path syntax it's hard to add parameters
... if you want to say "go through these points within 0.1 units"
it's hard to pass that in with the current path syntax
ED: anyone interested in looking at this? do we need to try to
contact someone to make something from this?
DS: i think it's potentially interesting, but i don't have the math
to make it interesting enough to myself
CL: too much conceptual gap between his math and what we need
... otoh i think he's quite interested in this
... so in general if you've got n points, what's the algorithm to
produce the path?
... does it decompose into other curve segments?
... need to get patrick to explain what's entailed there
DS: if i could see the java implementation, that would give me a
better sense
... want to see two things: one, what such curves look like
visually, and two what the syntax might be
... so i'd like to see a bunch of points have a path go through it
in a predictable way
... maybe the syntax would just be like a <polyline>, but i don't
know that
CL: for a basic shape that's easy, we could have another attribute
that says accuracy="whatever" with a default of 0, e.g.
... and other constraints, how tight the "cord" is pulled
... you could imagine floppy shapes and mostly straight line curves
... exactly the kind of thing the java testing app would help us see
DS: another aspect is that i don't know how it deals with shapes
where the line crosses itself several times
... don't know if that would lead to funky behaviour
<ed>
[26]http://www-personal.umich.edu/~pion/WebGeom/sketch-test5.html
[26] http://www-personal.umich.edu/~pion/WebGeom/sketch-test5.html
ED: that app isn't showing any nice curves
DS: curves would be more interesting
... for a graph where you want to plot the points, for example
CL: if the java applet doesn't do it, but he thinks it's simple, we
could ask him to do it
AG: this applet looks like the constraint stuff we were talking
about, applying constraints to the movement
... and you get some sort of mechanical effect
<scribe> ACTION: Chris to contact Patrick Ion for an applet that
demonstrates these curves [recorded in
[27]http://www.w3.org/2009/07/01-svg-minutes.html#action03]
<trackbot> Created ACTION-2630 - Contact Patrick Ion for an applet
that demonstrates these curves [on Chris Lilley - due 2009-07-08].
AG: you could do some cool stuff with constraints on these curves
ISSUE-2274 - Consider adding drag and drop functionality
ISSUE-2274?
<trackbot> ISSUE-2274 -- Consider adding drag and drop functionality
-- RAISED
<trackbot> [28]http://www.w3.org/Graphics/SVG/WG/track/issues/2274
[28] http://www.w3.org/Graphics/SVG/WG/track/issues/2274
ED: don't know if there's anything to discuss, but there should be
an action to research what would be needed from svg
... this might be related to webapps work
DS: drag and drop has been added to html5
... but not exactly in the way we'd want in svg
... in html5 it's like a special kind of clipboard
... so a copy/paste thing
... i'm thinking that the OP means (and i mean) is being able to
drag and drop a shape around the screen
... moving it around
... two ways of doing it
... either have drag and drop attributes, e.g.
... or a constraints mechanism where they could say what to do with
it
... pointer.x-5 and pointer.y-10
... enable people to do things based on the pointer position, not
using script
... activation through smil
... so i think this is SVG specific
CL: if it's going to interact with smil, you'd want it to raise
events so you can say onblah
DS: we could create drag and drop events
... that it would dispatch when it did that
... we could have it triggered on regular events mousedown,
mousemove etc.
... if we did that, what we would need to do is also define how it
works with a keyboard
... or some alternate pointer device
... so the more semantic thing would be grab/drag/drop
... however that's actuated
... making it accessible isn't particularly easy, i think
JW: allowing drag&drop without script?
CL: yes
... though i worry that it might get in the way of other things
trying to affect the position
DS: that could argue for real grab/drag/drop events
CL: if you provide hooks then people can write script to make use of
them as needed
... but if it's automatic, then it might get in the way of other
things like link activation
JW: that would be an issue, that it would need to set attributes x/y
or whatever
... especially when we're just introducing calc() or more complex
positioning, layout, it's going to become painful to define what
happens when you have percentage plus pointer.x pixels
<ed> <animate begin="rect.mousedown" end="dropzone.mouseup" ...> is
possible already
<shepazu> attributeName="cx" attributeValue="pointer.x+5"
<animateTransformToPointer offsetX="..." offsetY="..."
begin="rect.mousedown" end="rect.mouseup"/>
CM: if it's a smil mechanism, it might make it easier to avoid
competing things affecting the position of an object
ED: sometimes you want the object to stay at its end point,
sometimes to return
DS: you could use fill="freeze" for that
... so this wouldn't solve all cases
... but for the cases where people want something really strange, i
think that they could code something up
... would this cover say 50-70% of cases where people want to do
dnd?
... my guess is yes
ED: i don't know, all the cases i've seen you need to do some
scripting or trigger server side actions
... depends on the use case
DS: what use cases?
ED: e.g. sorting some objects in some way and then storing it
... putting orders in a basket in a web shop
JW: svg solitaire
DS: in my mind, if you just had svg solitaire or putting items in a
basket, both of those cases aren't asking for anything much special
... just moving the cards or the items
JW: you want to be able to drop near the cards
DS: wouldn't say you wouldn't have to script the drag code
ED: but i think you'd want to have script callbacks for dnd
DS: you have those already for smil
ED: you have the mouse events but don't know that it's drag/drop
DS: could change that
... in the past bjoern wanted to be able to use arbitrary events in
smil begin/end
... i think for 50-70% of the cases, dragging to move it around and
then hooking that into script would handle it
... hard to think of anything funkier with dragging
... another case is if we wanted to allow people to have connectors
and move nodes/edges around
... and have the connectors follow the shape, then we should try to
solve that problem at the same time
... and it would be solved, if we had a way of saying "this line
connects between these two shapes"
... then you would be able to drag things around and have the
connectors follow
... i do think that even though it gets a little specialised, having
that kind of functionality built in to svg solves a large number of
use cases
... and it would make the language a lot more attractive to use
ED: have you looked at the html5 dnd?
DS: no but i should
ED: i think that's also something that's in silverlight
... same type of specialised dnd events
... might be good to study those cases
DS: not sure we're in a position yet to do anything about it
... i'm interested in this but there's so much other stuff to do
... i think we should come back to this
JW: i think it's a fair bit of work to work out the events, how
attributes get modified, etc.
... and since it's 10-20 lines to implement dnd in script, maybe we
should be prioritising other things
DS: one way to make it easier would be the "get the real point"
stuff we talked about
... get the x/y position i care about, with transformations/ctm
taken care of
CL: that's more the kind of thing i was talking about. adding hooks
to make it more easily implemented.
DS: that stuff we'd need to resolve anyway if we were to do this
... since that's the behaviour people would want
... the "absolute" value of the mouse pointer
... so let's solve that part first
SVG 1.1 test suite template conversion
AG: pretty much all the tests are converted
... i'm just going through and verifying that they're all good
... just 30-odd tests left to check
... then i'll commit them all as a batch
... 335 tests all done
... should be done by the end of this week
CM: sounds good
AG: made some minor fixes to the xslt, it's working properly now
... we can use this and the new template for the svg core tests when
the spec is on its way
... and for modules
ED: if we make tests for modules we should use the 1.1F2 template?
AG: or some variant?
... the template we use now for those tests might be ported across
to modules etc.
... so it'd be good to decide
... the one we're using the 1.1F2 is very close to the 1.2T one
... apart from a couple of extra fields
CL: it's using id instead of xml:id presumably?
AG: yes
CM: nothing specific to 1.1 that would prevent us from using that
template for modules etc. would it?
AG: no, it's usable for all modules
... the TestCase element, the bit that has all the metadata for the
test, that bit is using xlink:href to reference into the spec
... that's the only odd thing it's doing
... otherwise it's the same as the tiny template
CM: i don't know if it's useful to have xlink:href attribute named
like that
AG: it's on the TestComponent element
... so when we generate the harness it can generate an <a>
CL: if it's being transformed anyway it doesn't matter what it's
called
<scribe> ACTION: Anthony to draft the template for SVG 2.0 and
modules and present it at the next telcon [recorded in
[29]http://www.w3.org/2009/07/01-svg-minutes.html#action04]
<trackbot> Created ACTION-2631 - Draft the template for SVG 2.0 and
modules and present it at the next telcon [on Anthony Grasso - due
2009-07-08].
RNG for 1.1
DS: berjon is willing to help us out and give us guidance
... but not to do the whole thing
... he's pretty busy with other stuff too
... he can't join as vodafone rep
... he sent me a fairly detailed email and i'll ask if i can forward
it on to us
Summary of Action Items
[NEW] ACTION: Anthony to draft the template for SVG 2.0 and modules
and present it at the next telcon [recorded in
[30]http://www.w3.org/2009/07/01-svg-minutes.html#action04]
[NEW] ACTION: Cameron to add a proposal for getBBoxOf() to the
proposals directory [recorded in
[31]http://www.w3.org/2009/07/01-svg-minutes.html#action02]
[NEW] ACTION: Chris to contact Patrick Ion for an applet that
demonstrates these curves [recorded in
[32]http://www.w3.org/2009/07/01-svg-minutes.html#action03]
[NEW] ACTION: Erik to add these decisions to the 1.1SE spec, and
make the clippath example into a test case [recorded in
[33]http://www.w3.org/2009/07/01-svg-minutes.html#action01]
[End of minutes]
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Wednesday, 1 July 2009 08:44:59 UTC