W3C home > Mailing lists > Public > public-svg-wg@w3.org > April to June 2009

Minutes, Raleigh F2F 2009 day 2

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>
Message-ID: <op.uvfobgjqgeuyw5@macbooked.local>
Minutes from day 3:


or as text below:


       [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


           Doug_Schepers, Erik_Dahlstrom, Cameron_McCormack,
           Jonathan_Watt, Sam_Ruby, Chris_Lilley


           ChrisL, heycam, jwatt


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


      [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:
    2-f.svg if you could add some pass criteria etc I could review that


    <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

    <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


      [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

    <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)."



    <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

    <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




    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

    change <link rel="stylesheet" type="text/css"

    to <link rel="stylesheet" type="text/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

    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

    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

    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

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

    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'

    ds (describes aria roles as applied to svg)

    (discussion of auto connectors vs metadata-decorated general

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

    <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

    <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

    <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

    <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

    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.

      [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

    rs: sounds like the stronger statement would preclude an implementor
    saying they support html5 if they dont support scripting, svg,
    ... 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/


      [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

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



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

      [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


      [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
    ... is it needed?


      [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


      [34] http://www.svgopen.org/2005/papers/abstractsvgopen/index.html


      [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

    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

    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

    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

    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> er, sorry


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

    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
    [NEW] ACTION: jwatt to find out about svg integration in html5
    [recorded in

    [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

      [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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:11 UTC