SVG Working Group Teleconference -- 01 Jul 2009

<trackbot> Date: 01 July 2009

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

svg color

<ChrisL> 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> http://dev.w3.org/SVG/modules/color/master/SVGColor.html

[we agree to publish fpwd]

<ChrisL> 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> http://www.w3.org/TR/CSS21/grammar.html

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> 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> 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> http://www.w3.org/TR/SVGTiny12/painting.html#VisibilityControl

<ChrisL> (message re IDENT sent ... 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 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> 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 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> 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> 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 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> 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"

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

- DRAFT -

SVG Working Group Teleconference

01 Jul 2009

Attendees

Contents