See also: IRC log
<trackbot> Date: 01 July 2009
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
<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?
<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?
<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?
<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?
<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"
<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
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].
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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/chnages/changes/ Succeeded: s/cipping/clipping/ Succeeded: s/getBBox/getBBoxOf/ Succeeded: s/is like/it's like/ Succeeded: s/anyhting/anything/ Succeeded: s/you need to/you want to be able to/ Found Scribe: Cameron Found ScribeNick: heycam Default Present: Doug_Schepers, ed, heycam, anthony, jwatt, [IPcaller] Present: Doug_Schepers ed heycam anthony jwatt ChrisL Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0247.html Found Date: 01 Jul 2009 Guessing minutes URL: http://www.w3.org/2009/07/01-svg-minutes.html People with action items: anthony cameron chris erik[End of scribe.perl diagnostic output]