- From: Erik Dahlstrom <ed@opera.com>
- Date: Fri, 12 Jun 2009 18:49:02 -0400
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Minutes from day 3:
http://www.w3.org/2009/06/10-svg-minutes.html
or as text below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
10 Jun 2009
See also: [2]IRC log
[2] http://www.w3.org/2009/06/10-svg-irc
Attendees
Present
Doug_Schepers, Erik_Dahlstrom, Cameron_McCormack,
Jonathan_Watt, Sam_Ruby, Chris_Lilley
Regrets
Chair
Cameron
Scribe
ChrisL, heycam, jwatt
Contents
* [3]Topics
1. [4]Errata changes
2. [5]1.1SE publication
3. [6]Integration spec
4. [7]svg in html
5. [8]Filter module
* [9]Summary of Action Items
_________________________________________________________
<shepazu> [10]http://www.flickr.com/search/?q=manhattanhenge
[10] http://www.flickr.com/search/?q=manhattanhenge
<shepazu>
[11]http://www.epson.co.jp/e/newsroom/manage_news/manage_090430.htm
[11] http://www.epson.co.jp/e/newsroom/manage_news/manage_090430.htm
<shepazu> [12]http://www.amantepizza.com/menu.html
[12] http://www.amantepizza.com/menu.html
<heycam> whole wheat medium greek
<ChrisL> small wholewheat amore roma with extra anchovies
<ed> small regular Proscuitto Italiano Pizza
<ed> ChrisL:
[13]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/filters-displace-0
2-f.svg if you could add some pass criteria etc I could review that
test
[13]
http://dev.w3.org/SVG/profiles/1.1F2/test/svg/filters-displace-02-f.svg
<ed> maybe better wait until AG does the xslt update though
<heycam> close action-2550
<trackbot> ACTION-2550 Incorporate icc grammar closed
<shepazu> [14]http://www.wolaver.org/animals/giraffe&squirrel.jpg
[14] http://www.wolaver.org/animals/giraffe&squirrel.jpg
<heycam> ACTION: doug to republish the 1.1 errata [recorded in
[15]http://www.w3.org/2009/06/10-svg-minutes.html#action01]
<trackbot> Created ACTION-2611 - Republish the 1.1 errata [on Doug
Schepers - due 2009-06-17].
<shepazu> [16]http://www.wolaver.org/animals/baby_elephant.jpg
[16] http://www.wolaver.org/animals/baby_elephant.jpg
<heycam> close action-2551
<trackbot> ACTION-2551 Add some text to say what it means for an
SVGRect (and similar objects) to be "read only", such as with
SVGSVGElement::viewport closed
<heycam> close action-2002
<trackbot> ACTION-2002 Examine the scripts used by the working group
to check for similarities and if some can be replaced by a single
script closed
<anthony> heycam, do you think it's worth preserving the baseProfile
and version in the SVG tests?
<heycam> hmm
<heycam> i don't know if any tests have special values for those
<anthony> so maybe version
<heycam> i doubt it though
<anthony> like in F11 version="1.1
<heycam> probably safe either way
<anthony> right
<anthony> I might exclude baseProfile
<heycam>
[17]http://dev.w3.org/SVG/profiles/1.1F2/publish/changes.html
[17] http://dev.w3.org/SVG/profiles/1.1F2/publish/changes.html
<heycam> anthony, ok
<heycam> (that url was for doug)
<heycam> exclude how?
<heycam> in that xpath expression?
<heycam> maybe baseProfile should be kept as is
<anthony> ok
<heycam> since some tests are for tiny, some for basic, some for
full
<heycam> but i guess all the versions should be 1.1
<trackbot> Date: 10 June 2009
Errata changes
<jwatt> I'd propose changing:
<jwatt> "Note that the specification of a <number> is different for
CSS2 property values than for XML attribute values."
<jwatt> to:
<jwatt> "Note that the specification of a <number> is different for
CSS2 property values than for XML presentation attribute values,
including for corresponding CSS properties and presentation
attributes (specifically, scientific notation is allowed in
presentation attributes, but not in CSS properties)."
<jwatt>
[18]http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#DataType
Length
[18]
http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#DataTypeLength
<heycam> 'Note that the specification of a <number> is different for
CSS property values than for XML presentation attribute values
(specifically, scientific notation is allowed in presentation
attributes, but not in corresponding property values in 'style'
attributes or in style sheets)."
<ChrisL> 'Note that the specification of a <number> is different for
CSS property values in stylesheets (style attribute, style element,
or external stylesheets) than it is for for XML attribute values
(including presentation attributes). Specifically, scientific
notation is allowed in presentation attributes, but not in style
sheets)."
<ChrisL> or drop 'presentation' from second sentence
<jwatt> so
<jwatt> "Note that the specification of a <number> is different for
CSS property values in stylesheets (style attribute, style element,
or external stylesheets) than it is for XML attribute values
(including presentation attributes). Notably, scientific notation is
allowed in attributes, but not in style sheets)."
<ed> ACTION-2599?
<trackbot> ACTION-2599 -- Erik Dahlström to fix ISSUE-2046 to allow
negative startOffset in 1.1 -- due 2009-06-10 -- OPEN
<trackbot> [19]http://www.w3.org/Graphics/SVG/WG/track/actions/2599
[19] http://www.w3.org/Graphics/SVG/WG/track/actions/2599
<ChrisL> ScribeNick: ChrisL
1.1SE publication
cl: we cannot add new functionality (new elements attributes etc).
We ust be careful whether something is a substantive change
... we need to show implementability of clarified areas (test suite
report is good)
... larger issues that would require substantive new functionality
should be moved to SVG Core, from SVG 1.1, in the tracker
... i also thing the RNG should be published as a separate document
Integration spec
[20]http://dev.w3.org/SVG/modules/integration/master/SVGIntegration.
html
[20]
http://dev.w3.org/SVG/modules/integration/master/SVGIntegration.html
Abstract
The SVG Integration Module is intended as a guide to other markup
and programming on how to best integrate SVG, within the context of
that language's constraints. SVG may be integrated in whole or in
part, and may be included in another language by reference or by
inclusion (that is, through linking or inline). This specification
contains normatively referenceable material, and discusses default
behaviors and best practices, but is not intended to override the
des
change <link rel="stylesheet" type="text/css"
href="style/svg-style.css"/>
to <link rel="stylesheet" type="text/css"
href="../publish/style/svg-style.css"/>
(demo of widgets, including svg widgets)
how to reference script in the icon, but still have animation
ed: how css backgrounds that are svg are rendered is not clear
(percentages, etc)
... fantasia said this si something svg should specify
cm: border-image that is svg is another one
cl: want to avoid premature rasterisation, especially if its then
going to be rescaled
<heycam> list bullet images too?
ds: so some issues have come up with css and svg, its being
implemented now
sr: why would image in css background and in html img behave
differently
ed: up for discussion
(we conclude that interactivity and (user directed) link traversal
are the same)
cm: for immediate mode, how does that work?
sr: for mobile, bandwidth is more precious than meory
ed: and latency is also precious
cl: if there is no interaction, scripting, or animation its not
externally observable whether the dom has been retained or not
(discussion on whether ther ewill be low-end mobile devices as well
as powerful ones)
sr: canvas requires script
ds: could stil usefully have an svg that uses a dom, is rendered,
and then only the raster is kept
... as we can't anticipate all the possible use cases, we list them
all
cl: vodaphone uses both animated and static modes, and switches
between them dynamically. this saves needless cpu
ds: performance benchmarking suite, they found that below a certain
size raster is better than vector, they said
ed: if rasters are small its easy to cache
ds: happy to fold in some modes, just wanted to give other groups
the options
(discussion of modes used by CDF)
(discussion of CDF)
CDF test suite
[21]http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/index.xhtml
[21] http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/index.xhtml
ds: dynamic mode is the default for svg
... animated mode has no user interaction
... secure animated mode also enforces no external references,
brought up by Apple, seen as a security concern
(discussion of security exploits)
rs: not clear that this is doing anything more than showing a
resource the user has access to directly anyway
cm: (iframe and contentDocument discussion) ... so don't see the
need for the secure and insecure modes.
ds: secure animated mode indicates the intent
rs: example with email client, images don't show to prevent spammers
knowing the email was read
ds: this is why we wanted to list all the options, let users of the
spec decide which ones they want to use in their specs
jw: thunderbird does not display external images by default
... no special html mode, just an implementation decision
cl: probably setting prefs differently for email and for html
browsing
jw; another one about certificate warnings, wanted to use
stripped-down svg and asked us to specify it
scribe: covered by this spec
rs: initially thought there were too many options but we are
starting to see the realistic use cases for them....
ds: probably should give sample use cases for each one. already
recommend certain options
... this spec is intended primarily for other spec writers, not for
end users
cm: batik has both full dynamic and linking-but-no-other-interaction
modes
... immediate mode, renderng an svg to canvas then discarding ....
ds: extending svg section is pulled from svg 1.1
cl: (explains background for the extensibility rules, asked for my
MPEG)
ds: same for ODF for example, could also use this section
... yesterday was told that ODF is starting to make doug a liaison
with ODF to harmonise
jw: good to know wat draw can do that svg cannot
ds: they have a connector, for example
cl: is this a visual connector, or a triple-like 'x relates to y'
connector?
ds (describes aria roles as applied to svg)
(discussion of auto connectors vs metadata-decorated general
graphics)
cm: want to avoid automatic routing
... facility to write that in script is handy
<heycam> ScribeNick: heycam
JW: i'm skeptical about having an attribute on a path to say that
these two objects are connected
DS: one thing an authoring tool could do with role="connector" is
that it can realise that the path is acting as a connector
... they might give it a class or something to roundtrip it
... i'm more concerned about a screen reader
JW: for accessibility?
DS: yes
... if something is known to be a connector, there's an implicit
path to navigate around the document
JW: i can see some utility for accessibility
DS: also a script might look at all the elements with
role="connector", maybe use XBL2 to create behaviours on that
... or just plain script
JW: a good starting point would be looking at what inkscape actually
does
... and looking at what ODF does, and other formats and tools
... that do linking & connectors
DS: we're planning on adding a <point> element
... you could have those as children of <rect> to act as connection
points
<ChrisL> [22]http://www.graphviz.org/
[22] http://www.graphviz.org/
CM: i'm warying of specifying a connector routing algorithm
DS: if svg did this for people, people would use svg more
... script library might solve that
... if we're trying to solve real world problems, this is a big use
case
<ChrisL> cl: connector layout has an abundant literature and is
highly complex. we would not want to get into that, in my opinion.
better to allow different layout algorithms to be implemented on top
of, or to generate, svg
DS: if we're already putting in constraint stuff in svg, then having
an extension that is graph-svg (or not even svg) and browsers can
decide whether to implement that or not
... we can ask cameron's colleague on how to do this in svg
... or in some other spec
... if we had interest from implementors
... authors would rather just have a solution for doing graphs and
connecting things built in to the platform
CM: maybe porting his c++ library to js would be a good solution
<ed> [23]http://ajaxian.com/archives/ample-sdk-browser-in-a-browser
[23] http://ajaxian.com/archives/ample-sdk-browser-in-a-browser
<ChrisL> scribenick: chrisl
svg in html
<heycam> CM: happy with how the syntax end up?
<heycam> CL: how did it end up?
<heycam> ... my goals are, firstly, if you have svg out of a regular
authoring tool you should have minimum changes to make it work in
text/html
<heycam> ... e.g. take off xml decl and dtds off
<heycam> ... it would accept other things as well, i imagine
<heycam> ... if that's still true i'm mostly satisfied
<heycam> SR: if authoring tool choose to use a different default
namespace then it wouldn't work
<heycam> ... most tools use default svg namespace
<heycam> ... only exception i know of is the w3c profile of svg in
xhtml
<heycam> CL: that spec says nothing about rendering or anything,
just a demonstration of modular dtds combining together
<heycam> ... the svg 1.1 dtd has the same thing, the dtd allows you
to declare a prefix
<heycam> ... but nobody does
<heycam> SR: the only way to have valid XHTML+SVG+MathML profile is
to use prefixes
<heycam> CL: i wouldn't worry about that, it's just a demonstration
that you could do that with dtds
<heycam> SR: i've seen some people change their sites because of it
<heycam> ... i'm happy with svg prefixes not working in text/html
<heycam> CM: that's how it is at the moment
<heycam> CL: i don't want to see authoring tools change to have
"save as text/html compatible svg"
<heycam> SR: adobe like to put entity definitions in their output
<heycam> DS: i don't have a problem with an xml prolog and doctype
having to be stripped
<heycam> ... but what if i don't strip them?
<heycam> CL: should be reasonable defined behaviour
<heycam> ED: that would be the same if you put a DTD in the middle
of HTML-only document
<heycam> CM: think <!DOCTYPE ...> interpreted as a comment
<heycam> CL: defining entities and so on won't work, which is fine
<heycam> ... use xhtml5 if you want to do that
<heycam> DS: one thing i'm not happy with is that it wasn't clear to
us what the implications are of the parsing behaviour
<heycam> ... we assumed that an inline doctype is treated the same
as in html, but it's hard to read the parsing sections to determine
these things
<heycam> ... few high level overviews of the concepts involved
<heycam> SR: i've heard that before
<heycam> ... haven't had anyone volunteer to fix it though
<heycam> CL: common in w3c for someone to propose wording
<heycam> ... usually that's because they found specific bits
confusing, not "the whole document is confusingly written"
<heycam> DS: in the table of contents there's a section on svg
<heycam> ... but it would be useful to have some
prefatory/introductory material that says that svg is basically
supported in text/html
<shepazu> [24]http://www.w3.org/TR/html5/the-canvas-element.html#svg
[24] http://www.w3.org/TR/html5/the-canvas-element.html#svg
<scribe> scribenick: chrisl
sr: title in html is effectively a cdata marked section
cm: seems like the parsing on html5 for svg is headed ina good
direction, sensible people are commenting
... cdata marked sections
sr: my pages are xhtml5 and have inline svg, but by using cdata I
can make some text at least show up in IE
... my content shows up mostly intact in IE
cm: so both solutions for cdata would work. one makes script that
has no cdata break
... < symbols are rare in CSS (not so for > )
... so, ok with that
ds: where does it say in html5 about dom interfaces in svg?
cl: there is no indication that svg and mathml are anything other
than examples
Elements that are from namespaces other than the HTML namespace and
that convey content but not metadata, are embedded content for the
purposes of the content models defined in this specification. (For
example, MathML, or SVG.)
ds: if you are defining a platform then it all needs to be defined,
not some parts merely illustrative examples
... would have been better if the parsing and the rest of the spec
was separate as many suggested
cl: I can understand how implementors could be confused whether svg
and mathml is actually part of html5 and required for an html5 user
agent
cm: are the interfaces required?
ds: quotes "When an XML name, such as an attribute or element name,
is referred to in the form prefix:localName, as in xml:id or
svg:rect, it refers to a name with the local name localName and the
namespace given by the prefix, as defined by the following table:"
... looks like an informative not, document object of svg and html
... quotes "For example, if an HTML implementation also supports
SVG, then the Document object implements both HTMLDocument and
SVGDocument." which is non-normative
If the root element is an svg element in the
"[25]http://www.w3.org/2000/svg" namespace, and the user agent
supports SVG, then return the value that would have been returned by
the DOM attribute of the same name on the SVGDocument interface.
[SVG]
[25] http://www.w3.org/2000/svg
Web browsers that support HTML must process documents labeled as
text/html as described in this specification, so that users can
interact with them.
but not "Web browsers that support SVG must process document
fragments labeled as image/svg+xml as described in the SVG
specification, so that users can interact with them."
and the dsame for mathml
<heycam> "The nodes representing HTML elements in the DOM must
implement, and expose to scripts, the interfaces listed for them in
the relevant sections of this specification."
<shepazu> I'd prefer stronger wording in 2.2, indicating that SVG
should/must be supported
cm: not finding a requirement to implement the svg interfaces if svg
is supported
<shepazu> there's a lot of ambiguity here... it needs a clear
statement about SVG and MathML being supported, and likewise the
interfaces
rs: sounds like the stronger statement would preclude an implementor
saying they support html5 if they dont support scripting, svg,
mathml
... where does it say this statement in your blog?
ds: i'm talking about the platform, as a platform, html5, svg is in
there. As a specification, I would like it to say that too
rs: i thought that was the intent. Typically ian is very deliberate,
so if the spec says svg is optional thats probably ians intent
ds: so how do you think that will fly, if the svg wg wants for it to
be non optional
ds; want it asdded to webb rowsers and other interactive user agents
rs: should specify a profile
ds: svg 1.1, then
rs: a significant goal is interop between browsers, and making such
a major part optional harms interop
(general agreement)
ds: png is a required format for example
ed: there is a requirement to make PNGs (as a data url) not to
render them
<ed> that's canvas.toDataURL
rs: was not aware that pdf could be used on an img tag
<ed> [26]http://dev.w3.org/html5/spec/
[26] http://dev.w3.org/html5/spec/
<rubys>
[27]http://dev.w3.org/html5/spec/Overview.html#cdata-section-state
[27] http://dev.w3.org/html5/spec/Overview.html#cdata-section-state
cl: video used to require ogg theora
ds: some people demanded it be removed
ed: audio with WAVE container encoded as PCM is the only external
format that is required so far
sr: acid3 has some svg tests, not very much
ed: yes, a few SVG dom tests
sr: consistent errr handling in html5 gives interop. same for
handling svg. needs to be a minimal list or a concentric circle set
of conformance classes
cm: easier if there is a specific conformance clash
... html doesnt require svg interfaces to be implemented on svg
nodes, not so much of a problem since svg requires it
ds: mathml has a dom too
<ed> ACTION: jwatt to find out about svg integration in html5
[recorded in
[28]http://www.w3.org/2009/06/10-svg-minutes.html#action02]
<trackbot> Created ACTION-2612 - Find out about svg integration in
html5 [on Jonathan Watt - due 2009-06-17].
action cameron to find nathan hurst's paper on text flowing into
growing shapes and send copy to liam
<trackbot> Created ACTION-2613 - Find nathan hurst's paper on text
flowing into growing shapes and send copy to liam [on Cameron
McCormack - due 2009-06-17].
action-2613
action-2613?
<trackbot> ACTION-2613 -- Cameron McCormack to find nathan hurst's
paper on text flowing into growing shapes and send copy to liam --
due 2009-06-17 -- OPEN
<trackbot> [29]http://www.w3.org/Graphics/SVG/WG/track/actions/2613
[29] http://www.w3.org/Graphics/SVG/WG/track/actions/2613
<heycam> close ACTION-2552 (edit)
<heycam> close ACTION-2552
<trackbot> ACTION-2552 Get filters module building closed
<jwatt> ScribeNick: jwatt
Filter module
ED: filters module now building
... except IDL
... need move everything over from 1.1 2nd edition draft
... to integrate filters applied to HTML stuff that roc sent in
<ChrisL> <xsl:attribute name="xmlns:xsl"
namespace="whatever">[30]http://www.w3.org/1999/XSL/Transform</xsl:a
ttribute>
[30] http://www.w3.org/1999/XSL/Transform%3C/xsl:attribute%3E
<ChrisL> it will not result in a namespace declaration being output.
<ed> [31]http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html
[31] http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html
<ed>
[32]http://lists.w3.org/Archives/Public/www-svg/2008Sep/0041.html
[32] http://lists.w3.org/Archives/Public/www-svg/2008Sep/0041.html
ED: we should discuss that proposal
... as I understand, Mozilla doesn't implement some of the filter
inputs e.g. BackgroundImage
JW: correct
ED: I'm wondering if we should define what those mean in HTML terms
... same as for SVG?
JW: I was assuming so
CM: what if you have filterUnits="userSpaceOnUse"?
ED: proposal says bounding client rect
... what capabilities does enable-background give us in the HTML
context?
... is it needed?
<ed>
[33]http://www.w3.org/TR/SVG11/filters.html#AccessingBackgroundImage
[33] http://www.w3.org/TR/SVG11/filters.html#AccessingBackgroundImage
AG: let me get a pointer to the SVG Open 2005 paper that explains
what enable-background is useful for
<anthony>
[34]http://www.svgopen.org/2005/papers/abstractsvgopen/index.html
[34] http://www.svgopen.org/2005/papers/abstractsvgopen/index.html
<anthony>
[35]http://www.svgopen.org/2005/papers/abstractsvgopen/index.html#S9
.
[35] http://www.svgopen.org/2005/papers/abstractsvgopen/index.html#S9.
ED: the draft from roc doesn't say anything about enable-background
JW: I don't think roc considers it a core feature, although I found
it very useful when writing filters stuff years ago for ASV
<ChrisL> EB has got a bad rep because of Illustrator slapping it on
every document. but it certainly does have its uses
ED: the current text in the svg spec for EB is very SVG specific,
and says if it's used in non-SVG the behavior will need to be
defined
CL: HTML is quite different to the SVG painter's model, since it has
z-index, stacking contexts, absolutely positioned content,...
... that makes it a much harder problem for HTML, so I can
understand why he left that bit out
AG: you could just take whatever's written to the device, and use
that as the background when EB is set to 'accumulate'
ED: so you're suggesting not to allow the 'new' value?
AG: that just gives you a blank buffer of a set size
... or I think that's what it should do
<ed> ED: so if you have EB=new on some random HTML element, is it
possible to get the backgroundimage in a consistent way when you
apply the filter?
<ed> ...you need to figure out how to go back in the "rendering
tree" to generate it
<ed> ...not as easy as in svg
<heycam> close ACTION-2613
<trackbot> ACTION-2613 Find nathan hurst's paper on text flowing
into growing shapes and send copy to liam closed
ED: I'm not sure it's a good idea to draw into the background image
when you see 'new', since you don't know if you will end up using it
... so I suggest to clearly mark it as something we want feedback on
on how it should work, and list some of the issues
... but I don't think there's a problem with 'accumulate'
AG: it depends which model you use
... if using the compositing model it's not so simple because...
... the reason compositing is done that way is to produce the same
results as Abobe did in their model
... when you do the compositing with filters you get the background
twice
ED: it might be possible to define for HTML that it doesn't draw
anything but the background image
AG: that might work
ED: we could try that and see if it works
AG: for 'accumulate' you're not rendering to the device anyway
<ChrisL2> so, save a pristine copy of the background, continue
accumulating onto it, then subtract out the original background
again
ED: and there's FillPaint and StrokePaint
CM: I thought we might be able to use pseudo elements to set fill
and stroke on them
<heycam> like div::background { fill: blah; stroke: blah; }
<heycam> with initial values for fill and stroke that mean they get
their values from color/background properties
CM: are you allowed to have different initial values for different
elements?
ED: making fill and stroke apply could clash a bit with the special
CSS syntax for gradients implemented by webkit
CL: you could also have BorderPaint, ContentPaint,...
... giving them that might be better
<ChrisL2> instread of trying to map css boxmodel concepts to fill
and stroke, give them direct access to their concepts as paint
CL: we should put that in as a suggestion in an editorial note
<ChrisL2>
file:///D:/WWW/dev/SVG/modules/filters/master/SVGFilter.html#FillPai
nt
<ChrisL2> er, sorry
[36]http://dev.w3.org/SVG/modules/filters/master/SVGFilter.html#Fill
Paint
[36]
http://dev.w3.org/SVG/modules/filters/master/SVGFilter.html#FillPaint
ED: another thing I'm not clear on is how the 'filter' property
would be applied to the HTML compositing model
... basically in what order other type of operations are applied -
where 'filter' fits in with mask and clipping for example
... say you had an 'opacity' property set for example, that would be
applied after the 'filter' property I guess
... that's what it says here
... I guess clipping is the one thing I'm most concerned about
... SVG spec says clipping happens after filtering
... seems reasonable to have the same for HTML
JW: desirable for consistancy
ED: okay, so I'll work on folding this in, but first priority is to
port everything over from SVG 1.1 2nd Ed and make sure things are
consistant
... I'm about to commit some tests to the 2nd Ed test suite
... Antony, it would be good to have any enable-background tests you
have
AG: I'll send over anything I have that would be useful
Summary of Action Items
[NEW] ACTION: doug to republish the 1.1 errata [recorded in
[37]http://www.w3.org/2009/06/10-svg-minutes.html#action01]
[NEW] ACTION: jwatt to find out about svg integration in html5
[recorded in
[38]http://www.w3.org/2009/06/10-svg-minutes.html#action02]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [39]scribe.perl version 1.135
([40]CVS log)
$Date: 2009/06/10 22:38:25 $
_________________________________________________________
[39] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[40] 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 [41]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[41] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/bot/both/
Succeeded: s/that //
Succeeded: s/document/HTML-only document/
Succeeded: s/work/work, which is fine/
Succeeded: s/parsing/parsing sections/
Succeeded: s/only/audio with WAVE container encoded as PCM is the only/
Succeeded: s/c:/cm:/
Succeeded: s/htl5/html5/
Succeeded: s/.../ds:/
Succeeded: s/give us/give us in the HTML context/
Succeeded: s/elements/elements?/
Succeeded: s/class/clash/
Succeeded: s/class/clash/
Succeeded: s/that is/that in/
Found ScribeNick: ChrisL
Found ScribeNick: heycam
Found ScribeNick: chrisl
Found ScribeNick: chrisl
Found ScribeNick: jwatt
Inferring Scribes: ChrisL, heycam, jwatt
Scribes: ChrisL, heycam, jwatt
ScribeNicks: ChrisL, heycam, jwatt
Present: Doug_Schepers Erik_Dahlstrom Cameron_McCormack Jonathan_Watt S
am_Ruby Chris_Lilley
Found Date: 10 Jun 2009
Guessing minutes URL: [42]http://www.w3.org/2009/06/10-svg-minutes.html
People with action items: doug jwatt
[42] http://www.w3.org/2009/06/10-svg-minutes.html
End of [43]scribe.perl diagnostic output]
[43] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Friday, 12 June 2009 22:49:53 UTC