<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

SVG in HTML5

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

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