See also: IRC log
<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> 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
CM: looked at html5 wrt svg
<heycam> 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> 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> 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 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].
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> 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
<heycam> http://www.w3.org/mid/20090928065405.GC25086@wok.mcc.id.au
ED: agree
<heycam> 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
http://www.w3.org/TR/SVG11/painting.html#StrokeProperties
CM: returning to 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> 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, http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMOverview and have it be NaN or 0 with unknown unit depending on the type of domobject [recorded in http://www.w3.org/2009/09/28-svg-minutes.html#action02]
<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, http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMOverview and have it be NaN or 0 with unknown unit depending on the type of domobject [recorded in http://www.w3.org/2009/09/28-svg-minutes.html#action03]
<trackbot> Created ACTION-2676 - Fix the 1.1 second edition wording for values that are accessed where no attribute was provided, http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMOverview and have it be NaN or 0 with unknown unit depending on the type of domobject [on Chris Lilley - due 2009-10-06].
<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, http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMOverview and have it be NaN or 0 with unknown unit depending on the type of domobject -- due 2009-10-06 -- OPEN
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2676
rrs-agent, make minutes
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at 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: http://www.w3.org/2009/09/28-svg-minutes.html People with action items: cl fix heycam[End of scribe.perl diagnostic output]