00:08:06 <shepazu> http://www.flickr.com/search/?q=manhattanhenge
00:18:18 <shepazu> http://www.epson.co.jp/e/newsroom/manage_news/manage_090430.htm
00:47:29 <shepazu> http://www.amantepizza.com/menu.html
01:04:55 <heycam> whole wheat medium greek
01:04:56 <ChrisL> small wholewheat amore roma with extra anchovies
01:06:42 <ed> small regular Proscuitto Italiano Pizza
01:21:28 <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
01:22:30 <ed> maybe better wait until AG does the xslt update though
02:07:41 <Zakim> Zakim has left #svg
02:34:07 <heycam> close action-2550
02:34:07 <trackbot> ACTION-2550 Incorporate icc grammar closed
03:32:02 <ed> ed has joined #svg
03:32:54 <ed> ed has joined #svg
04:37:44 <shepazu> http://www.wolaver.org/animals/giraffe&squirrel.jpg
04:43:05 <heycam> action: doug to republish the 1.1 errata
04:43:05 <trackbot> Created ACTION-2611 - Republish the 1.1 errata [on Doug Schepers - due 2009-06-17].
04:45:05 <shepazu> http://www.wolaver.org/animals/baby_elephant.jpg
04:53:50 <heycam> close action-2551
04:53:50 <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
05:14:07 <heycam> close action-2002
05:14:07 <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
05:25:28 <anthony> heycam, do you think it's worth preserving the baseProfile and version in the SVG tests?
05:26:46 <heycam> hmm
05:26:53 <heycam> i don't know if any tests have special values for those
05:26:53 <anthony> so maybe version
05:26:55 <heycam> i doubt it though
05:27:04 <anthony> like in F11 version="1.1
05:27:05 <heycam> probably safe either way
05:27:14 <anthony> right
05:27:18 <anthony> I might exclude baseProfile
05:32:01 <heycam> http://dev.w3.org/SVG/profiles/1.1F2/publish/changes.html
05:32:03 <heycam> anthony, ok
05:32:12 <heycam> (that url was for doug)
05:32:21 <heycam> exclude how?
05:32:24 <heycam> in that xpath expression?
05:32:32 <heycam> maybe baseProfile should be kept as is
05:32:37 <anthony> ok
05:32:40 <heycam> since some tests are for tiny, some for basic, some for full
05:32:46 <heycam> but i guess all the versions should be 1.1
13:38:51 <RRSAgent> RRSAgent has joined #svg
13:38:51 <RRSAgent> logging to http://www.w3.org/2009/06/10-svg-irc
13:38:53 <trackbot> RRSAgent, make logs public
13:38:53 <Zakim> Zakim has joined #svg
13:38:55 <trackbot> Zakim, this will be GA_SVGWG
13:38:55 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
13:38:56 <trackbot> Meeting: SVG Working Group Teleconference
13:38:56 <trackbot> Date: 10 June 2009
13:39:03 <ed> Topic: Errata changes
13:40:50 <jwatt> I'd propose changing:
13:40:52 <jwatt> "Note that the specification of a <number> is different for CSS2 property values than for XML attribute values."
13:40:53 <jwatt> to:
13:40:56 <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)."
13:43:35 <rubys1> rubys1 has joined #svg
13:43:54 <ChrisL> ChrisL has joined #svg
13:44:23 <ChrisL> rrsagent, here
13:44:23 <RRSAgent> See http://www.w3.org/2009/06/10-svg-irc#T13-44-23
13:44:25 <jwatt> http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#DataTypeLength
13:47:20 <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)."
13:49:58 <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)."
13:51:39 <ed_work> ed_work has joined #svg
13:52:38 <ChrisL> or drop 'presentation' from second sentence
13:53:07 <jwatt> so
13:53:40 <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)."
13:58:59 <ed> ACTION-2599?
13:58:59 <trackbot> ACTION-2599 -- Erik Dahlström to fix ISSUE-2046 to allow negative startOffset in 1.1 -- due 2009-06-10 -- OPEN
13:58:59 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2599
15:12:37 <heycam> Chair: Cameron
15:12:58 <ChrisL> ScribeNick: ChrisL
15:13:08 <ChrisL> Topic: 1.1SE publication
15:13:41 <ChrisL> cl: we cannot add new functionality (new elements attributes etc). We ust be careful whether something is a substantive change
15:14:01 <ChrisL> ... we need to show implementability of clarified areas (test suite report is good)
15:14:37 <ChrisL> ... larger issues that would require substantive new functionality should be moved to SVG Core, from SVG 1.1, in the tracker
15:17:23 <ChrisL> ... i also thing the RNG should be published as a separate document
15:20:12 <ChrisL> Topic: Integration spec
15:20:27 <rubys> rubys has joined #svg
15:20:41 <ChrisL> http://dev.w3.org/SVG/modules/integration/master/SVGIntegration.html
15:22:23 <ChrisL> Abstract
15:22:23 <ChrisL> 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
15:23:41 <ChrisL> change <link rel="stylesheet" type="text/css" href="style/svg-style.css"/>
15:23:56 <ChrisL> to <link rel="stylesheet" type="text/css" href="../publish/style/svg-style.css"/>
15:27:18 <ChrisL> (demo of widgets, including svg widgets)
15:28:45 <ChrisL> how to reference script in the icon, but still have animation
15:29:22 <ChrisL> ed: how css backgrounds that are svg are rendered is not clear (percentages, etc)
15:29:40 <ChrisL> ... fantasia said this si something svg should specify
15:29:48 <ChrisL> cm: border-image that is svg is another one
15:30:08 <ChrisL> cl: want to avoid premature rasterisation, especially if its then going to be rescaled
15:32:51 <heycam> list bullet images too?
15:33:47 <ChrisL> ds: so some issues have come up with css and svg, its being implemented now
15:34:09 <ChrisL> sr: why would image in css background and in html img behave differently
15:34:18 <ChrisL> ed: up for discussion
15:38:37 <ChrisL> (we conclude that interactivity and (user directed) link traversal are the same)
15:40:12 <ChrisL> cm: for immediate mode, how does that work?
15:40:24 <ChrisL> sr: for mobile, bandwidth is more precious than meory
15:40:34 <ChrisL> ed: and latency is also precious
15:40:58 <Zakim> Zakim has left #svg
15:41:57 <ChrisL> cl: if there is no interaction, scripting, or animation its not externally observable whether the dom has been retained or not
15:42:22 <ChrisL> (discussion on whether ther ewill be low-end mobile devices as well as powerful ones)
15:42:32 <Zakim> Zakim has joined #svg
15:42:52 <ChrisL> zakim, remind us in 7 hours to go home
15:42:52 <Zakim> ok, ChrisL
15:43:18 <ChrisL> sr: canvas requires script
15:43:49 <ChrisL> ds: could stil usefully have an svg that uses a dom, is rendered, and then only the raster is kept
15:44:13 <ChrisL> ... as we can't anticipate all the possible use cases, we list them all
15:46:05 <ChrisL> cl: vodaphone uses both animated and static modes, and switches between them dynamically. this saves needless cpu
15:46:35 <ChrisL> ds: performance benchmarking suite, they found that below a certain size raster is better than vector, they said
15:47:12 <ChrisL> ed: if rasters are small its easy to cache
15:48:16 <ChrisL> ds: happy to fold in some modes, just wanted to give other groups the options
15:48:26 <ChrisL> (discussion of modes used by CDF)
15:49:44 <ChrisL> (discussion of CDF)
15:51:56 <ChrisL> CDF test suite  http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/index.xhtml
15:52:10 <ChrisL> ds: dynamic mode is the default for svg
15:52:38 <ChrisL> ... animated mode has no user interaction
15:53:05 <ChrisL> ... secure animated mode also enforces no external references, brought up by Apple, seen as a security concern
15:54:12 <ChrisL> (discussion of security exploits)
15:54:34 <ChrisL> rs: not clear that this is doing anything more than showing a resource the user has access to directly anyway
15:55:12 <ChrisL> cm: (iframe and contentDocument discussion) ... so don't see the need for the secure and insecure modes.
15:55:50 <ChrisL> ds: secure animated mode indicates the intent
15:56:58 <ChrisL> rs: example with email client, images don't show to prevent spammers knowing the email was read
15:57:26 <ChrisL> 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
15:58:28 <ChrisL> jw: thunderbird does not display external images by default
15:58:41 <ChrisL> ... no special html mode, just an implementation decision
15:59:36 <ChrisL> cl: probably setting prefs differently for email and for html browsing
16:00:20 <ChrisL> jw; another one about certificate warnings, wanted to use stripped-down svg and asked us to specify it
16:00:26 <ChrisL> ... covered by this spec
16:01:36 <ChrisL> rs: initially thought there were too many options but we are starting to see the realistic use cases for them....
16:02:05 <ChrisL> ds: probably should give sample use cases for each one. already recommend certain options
16:02:43 <ChrisL> ds: this spec is intended primarily for other spec writers, not for end users
16:03:31 <ChrisL> cm: batik has bot full dynamic and linking-but-no-other-interaction modes
16:03:54 <ChrisL> s/bot/both/
16:04:16 <ChrisL> cm: immediate mode, renderng an svg to canvas then discarding ....
16:05:05 <ChrisL> ds: extending svg section is pulled from svg 1.1
16:06:04 <ChrisL> cl: (explains background for the extensibility rules, asked for my MPEG)
16:06:45 <ChrisL> ds: same for ODF for example, could also use this section
16:07:31 <ChrisL> ds: yesterday was told that ODF is starting to make doug a liaison with ODF to harmonise
16:08:15 <ChrisL> jw: good to know wat draw can do that svg cannot
16:08:53 <ChrisL> ds: they have a connector, for example
16:09:42 <ChrisL> cl: is this a visual connector, or a triple-like 'x relates to y' connector?
16:10:07 <ChrisL> ds (describes aria roles as applied to svg)
16:15:06 <ChrisL> (discussion of auto connectors vs metadata-decorated general graphics)
16:15:41 <ChrisL> cm: want to avoid automatic routing
16:16:48 <ChrisL> ... facility to write that in script is handy
16:17:05 <heycam> ScribeNick: heycam
16:17:30 <heycam> JW: i'm skeptical about having an attribute on a path to say that these two objects are connected
16:18:53 <heycam> DS: one thing an authoring tool could do with role="connector" is that it can realise that the path is acting as a connector
16:19:09 <heycam> ... they might give it a class or something to roundtrip it
16:19:30 <heycam> ... i'm more concerned about a screen reader
16:19:33 <heycam> JW: for accessibility?
16:19:35 <heycam> DS: yes
16:19:54 <heycam> ... if something is known to be a connector, there's an implicit path to navigate around the document
16:20:05 <heycam> JW: i can see some utility for accessibility
16:20:31 <heycam> DS: also a script might look at all the elements with role="connector", maybe use XBL2 to create behaviours on that
16:20:35 <heycam> ... or just plain script
16:21:17 <heycam> JW: a good starting point would be looking at what inkscape actually does
16:21:24 <heycam> ... and looking at what ODF does, and other formats and tools
16:21:35 <heycam> ... that do linking & connectors
16:25:08 <heycam> DS: we're planning on adding a <point> element
16:25:16 <heycam> ... you could have those as children of <rect> to act as connection points
16:26:29 <ChrisL> http://www.graphviz.org/
16:28:07 <heycam> CM: i'm warying of specifying a connector routing algorithm
16:28:14 <heycam> DS: if svg did this for people, people would use svg more
16:28:26 <heycam> ... script library might solve that
16:28:37 <heycam> ... if we're trying to solve real world problems, this is a big use case
16:29:22 <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
16:29:53 <heycam> ... 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
16:30:22 <heycam> ... we can ask cameron's colleague on how to do this in svg
16:30:32 <heycam> ... or in some other spec
16:30:43 <heycam> ... if we had interest from implementors
16:31:16 <heycam> ... authors would rather just have a solution for doing graphs and connecting things built in to the platform
16:31:25 <heycam> CM: maybe porting his c++ library to js would be a good solution
16:32:05 <ed> http://ajaxian.com/archives/ample-sdk-browser-in-a-browser
17:55:53 <rubys> rubys has joined #svg
17:59:28 <ChrisL> scribenick: chrisl
17:59:37 <ChrisL> topic: svg in html
18:00:29 <heycam> CM: happy with how the syntax end up?
18:00:31 <heycam> CL: how did it end up?
18:00:44 <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
18:00:49 <heycam> ... e.g. take off xml decl and dtds off
18:01:16 <heycam> ... it would accept other things as well, i imagine
18:01:16 <heycam> ... if that's still true i'm mostly satisfied
18:01:29 <heycam> SR: if authoring tool choose to use a different default namespace then it wouldn't work
18:01:35 <heycam> ... most tools use default svg namespace
18:01:48 <heycam> ... only exception i know of is that the w3c profile of svg in xhtml
18:01:58 <heycam> s/that //
18:02:04 <heycam> CL: that spec says nothing about rendering or anything, just a demonstration of modular dtds combining together
18:02:22 <heycam> ... the svg 1.1 dtd has the same thing, the dtd allows you to declare a prefix
18:02:22 <heycam> ... but nobody does
18:02:38 <heycam> SR: the only way to have valid XHTML+SVG+MathML profile is to use prefixes
18:02:52 <heycam> CL: i wouldn't worry about that, it's just a demonstration that you could do that with dtds
18:03:17 <heycam> SR: i've seen some people change their sites because of it
18:03:27 <heycam> ... i'm happy with svg prefixes not working in text/html
18:03:31 <heycam> CM: that's how it is at the moment
18:03:48 <heycam> CL: i don't want to see authoring tools change to have "save as text/html compatible svg"
18:03:56 <heycam> SR: adobe like to put entity definitions in their output
18:04:15 <heycam> DS: i don't have a problem with an xml prolog and doctype having to be stripped
18:04:20 <heycam> ... but what if i don't strip them?
18:04:33 <heycam> CL: should be reasonable defined behaviour
18:05:16 <heycam> ED: that would be the same if you put a DTD in the middle of document
18:05:16 <heycam> CM: think <!DOCTYPE ...> interpreted as a comment
18:05:28 <heycam> CL: defining entities and so on won't work
18:05:59 <heycam> ... use xhtml5 if you want to do that
18:06:21 <ed> s/document/HTML-only document/
18:06:37 <ChrisL> s/work/work, which is fine/
18:06:43 <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
18:07:16 <heycam> ... we assumed that an inline doctype is treated the same as in html, but it's hard to read the parsing to determine these things
18:07:16 <heycam> s/parsing/parsing sections/
18:07:20 <heycam> ... few high level overviews of the concepts involved
18:07:30 <heycam> SR: i've heard that before
18:07:36 <heycam> ... haven't had anyone volunteer to fix it though
18:07:50 <heycam> CL: common in w3c for someone to propose wording
18:08:10 <heycam> ... usually that's because they found specific bits confusing, not "the whole document is confusingly written"
18:14:23 <heycam> DS: in the table of contents there's a section on svg
18:14:46 <heycam> ... but it would be useful to have some prefatory/introductory material that says that svg is basically supported in text/html
18:14:57 <shepazu> http://www.w3.org/TR/html5/the-canvas-element.html#svg
18:20:04 <ChrisL> scribenick: chrisl
18:20:21 <ChrisL> sr: title in html is effectively a cdata marked section
18:21:18 <ChrisL> cm: seems like the parsing on html5 for svg is headed ina  good direction, sensible people are commenting
18:22:47 <ChrisL> ... cdata marked sections
18:23:39 <ChrisL> sr: my pages are xhtml5 and have inline svg, but by using cdata I can make some text at least show up in IE
18:23:59 <ChrisL> ... my content shows up mostly intact in IE
18:25:03 <ChrisL> cm: so both solutions for cdata would work. one makes script that has no cdata break
18:25:47 <ChrisL> ... < symbols are rare in CSS (not so for > )
18:25:58 <ChrisL> cm: so, ok with that
18:26:30 <ChrisL> ds: where does it say in html5 about dom interfaces in svg?
18:30:07 <ChrisL> cl: there is no indication that svg and mathml are anything other than examples
18:30:22 <ChrisL> 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.)
18:31:08 <ChrisL> ds: if you are defining a platform then it all needs to be defined, not some parts merely illustrative examples
18:31:54 <ChrisL> ds: would have been better if the parsing and the rest of the spec was separate as many suggested
18:32:53 <ChrisL> 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
18:33:58 <ChrisL> cm: are the interfaces required?
18:35:30 <ChrisL> 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:"
18:37:20 <ChrisL> ds: looks like an informative not, document object of svg and html
18:38:34 <ChrisL> ds: quotes "For example, if an HTML implementation also supports SVG, then the Document object implements both HTMLDocument and SVGDocument." which is non-normative
18:38:59 <ChrisL> 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]
18:40:46 <ChrisL> Web browsers that support HTML must process documents labeled as text/html as described in this specification, so that users can interact with them.
18:42:38 <ChrisL> 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."
18:43:06 <ChrisL> and the dsame for mathml
18:43:22 <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."
18:43:56 <shepazu> I'd prefer stronger wording in 2.2, indicating that SVG should/must be supported
18:44:20 <ChrisL> cm: not finding a requirement to implement the svg interfaces if svg is supported
18:45:44 <shepazu> there's a lot of ambiguity here... it needs a clear statement about SVG and MathML being supported, and likewise the interfaces
18:46:34 <ChrisL> rs: sounds like the stronger statement would preclude an implementor saying they support html5 if they dont support scripting, svg, mathml
18:46:54 <ChrisL> ... where does it say this statement in your blog?
18:47:52 <ChrisL> 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
18:48:20 <ChrisL> rs: i thought that was the intent. Typically ian is very deliberate, so if the spec says svg is optional thats probably ians intent
18:50:23 <ChrisL> ds: so how do you think that will fly, if the svg wg wants for it to be non optional 
18:50:39 <ChrisL> ds; want it asdded to webb rowsers and other interactive user agents
18:50:57 <ChrisL> rs: should specify a profile
18:51:01 <ChrisL> ds: svg 1.1, then
18:52:30 <ChrisL> rs: a significant goal is interop between browsers, and making such a major part optional harms interop
18:52:36 <ChrisL> (general agreement)
18:53:26 <ChrisL> ds: png is a required format for example
18:55:27 <ChrisL> ed: there is a requirement to make PNGs (as a data url) not to render them
18:55:45 <ed> that's canvas.toDataURL
18:56:38 <ChrisL> rs: was not aware that pdf could be used on an img tag
18:57:33 <ed> http://dev.w3.org/html5/spec/
18:57:59 <rubys> http://dev.w3.org/html5/spec/Overview.html#cdata-section-state
19:06:21 <ChrisL> cl: video used to require ogg theora
19:06:28 <ChrisL> ds: some people demanded it be removed
19:06:45 <ChrisL> ed: only external format that is required so far
19:07:48 <ChrisL> rrsagent, here
19:07:48 <RRSAgent> See http://www.w3.org/2009/06/10-svg-irc#T19-07-48
19:08:04 <ed> s/only/audio with WAVE container encoded as PCM is the only/
19:20:58 <ChrisL> sr: acid3 has some svg tests, not very much
19:21:07 <ChrisL> ed: yes, a few SVG dom tests
19:21:53 <ChrisL> sr: consistent errr handling in htl5 gives interop. same for handling svg. needs to be a minimal list or a concentric circle set of conformance classes
19:22:10 <ChrisL> c: easier if there is a specific conformance class
19:22:28 <ChrisL> s/c:/cm:/
19:25:36 <ChrisL> cm: html doesnt require svg interfaces to be implemented on svg nodes, not so much of a problem since svg requires it
19:25:56 <ChrisL> ... mathml has a dom too
19:26:56 <ChrisL> s/htl5/html5/
19:27:36 <heycam> s/.../ds:/
19:28:30 <ed> ACTION: jwatt to find out about svg integration in html5
19:28:30 <trackbot> Created ACTION-2612 - Find out about svg integration in html5 [on Jonathan Watt - due 2009-06-17].
20:31:37 <ChrisL> ChrisL has joined #svg
20:38:48 <ChrisL> action cameron to find nathan hurst's paper on text flowing into growing shapes and send copy to liam
20:38:48 <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].
20:38:59 <ChrisL> action-2613
20:39:07 <ChrisL> action-2613?
20:39:07 <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
20:39:07 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2613
21:24:38 <heycam> close ACTION-2552 (edit)
21:24:40 <heycam> close ACTION-2552
21:24:41 <trackbot> ACTION-2552 Get filters module building closed
21:39:44 <rubys1> rubys1 has joined #svg
21:41:16 <jwatt> ScribeNick: jwatt
21:41:54 <jwatt> Topic: Filter module
21:42:27 <jwatt> ED: filters module now building
21:43:10 <jwatt> ...except IDL
21:43:26 <jwatt> ...need move everything over from 1.1 2nd edition draft
21:43:48 <jwatt> ...to integrate filters applied to HTML stuff that roc sent in
21:44:27 <ChrisL> <xsl:attribute name="xmlns:xsl" namespace="whatever">http://www.w3.org/1999/XSL/Transform</xsl:attribute>
21:44:27 <ChrisL> it will not result in a namespace declaration being output.
21:44:41 <ed> http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html
21:44:50 <ed> http://lists.w3.org/Archives/Public/www-svg/2008Sep/0041.html
21:45:10 <jwatt> ...we should discuss that proposal
21:46:03 <jwatt> ...as I understand, Mozilla doesn't implement some of the filter inputs e.g. BackgroundImage
21:46:08 <jwatt> JW: correct
21:46:31 <jwatt> ED: I'm wondering if we should define what those mean in HTML terms
21:47:25 <jwatt> ...same as for SVG?
21:47:31 <jwatt> JW: I was assuming so
21:48:42 <jwatt> CM: what if you have filterUnits="userSpaceOnUse"?
21:48:54 <jwatt> ED: proposal says bounding client rect
21:49:37 <jwatt> ...what capabilities does enable-background give us?
21:49:45 <jwatt> ...is it needed?
21:50:23 <ed> http://www.w3.org/TR/SVG11/filters.html#AccessingBackgroundImage
21:50:38 <jwatt> AG: let me get a pointer to the SVG Open 2005 paper that explains what enable-background is useful for
21:51:08 <ed> s/give us/give us in the HTML context/
21:51:27 <anthony> http://www.svgopen.org/2005/papers/abstractsvgopen/index.html
21:52:01 <anthony> http://www.svgopen.org/2005/papers/abstractsvgopen/index.html#S9.
21:54:27 <jwatt> ED: the draft from roc doesn't say anything about enable-background
21:55:32 <jwatt> 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
21:55:34 <ChrisL> EB has got a bad rep because of Illustrator slapping it on every document. but it certainly does have its uses
21:58:31 <jwatt> 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
21:59:36 <jwatt> CL: HTML is quite different to the SVG painter's model, since it has z-index, stacking contexts, absolutely positioned content,...
22:00:02 <jwatt> ...that makes it a much harder problem for HTML, so I can understand why he left that bit out
22:00:45 <jwatt> AG: you could just take whatever's written to the device, and use that as the background when EB is set to 'accumulate'
22:01:09 <jwatt> ED: so you're suggesting not to allow the 'new' value?
22:01:12 <ChrisL> Present: Doug_Schepers, Erik_Dahlstrom, Cameron_McCormack, Jonathan_Watt, Sam_Ruby, Chris_Lilley
22:01:21 <jwatt> AG: that just gives you a blank buffer of a set size
22:01:57 <jwatt> ...or I think that's what it should do
22:02:36 <rubys1> rubys1 has joined #svg
22:07:35 <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?
22:07:53 <ed> ...you need to figure out how to go back in the "rendering tree" to generate it
22:08:01 <ed> ...not as easy as in svg
22:08:12 <heycam> close ACTION-2613
22:08:12 <trackbot> ACTION-2613 Find nathan hurst's paper on text flowing into growing shapes and send copy to liam closed
22:09:16 <jwatt> 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
22:09:54 <jwatt> ...so I suggest to clearly mark it as something we want feedback on on how it should work, and list some of the issues
22:10:08 <jwatt> ...but I don't think there's a problem with 'accumulate'
22:10:19 <jwatt> AG: it depends which model you use
22:11:12 <rubys1> rubys1 has left #svg
22:11:26 <jwatt> ...if using the compositing model it's not so simple because...
22:11:59 <jwatt> ...the reason compositing is done that way is to produce the same results as Abobe did in their model
22:12:40 <jwatt> ...when you do the compositing with filters you get the background twice
22:13:28 <jwatt> ED: it might be possible to define for HTML that it doesn't draw anything but the background image
22:13:36 <jwatt> AG: that might work
22:14:27 <jwatt> ED: we could try that and see if it works
22:14:58 <jwatt> AG: for 'accumulate' you're not rendering to the device anyway
22:16:53 <ChrisL2> ChrisL2 has joined #svg
22:17:10 <ChrisL2> so, save a pristine copy of the background, continue accumulating onto it, then subtract out the original background again
22:17:14 <ChrisL2> rrsagent, here
22:17:14 <RRSAgent> See http://www.w3.org/2009/06/10-svg-irc#T22-17-14
22:18:57 <jwatt> ED: and there's FillPaint and StrokePaint
22:19:48 <jwatt> CM: I thought we might be able to use pseudo elements to set fill and stroke on them
22:20:19 <heycam> like div::background { fill: blah; stroke: blah; }
22:20:31 <heycam> with initial values for fill and stroke that mean they get their values from color/background properties
22:21:07 <jwatt> CM: are you allowed to have different initial values for different elements
22:21:17 <jwatt> s/elements/elements?/
22:22:34 <jwatt> ED: making fill and stroke apply could class a bit with the special CSS syntax for gradients implemented by webkit
22:22:45 <jwatt> s/class/clash/
22:22:46 <ed> s/class/clash/
22:24:30 <jwatt> CL: you could also have BorderPaint, ContentPaint,...
22:24:56 <jwatt> ...giving them that might be better
22:25:43 <ChrisL2> instread of trying to map css boxmodel concepts to fill and stroke, give them direct access to their concepts as paint
22:26:26 <jwatt> CL: we should put that is as a suggestion in an editorial note
22:26:38 <jwatt> s/that is/that in/
22:27:58 <ChrisL2> file:///D:/WWW/dev/SVG/modules/filters/master/SVGFilter.html#FillPaint
22:28:52 <ChrisL2> er, sorry http://dev.w3.org/SVG/modules/filters/master/SVGFilter.html#FillPaint
22:29:40 <jwatt> ED: another thing I'm not clear on is how the 'filter' property would be applied to the HTML compositing model
22:30:15 <jwatt> ...basically in what order other type of operations are applied - where 'filter' fits in with mask and clipping for example
22:30:44 <jwatt> ...say you had an 'opacity' property set for example, that would be applied after the 'filter' property I guess
22:30:49 <jwatt> ...that's what it says here
22:31:19 <jwatt> ...I guess clipping is the one thing I'm most concerned about
22:32:04 <jwatt> ...SVG spec says clipping happens after filtering
22:32:17 <jwatt> ...seems reasonable to have the same for HTML
22:32:34 <jwatt> JW: desirable for consistancy
22:34:13 <jwatt> 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
22:34:59 <jwatt> ED: I'm about to commit some tests to the 2nd Ed test suite
22:35:19 <jwatt> ED: Antony, it would be good to have any enable-background tests you have
22:36:12 <jwatt> AG: I'll send over anything I have that would be useful
22:38:20 <ChrisL2> rrsagent, make minutes
22:38:20 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/10-svg-minutes.html ChrisL2
22:42:52 <Zakim> ChrisL, you asked to be reminded at this time to go home
22:54:46 <Zakim> Zakim has left #svg