SVG Working Group Teleconference -- 10 Jun 2009

<shepazu> http://www.flickr.com/search/?q=manhattanhenge

<shepazu> http://www.epson.co.jp/e/newsroom/manage_news/manage_090430.htm

<shepazu> 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: http://dev.w3.org/SVG/profiles/1.1F2/test/svg/filters-displace-02-f.svg if you could add some pass criteria etc I could review that test

<ed> maybe better wait until AG does the xslt update though

<heycam> close action-2550

<trackbot> ACTION-2550 Incorporate icc grammar closed

<shepazu> http://www.wolaver.org/animals/giraffe&squirrel.jpg

<heycam> ACTION: doug to republish the 1.1 errata [recorded in http://www.w3.org/2009/06/10-svg-minutes.html#action01]

<trackbot> Created ACTION-2611 - Republish the 1.1 errata [on Doug Schepers - due 2009-06-17].

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

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

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

<jwatt> http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#DataTypeLength

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

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

http://dev.w3.org/SVG/modules/integration/master/SVGIntegration.html

Abstract

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 des

change <link rel="stylesheet" type="text/css" href="style/svg-style.css"/>

to <link rel="stylesheet" type="text/css" href="../publish/style/svg-style.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 differently

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 all

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

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 modes
... 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 MPEG)

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' connector?

ds (describes aria roles as applied to svg)

(discussion of auto connectors vs metadata-decorated general graphics)

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

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

<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> 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 text/html

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

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

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 "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. [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 interfaces

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

<rubys> 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 http://www.w3.org/2009/06/10-svg-minutes.html#action02]

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

action-2613

action-2613?

<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> 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" namespace="whatever">http://www.w3.org/1999/XSL/Transform</xsl:attribute>

<ChrisL> it will not result in a namespace declaration being output.

<ed> http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html

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

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

<anthony> http://www.svgopen.org/2005/papers/abstractsvgopen/index.html

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

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 twice

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 again

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

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> file:///D:/WWW/dev/SVG/modules/filters/master/SVGFilter.html#FillPaint

<ChrisL2> er, sorry http://dev.w3.org/SVG/modules/filters/master/SVGFilter.html#FillPaint

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

AG: I'll send over anything I have that would be useful

- DRAFT -

SVG Working Group Teleconference

10 Jun 2009

Attendees

Contents

Errata changes

1.1SE publication

Integration spec

svg in html

Filter module

Summary of Action Items

Scribe.perl diagnostic output