W3C home > Mailing lists > Public > www-svg@w3.org > September 2009

Minutes, 28 September 2009 SVG WG F2F - Day 3

From: Erik Dahlstrom <ed@opera.com>
Date: Mon, 28 Sep 2009 19:25:26 -0700
To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Message-ID: <op.u0zycotfgeuyw5@erik-dahlstroms-macbook-pro.local>
Minutes in html format:


   http://www.w3.org/2009/09/28-svg-minutes.html


or as text below:


    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                    SVG Working Group Teleconference

28 Sep 2009

    See also: [2]IRC log

       [2] http://www.w3.org/2009/09/28-svg-irc

Attendees

    Present
           Anthony, Cameron, Chris, Doug, Erik, Jonathan

    Regrets
    Chair
           Erik

    Scribe
           Erik

Contents

      * [3]Topics
          1. [4]SVG in HTML5
          2. [5]canvas API
          3. [6]random issues
      * [7]Summary of Action Items
      _________________________________________________________



    <shepazu> Discussion on the topics of scripting interface design,
    Web IDL, and coordination between W3C Working Groups, ECMA TC-39,
    and other interested parties.

    <shepazu> This list is not a forum for script authoring.

    <ChrisL> issue-2285?

    <trackbot> ISSUE-2285 -- Resolving @primitiveUnits and z attribute
    discrepancies -- RAISED

    <trackbot> [8]http://www.w3.org/Graphics/SVG/WG/track/issues/2285

       [8] http://www.w3.org/Graphics/SVG/WG/track/issues/2285

    <heycam> ok only five tests left to write, four of them filter ones

    <heycam> nice one, shepazu

    <heycam> :)

    <heycam> the footnote was a great touch too

    <shepazu> heycam: thanks :)

    <trackbot> Date: 28 September 2009

    <heycam> Meeting: Mountain View 2009 SVG WG F2F Day 3

    <heycam> Chair: Cameron

    <heycam> Scribe: Erik

    <scribe> scribeNick: ed

