- 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>
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:20 UTC