- From: Cameron McCormack <cam@mcc.id.au>
- Date: Sat, 13 Jun 2009 10:40:07 +1000
- To: public-svg-wg@w3.org
http://www.w3.org/2009/06/12-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
12 Jun 2009
See also: [2]IRC log
[2] http://www.w3.org/2009/06/12-svg-irc
Attendees
Present
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Cameron
Contents
* [3]Topics
1. [4]Layout
2. [5]Simple keywords
3. [6]ISSUE-2042 - Consider adding adding non-NS linking
syntax
4. [7]xlink:href
5. [8]New DOM syntax
6. [9]Test suite
7. [10]Mailing minutes to www-svg
* [11]Summary of Action Items
_________________________________________________________
<trackbot> Date: 12 June 2009
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
Layout
CM: flex box is progressing in css, what about other layout?
CL: there's multi column
... might be dropped in implementations
... there's grid, which is mainly used for asian typography
CM: not intended for big boxes of content in the grid?
CL: no
CM: template too
[12]http://www.w3.org/TR/2009/WD-css3-layout-20090402/
[12] http://www.w3.org/TR/2009/WD-css3-layout-20090402/
DS: xsl wants areas that text flows in to, and areas that grow to
fit the text
... we should make sure that whatever we do for text shape should
work for those
... need to gather use cases & reqs for text flow shapes
CM: a good way forward might be for someone to look at the flex
layout and see how applicable it is to svg
CL: as for the text flow problem, our flowText from the 1.2 draft is
pretty different from what xsl needs
ED: i'm more interested in the graphical content layout problem
DS: i'm still interested in the one way constraints stuff
<shepazu> DS: part of flexbox, as I understand it, is essentially
the springs-and-struts model
CM: i feel like high level layout (like flex boxes) plus one way for
relative positioning might be a good balance
... the springs can't cross boxes, with flex boxes
DS: if i have a rectangle and i want it to be a particular size,
relative to other things around it, with a min height/width, seems
like you could do that with the constraints
CM: one way constraints are less useful than i'd thought a while ago
DS: for some things i still want to use calc(bbox(some object) + 5)
kind of functionality
... it's possible people would misuse the simple stuff and try to
make things that are too complex
CM: also seems bad to require complex implementations to solve
simple use cases
CL: for text flow, we limited our 1.2 draft solution to just simple
paragraphs
... to avoid arbitrarily complex xsl-like formatting within svg
... want the sweet spot where small amount of functionality gets you
lots of use
DS: two problems with canned layout solutions
... one, they each only solve a particular problem
... if there's no underlying model, then it becomes harder to define
and to understand how they work together
CM: swing has a unifying model of rectangular components with
min/preferred/max width and height
CL: systems can work together fairly easily if you limit them to not
work together
... if they're mutually exclusive
DS: things tend to break down to specific syntax for those
solutions, then
... so we need an underlying model to make them work together
... and so that people can understand how they work together
CM: i think people will want to use multiple high level layouts
together
DS: maybe some you can combine some you can't?
... one thing that would be an easy win:
[doug talks about the "chain font" example]
scribe: so let's just allow shapes flowing along a path
... i think what goes along with that is navigation
... an implicit ordering
CM: so like implicitly determining the nav-* properties
DS: so for this pretty much textPath, but shapePath
ED: i've had cases where i wanted to place images along a path, it's
pretty difficult
CL: the trivial case where someone wants the layout and gives a
straight line path
DS: how do these shapes become anchored?
JW: two things tied into this shapes on a path
... i'd like percentages on a path
ED: another way of doing it is markers, but they're not easy to use
JW: also you might want minimum distances
... also, places objects on vertices
... like putting objects on each point of a star
DS: so reusing textpath for shapes, many of these things we're
thinking of for shapepath could be used in textpath too
... so laying out glyphs and shapes are similar
CL: <shapepath>A b c <rect> <circle> d e f</shapepath>
DS: i've been thinking about how to do connectors, how to connect
things to arbitrary points on a shap
... often you want limited connection points
... e.g. for circles, top bottom right and left
... if it's a star, only on the points
... so i want to identify those points through some syntax, or have
as a child of that shape, a bunch of <point> elements with their
actual positions
... those <point>s could be constrained to be at particular points
on the shape
... each could have an id, and you could say that one is the anchor
point
... or you might have anchor-x, anchor-y on a shape
CM: it's like setting the baseline for your shape
... if the <point>s are going to be used for other things, like
connectors, then would make sense to reuse them
... otherwise, just use the anchor- attributes
[doug draws]
CL: can we do text on a path where each glyph has a constant
rotation
JW: there's marker orientation
CM: i want automatically <use>d things along a path
<ed> there's no way to disable the rotation on textpath though, no
@orient attribute
CM: to fill up the path
... to do train line like paths
DS: you could have a stroke-dasharray type of mechanism to specify
those repeated things
... you could specify like background-repeat
ED: it's also like gradient spread method... reflect, pad, repeat,
...
DS: currently text has an interesting property where later glyphs
are drawn on top of earlier glyphs
... perhaps we want to allow painting glyphs in reverse order
... or maybe an arbitrary order
... painting order
... maybe you want to allow specifying multiple shape repeat
patterns that get drawn over each other
<scribe> ACTION: doug to write up a shape path proposal [recorded in
[13]http://www.w3.org/2009/06/12-svg-minutes.html#action01]
<trackbot> Created ACTION-2616 - Write up a shape path proposal [on
Doug Schepers - due 2009-06-19].
<shepazu> should also think about potential join points, might apply
to fonts, depends on how complex it did it
<shepazu> ... for patterns
DS: there's a problem with tspan and the semantics of a word
... would be useful to define that tspan does not affect the
underlying semantics of the text, it's just the positioning
... you can have multiple tspans that comprise a single word
... only a space in english defines a separate word
ED: we should define how collapsed whitespace is assigned to
particular text elements
CL: <text font-size='50'>a[space]<tspan
font-size='10'>[space]</tspan></text> -- how big is the single
collapsed space?
<jwatt> JW: I'd say the smaller of the two
<ed> raised ISSUE-2280
CL: you can consider the shape-flowing-to-variable-width-path as a
displacement map problem
... the path defines a complex gradient
... which you use as the displacement map
<scribe> ACTION: cameron to play with css flex box to see how
applicable it could be to svg [recorded in
[14]http://www.w3.org/2009/06/12-svg-minutes.html#action02]
<trackbot> Created ACTION-2617 - Play with css flex box to see how
applicable it could be to svg [on Cameron McCormack - due
2009-06-19].
Simple keywords
CM: i was thinking about vector-effect='strokeBelowFill'
ED: or filter='drop-shadow'
<scribe> ACTION: chris to add a strokeBelowFill canned vector effect
[recorded in
[15]http://www.w3.org/2009/06/12-svg-minutes.html#action03]
<trackbot> Created ACTION-2618 - Add a strokeBelowFill canned vector
effect [on Chris Lilley - due 2009-06-19].
DS: i want to make sure that large stroke on text, where the stroke
is behind the fill, works. where the stroke around the individual
glyphs doesn't overlap.
CL: yes that's possible with vector effects
<shepazu> [16]http://chapelhillcomics.com/sample/TOP-LOGO.jpg
[16] http://chapelhillcomics.com/sample/TOP-LOGO.jpg
<ed> (discussion on vector-effects)
ISSUE-2042 - Consider adding adding non-NS linking syntax
xlink:href
ISSUE-2042?
<trackbot> ISSUE-2042 -- Consider adding adding non-NS linking
syntax -- RAISED
<trackbot> [17]http://www.w3.org/Graphics/SVG/WG/track/issues/2042
[17] http://www.w3.org/Graphics/SVG/WG/track/issues/2042
CL: at one point i suggested combining the thing that holds the IRI
and the thing that holds the type into one attribute
... so <image> would have src, and <a> would have href
... and have a generic category for other
DS: so define it in terms of xlink
CL: we'd define the mapping to xlink for the subset of xlink that we
use
... xlink would have had a network effect if a bunch of specs used
it, but they didn't
... what xlink was going to be changed mid-design
[explains what xlink was meant to be and what it ended up as]
scribe: so xlink:type="" doesn't tell you what to do (refer, embed);
instead it's just a hint to the xlink processor
... so xlink gives you some generality, but not full generality
... it has enough generality to get in the way, though
... the promise of serving domain specific xml has been lost
DS: for backwards compat and existing UAs we've still held on to
xlink:href
CL: you could come up with new attributes and deprecate xlink:href
... UAs need to support both, new content targetting new browsers
can just use the new attrs, content supporting both needs both, etc.
... i propose svg 2 prefer a new xlink-less syntax that does just
what we need
... and say what's the mapping of the new way to the old way
DS: this is also applicable to svg in text/html
JW: we need to decide which takes precedence
... we don't implement xlink, but we don't take some notice of some
of the xlink attrs
... if we take the href attribute instead of xlink:href, should it
then ignore all the other xlink attrs? or should the href override
all of the xlink attributes?
CL: suppose we had src, and it means xlink:type=embed.
ED: the only two that are used are xlink:title and xlink:href
CL: i've never seen xlink:role used in the wild
JW: we pay attention to xlink:show
<scribe> ... new or replace
CM: like target
CL: all the implementations took target in preference to xlink:show
anyway
JW: if the target attr is empty or not specified, it will look at
xlink:show
... if href overrides xlink:href, should we then ignore xlink:show?
CL: my off the cuff response to that is that when you find the new
attribute, it overrides all xlink attrs
DS: title and xlink:title are two different things
... xlink:title is the title of the linked to thing, and title is
the title of the element it's on
CL: we shouldn't force people to type xlink:type just to do that
<ed> <a href="foo" title="bar" xlink:href="foo" xlink:title="bar"/>
but should be possible to just do <a href="foo" title="bar"> in new
content
CM: hreflang exists, you could have hreftitle
ED: seems like we all prefer new xlink-less attrs to override xlink
ones
JW: i'm not sure about that
... say now someone sticks xlink:href and href on the content
... the behaviour will be that impls follow the href
DS: href and src
CM: i'd rather align with html's attr names
DS: i propose href to outgoing links and src for incoming links
CL: not sure what you mean by incoming links
DS: i mean for embedding type elements, like <image>
CL: i don't think they all fall in to two different categories
... e.g. xlink:href on gradients
... what type is that?
... one aspect is whether it's embedded, one aspect is whether it's
user actuated
DS: the ability for us to adopt href and src for some of our
elements, where the align, has a clear case
... i'd like to propose we resolve to, where there's a clear mapping
to html, that we use the same attr name
JW: i see the academic argument for distinct attr names
ED: but it's confusing since it's not the same as in html
JW: it's confusing because people are used to typing xlink:href for
everyone
... two reasons to consider doing them with different names
... one is for recognition that they're different types of links
... the other one is consistency
... with html, specifically
DS: html doesn't have some of these kinds of links, like gradient
links
CM: they have <label for>, but it's not a url
<ed> break for lunch
ed++
<ed> back for more of xlink
<ed> ACTION: CL to research where svg uses links, and make a
proposal for how to resolve ISSUE-2042 [recorded in
[18]http://www.w3.org/2009/06/12-svg-minutes.html#action04]
<trackbot> Created ACTION-2619 - Research where svg uses links, and
make a proposal for how to resolve ISSUE-2042 [on Chris Lilley - due
2009-06-19].
New DOM syntax
<ed> ISSUE-2044?
<trackbot> ISSUE-2044 -- Consider improving the SVG DOM interfaces
for attribute access -- RAISED
<trackbot> [19]http://www.w3.org/Graphics/SVG/WG/track/issues/2044
[19] http://www.w3.org/Graphics/SVG/WG/track/issues/2044
CM: so ecmascript allows host objects to do that
... rectElement.x = 20; is just implemented with a custom [[Put]] on
the SVGRectElement host object
JW: not sure if xpcom will allow you to do that
ED: it's just in the dom, just forwarding on the assignment
... in my quick test, just depending on the type of value you're
assigning, you either use .baseVal.value or .baseVal.valueAsString
CM: in html there's already something like this, window.location
... it's a Location object, but you can assign a string to it
... getting the values is a bit harder
... you can define [[DefaultValue]] on the SVGAnimatedLength
... that works ok for most types, but not for SVGAnimatedBoolean
... since ToBoolean in ecma-262 doesn't use [[DefaultValue]]
JW: it's probably not feasible to throw away the current SVG DOM
... unless we come up with something exceptionally good, we'll need
to stick with it
ED: we should try to make it more useful as we can, though
... maybe deprecate some parts going forward
DS: is it possible to make this in such a way such that we can also
make it work for canvas?
ED: i thought about it, it's not that simple
... it's not easy to generate something that would make any sense if
you record all the drawing commands
DS: we could make jquery-like or kevlin's createCircle()
... and allow dot syntax with that object
CM: so maybe getContext('svg') then canvas drawing commands gets you
an svg tree
<scribe> ACTION: doug to write up a proposal for joint canvas/svg
api, ISSUE-2044 [recorded in
[20]http://www.w3.org/2009/06/12-svg-minutes.html#action05]
<trackbot> Created ACTION-2620 - Write up a proposal for joint
canvas/svg api, ISSUE-2044 [on Doug Schepers - due 2009-06-19].
ED: for all of the list types, it feels very unnatural to use
getItem() and getNumberOfItems()
... it's very un-javascript like
JW: you already can use []-indexing on list objects
ED: it's not in the spec though
JW: it might be in DOM spec
CM: but SVG doesn't say it
<ed> would prefer .length and [i] instead of .numberOfItems and
.getItem(i)
CM: instead of or in addition to?
ED: the hard one is the numberOfItems one
CM: we could always just have .length as well
... also, SVGNumber is a bit sucky
... why not just have floats in an SVGNumberList
... you could do the same thing as with SVGLength, and have
SVGNumber have a [[DefaultValue]] that turns it into a Number
ED: another silly aspect is that you have to get the SVGSVGElement
... to create SVG types
... most of the times they're not inserted until later
... so having a constructor would be nice for the basic types
JW: i think that works already in mozilla
[21]http://dev.w3.org/SVG/proposals/type-constructors/type-construct
ors.txt
[21] http://dev.w3.org/SVG/proposals/type-constructors/type-constructors.txt
CM: i didn't propose constructors PathSegItem interfaces
... not sure how useful they would be
... but probably just improving SVGPathSegList would be better
ED: so we want to move forward on these?
CM: yes i think we could put these in a blank SVG 2.0 spec
<scribe> ACTION: update template directory with build scripts
[recorded in
[22]http://www.w3.org/2009/06/12-svg-minutes.html#action06]
<trackbot> Sorry, couldn't find user - update
<scribe> ACTION: cameron update template directory with build
scripts [recorded in
[23]http://www.w3.org/2009/06/12-svg-minutes.html#action07]
<trackbot> Created ACTION-2621 - Update template directory with
build scripts [on Cameron McCormack - due 2009-06-19].
<scribe> ACTION: cameron add these dom suggestions to a new svg 2.0
spec [recorded in
[24]http://www.w3.org/2009/06/12-svg-minutes.html#action08]
<trackbot> Created ACTION-2622 - Add these dom suggestions to a new
svg 2.0 spec [on Cameron McCormack - due 2009-06-19].
Test suite
<ed>
[25]http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/021
8.html
[25] http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0218.html
<ed> ACTION-2385?
<trackbot> ACTION-2385 -- Anthony Grasso to make an XSLT to change
the template of the 1.1 tests to the new one -- due 2008-12-25 --
OPEN
<trackbot> [26]http://www.w3.org/Graphics/SVG/WG/track/actions/2385
[26] http://www.w3.org/Graphics/SVG/WG/track/actions/2385
CL: dbaron explained reftests to us at csswg f2f
JW: i demoed them to svgwg last f2f
... the important thing for us is that you can do pixel-perfect
testing
... and thus automated testing
... i've written up some short docs on it
CL: we use image patches, which are like ref tests
... but more for compensating for bugs in batik, to generate the
reference png
JW: it's very important for interop
... the references should be in svg, i think
... don't need a harness, implementors can write their own
... and have by-hand harnesses for people to use (not automatic test
suite running)
... not sure if there's the need for a raster fallback
CM: what's in the baseline?
... paths?
JW: depends on the test
<ChrisL> benefir of a reftest is that the set of fonts, the
anti-aliasng, are the same for the reference and the test (both run
on same machine)
JW: you might want to start off with testing a rectangle with a
fill, for example
... from that level you would build up from it
... so some tests depend on functionality tested in previous tests
... we call the basic ones "sanity tests"
... whatever assumptions you make in the reference for a test, make
sure there are tests for those basic functionality in the test suite
... resolution independence is pretty much the only reason not to
use raster reference images, for simple things like testing <rect>
... my further plans, as well as technical issues like test format,
there are social issues and political issues around getting
implementors to agree on things
... especially implementors allowing you to have automated ways of
running the test suite in the browser
... organisation of tests, naming, how detailed they should be,
should each test do one feature, or many features in one
... a few other things i was working on; how to structure the tree
of tests so that different implementors could mark things as 'we
fail this"
... e.g. if moz sends all their tests to opera, a bunch will
probably faily
... you want to mark them as known fails, so that if they suddenly
start passing they notify you
... but wouldn't keep the tree red
... this is one of the places where ref tests falls down, it doesn't
support multiple implementors tagging this
DS: danc says he's been interested in it for a while
... plh was really interested
CL: related to passing tests around is the licence
... currently w3c licence is fairly restrictive
... the aim was to prevent vendors from grabbing a test suite,
fiddling with it, then saying they pass the test
... but more important is to give ppl the freedom to modify the
tests for their purposes
... so you can now licence them under a modified MIT licence
... i propose we use this in the future
JW: i'd rather creative commons zero licence
... it's essentially public domain
... it frees people up for snippets of code etc.
... MIT requires you to have a header
... and say who the contributors were
... it's a very open licence, but is still a licence, and has these
requirements
CL: the advantage of doing it with the modified MIT licence is that
it's currently allowed by w3c
DS: i was skeptical there was a reason to push for CC0, and thought
that there were useful aspects to a licence that requires
attribution etc.
... if everyone wants to go for CC0, then that's fine
JW: i'm happy with having provenance information in comments or
metadata in the document
... but it's not a licence
<ChrisL> So CC Attribution 3.0 Unported looks good to me
<ChrisL> [27]http://creativecommons.org/licenses/by/3.0/
[27] http://creativecommons.org/licenses/by/3.0/
JW: to me, whether it's a licence or not, the point is that we don't
want people to propagate modified tests
DS: that's the non-malicious case
... what if a group want to remove some features from a test suite
that they don't want, and distribute that?
ED: i wonder if there's a licence that fits out of the box
<ChrisL> actually this one is better
<ChrisL> [28]http://creativecommons.org/licenses/BSD/
[28] http://creativecommons.org/licenses/BSD/
<ChrisL> and arguably more applicable to markup (code)
<jwatt>
[29]http://www.w3.org/Consortium/Legal/2008/04-testsuite-copyright.h
tml
[29] http://www.w3.org/Consortium/Legal/2008/04-testsuite-copyright.html
CL: a three-clause bsd licence
JW: that's what the current test suite is under
<ChrisL> is it really iunder that?
JW: i want people to be able to take snippets out of the test slides
too
... and reuse them at will
DS: can we have the individual tests under once license, and the
test suite as a whole under another?
CL: for the new template, i'd like a link to this licence
... not the wall of capital letters
<ChrisL> lets just have a link to W3C 3-clause BSD License in the
test harness
ED: i think it would be good to move to the bsd licence
CM: will other implementors want to contribute with w3c 3-clause bsd
licenced tests?
... or would they be unhappy with anything but something like public
domain / cc0
JW: are we still open to discussion on using other licences in the
future?
DS: yes
RESOLUTION: We will move the SVG test suite to the new W3C 3-clause
BSD licence
<scribe> ACTION: erik to convert the test suites to use the 3-clause
bsd licence [recorded in
[30]http://www.w3.org/2009/06/12-svg-minutes.html#action09]
<trackbot> Created ACTION-2623 - Convert the test suites to use the
3-clause bsd licence [on Erik Dahlström - due 2009-06-19].
<ed>
[31]http://dev.w3.org/cvsweb/SVG/profiles/1.1F2/test/script/f11_1st_
2_f11_2nd.pl
[31] http://dev.w3.org/cvsweb/SVG/profiles/1.1F2/test/script/f11_1st_2_f11_2nd.pl
ED: we'll wait for anthony to finish the test suite conversion
script, then convert it and check it
... there are some 1.1 tests that need review
<scribe> ACTION: erik to go through the test suite to see which ones
need reviewing, and put that list on a wiki page [recorded in
[32]http://www.w3.org/2009/06/12-svg-minutes.html#action10]
<trackbot> Created ACTION-2624 - Go through the test suite to see
which ones need reviewing, and put that list on a wiki page [on Erik
Dahlström - due 2009-06-19].
Mailing minutes to www-svg
JW: i propose that we CC the minutes to www-svg
ED: i don't disagree with that, but they should still be on
public-svg-wg
DS: charter says we have to send to public-svg-wg at least
ED: i'm concerned conversations will fork
CM: i don't think that forking is a problem
... i'd be happy with doing technical discussion on www-svg
DS: we can't just CC the mail
... we could send to www-svg and bcc public-svg-wg
... we should have a disclaimer about the minutes being sent out
... when this was mentioned to chris yesterday (sending minutes to
www-svg) he was concerned about that as a policy and i suspect that
his concern may in part have been that the minutes are not clear if
you weren't there
... and also that it might generate a lot of noise, feedback before
our ideas are fully baked
... but that's just my guess on his concern is
CM: personally i'm happy if people can see our half baked ideas
JW: i suggest some disclaimer text
<jwatt> DISCLAIMER: The SVG Working Group provides these minutes,
unedited, in the interest of timely openness. The lack of editing
may make them difficult to understand or subject to
misinterpretation outside of context. If you find that to be the
case, polite requests for clarification are welcome.
DS: i think it's a worthwhile experiment to see if the policy causes
problems
... i'll note that this is how we operate in the Web Apps WG, and it
has caused a lot of discussion, but not problems
... work with the dom has generated helpful input
JW: if everything is done out of public view, and presented all at
once, you get a flood of comments
... which is hard to deal with
... if you send the minutes gradually, it heads off a whole swamp of
upset people
... by giving them a chance to voice their concerns at an earlier
stage
DS: before we've put too much work in to a solution that has
problems
CM: we had the thread on style/script in text/html on www-svg
... that worked ok
DS: since the svg wg has shown that we are trying harder towards
being better integrated into the web architecture, open web
platform, i think people are less prone to jump to bad conclusions
JW: one thing not in the disclaimer is about new ideas here not
being final
... often discussion about embryonic ideas
... and many of them could be thrown away
DS: or may not be the solution we settle on
JW: i'd like to keep the disclaimer short
DS: we should send something to www-svg before we start doing this,
signalling our intentions/concerns/...
... brainstorming
... "we were encouraged by recent conversations on www-svg and we
want to see as an experiment if working completely in the open works
for us"
RESOLUTION: We will send minutes to www-svg as well as public-svg-wg
as a first step
<scribe> ACTION: doug to send mail to www-svg with explanation of
what we'll be doing with minutes sending [recorded in
[33]http://www.w3.org/2009/06/12-svg-minutes.html#action11]
<trackbot> Created ACTION-2625 - Send mail to www-svg with
explanation of what we'll be doing with minutes sending [on Doug
Schepers - due 2009-06-19].
<ed> trackbot, make minutes
<trackbot> Sorry, ed, I don't understand 'trackbot, make minutes'.
Please refer to [34]http://www.w3.org/2005/06/tracker/irc for help
[34] http://www.w3.org/2005/06/tracker/irc
Summary of Action Items
[NEW] ACTION: cameron add these dom suggestions to a new svg 2.0
spec [recorded in
[35]http://www.w3.org/2009/06/12-svg-minutes.html#action08]
[NEW] ACTION: cameron to play with css flex box to see how
applicable it could be to svg [recorded in
[36]http://www.w3.org/2009/06/12-svg-minutes.html#action02]
[NEW] ACTION: cameron update template directory with build scripts
[recorded in
[37]http://www.w3.org/2009/06/12-svg-minutes.html#action07]
[NEW] ACTION: chris to add a strokeBelowFill canned vector effect
[recorded in
[38]http://www.w3.org/2009/06/12-svg-minutes.html#action03]
[NEW] ACTION: CL to research where svg uses links, and make a
proposal for how to resolve ISSUE-2042 [recorded in
[39]http://www.w3.org/2009/06/12-svg-minutes.html#action04]
[NEW] ACTION: doug to send mail to www-svg with explanation of what
we'll be doing with minutes sending [recorded in
[40]http://www.w3.org/2009/06/12-svg-minutes.html#action11]
[NEW] ACTION: doug to write up a proposal for joint canvas/svg api,
ISSUE-2044 [recorded in
[41]http://www.w3.org/2009/06/12-svg-minutes.html#action05]
[NEW] ACTION: doug to write up a shape path proposal [recorded in
[42]http://www.w3.org/2009/06/12-svg-minutes.html#action01]
[NEW] ACTION: erik to convert the test suites to use the 3-clause
bsd licence [recorded in
[43]http://www.w3.org/2009/06/12-svg-minutes.html#action09]
[NEW] ACTION: erik to go through the test suite to see which ones
need reviewing, and put that list on a wiki page [recorded in
[44]http://www.w3.org/2009/06/12-svg-minutes.html#action10]
[NEW] ACTION: update template directory with build scripts [recorded
in [45]http://www.w3.org/2009/06/12-svg-minutes.html#action06]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [46]scribe.perl version 1.135
([47]CVS log)
$Date: 2009/06/12 22:45:52 $
_________________________________________________________
[46] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[47] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20
Check for newer version at [48]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[48] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/pad/pad, repeat/
Succeeded: s/the PathSegList/PathSegItem/
Succeeded: s/ideass/ideas/
Succeeded: s/sohrt/short/
Found Scribe: Cameron
Found ScribeNick: heycam
WARNING: No "Present: ... " found!
Possibly Present: CL CM ChrisL DISCLAIMER DS JW ScribeNick ed eseidel j
oined jwatt left shepazu svg trackbot
You can indicate people for the Present list like this:
<dbooth> Present: dbooth jonathan mary
<dbooth> Present+ amy
WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth
Found Date: 12 Jun 2009
Guessing minutes URL: [49]http://www.w3.org/2009/06/12-svg-minutes.html
People with action items: add cameron chris cl dom doug erik suggestion
s these update
[49] http://www.w3.org/2009/06/12-svg-minutes.html
End of [50]scribe.perl diagnostic output]
[50] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Saturday, 13 June 2009 00:40:58 UTC