Minutes, 01 July 2009 SVG WG telcon

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