SVG in HTML5

    CM: looked at html5 wrt svg

    <heycam>
    [9]http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_HTML5_Notes

       [9] http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_HTML5_Notes

    CM: some notes from reading through the spec
    ... let's go through the list (link above)
    ... first point, requiring document to implement SVGDocument and
    HTMLDocument
    ... required only if the UA supports svg

    AG: what's the difference between HTMLDocument and SVGDocument

    CM: they're similar, has title attribute and so on
    ... SVGDocument also has rootElement which points to the root svg

    ED: it's the same as documentElement, we added that to tiny12 IIRC

    CM: the general approach of supporting all the document interfaces
    on document is the way to go

    DS: i agree
    ... it's a good way of testing if it supports a language

    CL: so you can use document.createElement in an svgdocument to
    create non-svg elements?

    DS: yes, I do that all the time

    CM: yes, also works in HTML, it's in dom core
    ... one important thing to note is that html5 doesn't require svg to
    be implemented

    DS: the argument from hixie has been that since certain formats are
    implemented anyway there's no point in actually requiring them
    ... for png, jpeg etc
    ... same thing with the video codec
    ... so it's not inconsistent in the way that other formats aren't
    required either

    CM: though canvas is required

    DS: and png is required as an output format from canvas
    ... we should push back on this issue
    ... there needs to be a required video format

    CM: though that's different from requiring svg

    DS: it's similar though, not requiring common formats
    ... hixie's stance that it's not required for interop I don't agree
    with

    CM: when you say svg should be required there are many places where
    it could be supported, like img, object versus just supporting the
    dom (e.g the svg elements)
    ... regardless of whether you support svg the elements should be put
    in the correct namespace
    ... though the interfaces on those elements may not be supported

    DS: would want the elements to render if they're parsed into the
    correct namespace

    ED: would be nice to have a requirement, but i can understand why
    there might be resistance to that

    DS: as an author i want to know what I can rely on, if you can
    require canvas you can require svg

    CM: the requirement for rendering svg is in the svg spec

    DS: what if i made an rss reader
    ... should it also support svg?
    ... or if i have a mobile UA
    ... maybe it should be a should-level requirement

    ED: there are different conformance-classes in HTML5 though, so may
    be that it is a must-level requirement for some conformance-class

    DS: so a conformance class that requires support for svg, png, jpeg
    etc
    ... that's what we should ask for

    CM: (reads out current conformance classes in html5)

    DS: maybe "web-application user agents"
    ... distinction from "web browsers and other interactive user
    agents"
    ... by requiring the image formats

    CM: (reads thread on requirement for svg support)

    <heycam>
    [10]http://lists.w3.org/Archives/Public/public-html/2009Aug/1308.htm
    l

      [10] http://lists.w3.org/Archives/Public/public-html/2009Aug/1308.html

    CM: added wording to say that interfaces must be implemented if you
    have e.g an SVGSVGElement

    ED: still doesn't guarantee rendering

    CM: ok, next point: html5 says that title from htmldocument wins
    over the svgdocument
    ... depending on the root of the document

    ED: though having an svg root in a text/html document wouldn't be
    conforming would it?

    CM: yes, that's probably quite unlikely to occur
    ... this is probably a minor detail, which won't cause many problems
    ... next point: html5 says "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.)"
    ... only the 'svg' element can be embedded content

    ED: only case I can think of is allowing non-rendering elements
    outside of <svg>, things like gradients
    ... those don't depend on the coordinate system directly, so would
    be fine to have even outside of an svg fragment
    ... but it's not that so important I think

    CM: we can point out the inconsistency in the spec

    CL: probably easier to always require an svg fragment, even though
    some elements don't depend on that

    CM: we could define some specialcases for it though
    ... next point: img element is forbidden to reference an svg
    document that has script inside

    DS: the better requirement would be "the img element must not
    execute scripts in the referenced content"

    CM: (reads out parts of the html5 img src definition)
    ... so allowing the animation and not allowing scripting is what we
    wanted
    ... not disagreeing with that, but referencing documents that have
    scripts inside should be allowed

    AG: having to make new documents for the purpose of conforming would
    be silly
    ... (regarding paged-media)
    ... could show a particular page

    CM: for the svg with script case I think it's conceivable that you
    don't expect scripts to run when you reference it from an img
    element
    ... it's not clear what it means with non-interactive
    ... what if you had a smil animation that had something depending on
    e.g click
    ... that wouldn't conform

    DS: i don't think html5 should say anything about what you can point
    to
    ... from img

    CM: i propose we ask for saying that it's conforming to point to
    scripted and/or interactive svg content (just that those scripts
    shouldn't run, and any interaction would be disabled)
    ... next point: security and privacy considerations...
    ... (reads out point from wikipage)
    ... unlike the img element doesn't say anything about which
    documents video can reference

    CL: not that strange to want to sandbox it for video

    (discussion on animated gifs and whether that is video or image)

    CM: it's a bit strange to reference svg from video, especially since
    you might have a foreignobject with html inside from there
    ... next point; canvas getDataUri possible support for svg
    ... probably fine

    ED: there's no one mapping, if we wanted the same output from ua:s
    then it'd need defining

    CM: next point: exporting svg
    ... requires that any HTML child elements of foreignObject must be
    flow content.
    ... that is things that can be inside of body
    ... think that's reasonable

    ED: that would prohibit someone from putting a <head> element for
    example, right?
    ... just thinking of e.g wanting to pull in external stylesheets for
    example

    CM: and bgcolor maybe?
    ... i think you should really be allowed to leave out the body
    element
    ... inside foreignobject

    (discussion on html elements outside of foreignobject in svg)

    CL: we should have a specific element for embedding html in svg,
    with a different name and defined behaviour
    ... in the integration spec maybe

    CM: so having <html> or <body> in foreignObject in text/html would
    be causing problems for the html parser
    ... so is it worth asking for these cases to be allowed

    ED: it'd work fine in XHTML though
    ... but I don't think it's any real problem to say it's
    non-conforming

    CM: next one: Requires that <svg:title> inside HTML documents have
    only phrasing content.

    AG: what is title used for mostly?
    ... and what do we require in svg?

    CL: we restricted it in svgt12

    DS: it's just text in tiny12

    CM: do we mind that html5 restricts what you can put inside of
    title?

    CL: quite reasonable

    DS: unless you have a switch
    ... title inside of switch, or switch around title
    ... using that with systemLanguage might be good
    ... suggesting contentmodel of metadata or foreignobject
    ... if tspan is child of title, ua should honor style but not
    positioning

    CL: sounds like the tooltip element would be what you wnat

    DS: still doesn't solve the contentmodel of title

    CL: having markup there for i18n is common
    ... but doesn't care much about what the elements are called (in xml
    anyway)

    DS: maybe explaining why title is an element early in the svg spec
    would be good
    ... several usecases we are trying to address
    ... allowing switch either inside or outside of title
    ... styling for tooltips
    ... structured content
    ... must be internationalizable
    ... structured and styled content are similar
    ... we also want to have a clear content model

    CM: don't think we need to decide all this to resolve the html5
    issue

    DS: wrt to html i think it's reasoable to say that we don't want to
    restrict it to be phrasing content, it might be better to treat it
    the same way foreignobject
    ... or text or metadata

    CM: that's to allow e.g tspans inside title
    ... the way the parser differentiates between elements with the same
    name depends on the context

    DS: maybe we should restrict the elements that are allowed to be
    anything that can be inside of an <svg:text> element or any phrasing
    content

    CM: for the tooltip case you might want to allow graphic elements,
    such as rects and other things

    DS: don't think it's necessary to have a new element for tooltips,
    we already have title

    CM: agree that title shouldn't have graphical content

    DS: batik and opera shows the title as tooltip
    ... as long as phrasing content includes svg phrasing content
    (tspan, tref etc)
    ... the UA may honor the styling (italics and bold perhaps, not
    colors)

    CM: and switch?

    DS: right
    ... but restricted to the content model of its parent
    ... so maybe say that we plan to allow switch, tspan, tref in title
    and calling that svg phrasing content

    CM: teh spec says that the semantics of svg elements are defined by
    the svg spec or by other relevant specs

    CL: we should say that's good

    CM: next one:
    ... "The SVG specification states that elements that are not in the
    SVG namespace, that are in SVG fragments, and that are not included
    in a foreignObject element, are to be ignored. Similarly, this
    specification does not define any processing for elements in SVG
    fragments that are not in the HTML namespace; they are considered
    neither conforming nor non-conforming from the perspective of this
    specification."
    ... doesn't affect the conformance of the html document, so you
    could have crazy invalid svg content inside, but the html could
    still be valid

    CL: i think that's ok

    CM: i asked for some explicit link for saying that svg fragments
    must be conforming svg document fragments
    ... that would cause the html to become non-conforming in some cases

    CL: but it's similar to how html is treated in svg

    ED: it probably fine

    <ChrisL> nvdl and relaxng - we define onl the validity of tyhe svg
    bits. its not 'ignoring', its 'splitting up and routing to the
    appropriate validator'.

    CM: next one, Suggests that SVG could be used for tag clouds.
    ... Allows <link rel="icon" sizes="any"> examples with svg
    ... looking at the examples in 9.1.2
    ... the example that has a prefixed element

    JW: so prefixed elements would break the web?

    CM: that's what I've heard from opera people anyway
    ... also the argument that prefixes are hard

    JW: prebound prefixes is easy, like for svg
    ... seems like a bogus argument to avoid namespace prefixes
    ... all comes down to extensibility
    ... prebound prefixes would be good

    DS: for svg and mathml that would be good

    CM: maybe you should have a special namespace used for unrecognized
    prefixes
    ... and maybe split the prefix and localname when creating the
    element
    ... instead of doing something like localname=cdrU00003Alicense
    ... the table mapping svg element casing is stll missing textArea
    and solidColor from 1.2Tiny
    ... we should push back on that
    ... referencing SVGT12, because the scripting section is better
    there
    ... asked why SVG 1.1 isn't there as a normative reference

    DS: we should publish the svg integration spec
    ... so that they could point to that spec

    CM: would need to add the tables

    DS: and links to the spec that defines the elements

    CL: for elements defined in two versions?

    DS: have one column for each

    <shepazu>
    [11]http://dev.w3.org/SVG/modules/integration/SVGIntegration.html

      [11] http://dev.w3.org/SVG/modules/integration/SVGIntegration.html

    CM: that's the end of the html5 summary

    <scribe> ACTION: heycam to summarize the html5 conclusions from
    these minutes and send them to the HTML WG [recorded in
    [12]http://www.w3.org/2009/09/28-svg-minutes.html#action01]

    <trackbot> Created ACTION-2675 - Summarize the html5 conclusions
    from these minutes and send them to the HTML WG [on Cameron
    McCormack - due 2009-10-05].

canvas API

    AG: do we need to define how it gets used in SVG?

    DS: yes
    ... the split out spec says the host language defines which elements
    have the getContext method

    CM: if it's a mixin interface then you wouldn't want it to inherit
    from element
    ... would you expect that to be on the image element?

    DS: and the video element

    ED: not convinced about the video element having getContext

    <shepazu>
    [13]http://lists.w3.org/Archives/Public/public-canvas-api/2009JulSep
    /0021.html

      [13]  
http://lists.w3.org/Archives/Public/public-canvas-api/2009JulSep/0021.html

    CM: the rendering order would need to be defined
    ... not sure about which usecases he expects to address
    ... accessing pixel values, or something else

    AG: in that last paragraph he says we can render to all these
    different elements

    CM: assuming it's been implemented, what would it do when used in
    foreignObject?
    ... ppl have wanted for ages to be able to read pixel values from
    svg
    ... AG would you be able to find out the use-cases?

    AG: sure
    ... I think he wants to hear what the WG thinks too
    ... I'll ask about the use-cases for each of these elements

    DS: obviously it makes sense to allow getContext on the image
    element
    ... if you have that image and you write upon that image, and you
    <use> that image, does it use the image that was drawn on by canvas?

    CM: what happens when you resize, if the image element width/height
    are in user units?

    ED: maybe it'd make more sense to introduce a new element in svg for
    canvas, stating that the width and height are in actual pixels

    (discussion on user units vs pixels)

    CM: in terms of pixel values, people want to know the value at some
    particular user units position
    ... without having to get a context and draw a complex svg to it,
    then get the pixels

    ED: for such cases it might be better to offer that functionatlity
    on the SVGSVGElement, since that holds the actual context for the
    entire svg
    ... also I wonder what to do about the case with image that has no
    xlink:href, which you mihgt wnat to use for a blank drawing area

    CM: for the use-case of wanting to know color values somewhere
    ... having some separate interface for getting color values at some
    certain position in user space
    ... without having to explicitly render to some new buffer
    ... so what about drawing trees of content to canvas
    ... roc was working on that?

    JW: no
    ... basically the main thing is drawing svg documents as rasters
    ... being able to reference svg images from img, css backgrounds etc

    ED: opera supports rendering svg to canvas, but taints the canvas so
    that you can't get the pixels
    ... we researched the various things that could make it crossdomain,
    and marking the canvas "safe" would need to be done on the document
    level (so that it includes stylesheets, things inside of
    foreignObject e.g iframe, and elements in svg referencing stuff

    DS: anything that can affect the rendering of the document including
    external resources (e.g css) should have dirty/clean flag
    ... for the document

    CM: what's the status of the split out canvas spec?

    DS: one guy from microsoft will be added as editor

random issues

    <heycam>
    [14]http://www.w3.org/mid/20090928065405.GC25086@wok.mcc.id.au

      [14] http://www.w3.org/mid/20090928065405.GC25086@wok.mcc.id.au

    ED: agree

    <heycam>
    [15]http://www.w3.org/mid/20090928061536.GB25086@wok.mcc.id.au

      [15] http://www.w3.org/mid/20090928061536.GB25086@wok.mcc.id.au

    ED: maybe we could say something like until the object is modified
    it's as if the element had not specified the attribute

    [16]http://www.w3.org/TR/SVG11/painting.html#StrokeProperties

      [16] http://www.w3.org/TR/SVG11/painting.html#StrokeProperties

    CM: returning to
    [17]http://www.w3.org/mid/20090928061536.GB25086@wok.mcc.id.au

      [17] http://www.w3.org/mid/20090928061536.GB25086@wok.mcc.id.au

    ED: would prefer the lacuna values to not be special computed values
    for things like textLength for example
    ... IIRC what Opera is currently doing is to initialize to 0 but
    have the object be disconnected from the attribute until it's
    modified at which point it will become "live"

    <ChrisL> I suggest either having 'unknown' or calling the same dom
    method to compute the length

    <heycam>
    [18]http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMO
    verview

      [18]  
http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMOverview

    CM: ok, but some may not have an unknown unit/type

    <ChrisL> chrisl: (proposes a marvelous solution)

    <scribe> ACTION: fix the 1.1 second edition wording for values that
    are accessed where no attribute was provided,
    [19]http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMO
    verview and have it be NaN or 0 with unknown unit depending on the
    type of domobject [recorded in
    [20]http://www.w3.org/2009/09/28-svg-minutes.html#action02]

      [19]  
http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMOverview

    <trackbot> Sorry, couldn't find user - fix

    <scribe> ACTION: CL to fix the 1.1 second edition wording for values
    that are accessed where no attribute was provided,
    [21]http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMO
    verview and have it be NaN or 0 with unknown unit depending on the
    type of domobject [recorded in
    [22]http://www.w3.org/2009/09/28-svg-minutes.html#action03]

      [21]  
http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMOverview

    <trackbot> Created ACTION-2676 - Fix the 1.1 second edition wording
    for values that are accessed where no attribute was provided,
    [23]http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMO
    verview and have it be NaN or 0 with unknown unit depending on the
    type of domobject [on Chris Lilley - due 2009-10-06].

      [23]  
http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMOverview

    <ChrisL> getComputedTextLength()

    <ChrisL> So, can I introduce lacuna values to make that write-up
    clearer

    <heycam> ChrisL, yes but that is a large undertaking

    <ChrisL> ok so its a zero value, not a lacuna value

    <heycam> action-2676?

    <trackbot> ACTION-2676 -- Chris Lilley to fix the 1.1 second edition
    wording for values that are accessed where no attribute was
    provided,
    [24]http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMO
    verview and have it be NaN or 0 with unknown unit depending on the
    type of domobject -- due 2009-10-06 -- OPEN

      [24]  
http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMOverview

    <trackbot> [25]http://www.w3.org/Graphics/SVG/WG/track/actions/2676

      [25] http://www.w3.org/Graphics/SVG/WG/track/actions/2676

    rrs-agent, make minutes

Summary of Action Items

    [NEW] ACTION: CL to fix the 1.1 second edition wording for values
    that are accessed where no attribute was provided,
    [26]http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMO
    verview and have it be NaN or 0 with unknown unit depending on the
    type of domobject [recorded in
    [27]http://www.w3.org/2009/09/28-svg-minutes.html#action03]
    [NEW] ACTION: fix the 1.1 second edition wording for values that are
    accessed where no attribute was provided,
    [28]http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMO
    verview and have it be NaN or 0 with unknown unit depending on the
    type of domobject [recorded in
    [29]http://www.w3.org/2009/09/28-svg-minutes.html#action02]
    [NEW] ACTION: heycam to summarize the html5 conclusions from these
    minutes and send them to the HTML WG [recorded in
    [30]http://www.w3.org/2009/09/28-svg-minutes.html#action01]

      [26]  
http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMOverview
      [28]  
http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMOverview

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [31]scribe.perl version 1.135
     ([32]CVS log)
     $Date: 2009/09/29 02:22:55 $
      _________________________________________________________

      [31] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [32] 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 [33]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

      [33] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/split out spec says/split out spec says the host language
defines/
Succeeded: s/it'd/marking the canvas "safe" would/
Succeeded: s/initial values/lacuna values/
Found Scribe: Erik
Found ScribeNick: ed
Present: Anthony Cameron Chris Doug Erik Jonathan
Found Date: 28 Sep 2009
Guessing minutes URL: [34]http://www.w3.org/2009/09/28-svg-minutes.html
People with action items: cl fix heycam

      [34] http://www.w3.org/2009/09/28-svg-minutes.html

    End of [35]scribe.perl diagnostic output]

      [35] 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 Tuesday, 29 September 2009 02:26:22 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:43 GMT