06:30:04 <RRSAgent> RRSAgent has joined #svg
06:30:04 <RRSAgent> logging to http://www.w3.org/2009/04/29-svg-irc
06:30:06 <trackbot> RRSAgent, make logs public
06:30:08 <trackbot> Zakim, this will be GA_SVGWG
06:30:09 <Zakim> ok, trackbot; I see GA_SVGWG()2:30AM scheduled to start now
06:30:09 <trackbot> Meeting: SVG Working Group Teleconference
06:30:09 <trackbot> Date: 29 April 2009
06:30:33 <Zakim> GA_SVGWG()2:30AM has now started
06:30:33 <Zakim> +Shepazu
06:30:50 <Zakim> +??P0
06:30:51 <Zakim> -??P0
06:30:51 <Zakim> +??P0
06:31:00 <anthony> Zakim, ??P is me
06:31:00 <Zakim> +anthony; got it
06:31:09 <Zakim> +??P1
06:31:12 <heycam> Zakim, ??P1 is me
06:31:12 <Zakim> +heycam; got it
06:31:42 <Zakim> +??P2
06:31:50 <ed> Zakim, ??P2 is me
06:31:50 <Zakim> +ed; got it
06:33:45 <ChrisL> ChrisL has joined #svg
06:34:15 <heycam> Scribe: Cameron
06:34:19 <heycam> ScribeNick: heycam
06:34:22 <heycam> Chair: Erik
06:34:24 <ed> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0080.html
06:34:58 <heycam> Topic: Publication status (compositing, ref)
06:35:07 <heycam> DS: going slowly
06:35:14 <heycam> ... cameron made some progress on the build scripts
06:35:26 <heycam> ... did you apply that to template too?
06:35:29 <Zakim> +ChrisL
06:35:30 <heycam> CM: no i didn't yet
06:35:55 <heycam> DS: cameron manually put build scripts in for the integration spec, the params spec and the compositing spec
06:36:13 <heycam> ... right now i'm in the of making the params spec have "params"
06:36:22 <ChrisL> q+ to ask about specs with two documents
06:36:46 <heycam> ED: regarding that, is it in the spec already that you could use params for references inside svg?  for example for 'use' elements?
06:37:08 <heycam> DS: we did mention that last telcon, but didn't really discuss it
06:37:43 <heycam> ... so that syntax for a url is   param(http://example.org/something#frag?query)
06:38:06 <heycam> s/#frag?query/?query#frag/
06:38:43 <heycam> ... a use element is just referenced using a uri, don't see why the query string shouldn't apply
06:38:52 <heycam> ... but it would apply at the global level
06:39:12 <heycam> ... we could say that the shadow tree of the 'use' element is a special case, and has its own params interface
06:39:18 <heycam> CL: so each instance has its own params
06:39:56 <heycam> CM: if you do <use xlink:href="?something#else">, then that's going to fetch another resource
06:40:29 <heycam> DS: we could change that in the context for 'use' elements
06:40:35 <heycam> CM: i'd be wary of doing that
06:40:46 <heycam> ED: we could allow <param> elements as children of <use>, that could fix that
06:40:55 <heycam> DS: so svg doesn't have a <param> element
06:41:07 <heycam> ... we can't take advantage of that, except for uris
06:41:16 <heycam> ... we could add a <param> element or equivalent
06:41:45 <heycam> ... <param> in html4 is quite elaborate
06:42:12 <heycam> CM: it is simpler in html5, just name/value attributes and no children
06:42:32 <shepazu> http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html#h-13.3.2
06:43:24 <heycam> DS: if we did do something like this, i'd take the html5 <param>
06:43:47 <heycam> CL: the whole reason for param in the first place was to extend things without changing the dtd
06:44:07 <heycam> ... i've never seen this other stuff, nor seen it used
06:44:27 <heycam> DS: part of me says, yeah it'd be great to just use <param>
06:44:40 <heycam> ... then there might be complaints about namespace for parsing in html, etc.
06:44:52 <heycam> ED: so in html you'd get HTML <param> elements
06:45:01 <heycam> ... part of me thinks it would be nice if it were the same
06:45:19 <heycam> DS: same question applies to the <link> element
06:45:26 <heycam> ... it'd be useful for authors to be able to use <link> in svg
06:45:52 <heycam> ... don't know if it would be difficult to have the namespace of the Element in the dom to differ, depending on where it lives
06:46:24 <heycam> ACTION: Doug to ask HTML WG what they think about parsing <param> and <link> in SVG
06:46:24 <trackbot> Created ACTION-2534 - Ask HTML WG what they think about parsing <param> and <link> in SVG [on Doug Schepers - due 2009-05-06].
06:46:47 <heycam> DS: i think it would be nice for us to have a <param> thing
06:46:55 <heycam> ... a child of a <use>, or any referencing element
06:47:06 <heycam> CM: i'd love to have <param> child of <use>
06:47:42 <shepazu> agenda+ CSS3.1
06:47:44 <heycam> ED: so when would the params spec be ready for publication?
06:48:09 <heycam> DS: if i can get everything pubruled tonight, i believe we'll be publishing on thursday, for both params and compositing
06:48:19 <ChrisL> q?
06:48:58 <ChrisL> ack Ch
06:48:58 <Zakim> ChrisL, you wanted to ask about specs with two documents
06:49:02 <heycam> Topic: CSS3 Values and Units
06:53:04 <shepazu> http://www.w3.org/TR/css3-values/
06:53:33 <heycam> DS: last time we were talking about the <ref> element, cameron suggested it might not be necessary to have that element
06:53:41 <heycam> ... simpler just to do a param() value inside attributes
06:53:50 <heycam> ... this was the first thing we talked about at tpac
06:54:11 <heycam> ... then i thought what about fallback values, etc.
06:54:28 <heycam> ... and it seemed like a paint server, and for text, like <text> referenceable by a <tref>
06:54:51 <heycam> ... i'd forgotten that if you use the url() syntax, you can have a second fallback value (for <color> and <paint>)
06:54:59 <heycam> ... that's a mechanism that already exists from css, and it simplifies things
06:55:13 <heycam> ... cameron suggested param() would have two values, one the parameter, second the fallback value
06:55:20 <heycam> ... but we could use that fallback syntax similar to <paint>
06:55:41 <heycam> ... we started talking about this in the context of other things we want to do, in particular allowing relative values
06:55:46 <heycam> ... e.g. 100% minus 5px
06:55:58 <heycam> ... and we realised that there's calc() in css3-values
06:56:08 <heycam> ... not sure it's implemented, but it's pretty well defined
06:56:23 <heycam> ... i noticed you and hakon were editors for that spec
06:56:27 <heycam> ... where does calc() stand?
06:56:30 <heycam> CL: not moving fast
06:56:38 <heycam> ... once other things are done, more effort will go in to it
06:56:46 <heycam> ... like the syntax module, it sort of rounds up bits
06:56:55 <heycam> ... any time a module adds a new value or unit, they'll have to modify that module as well
06:56:58 <heycam> ... so they're waiting, pretty much
06:57:33 <heycam> DS: we thought that that would be the easiest way, for us, for having say <rect width="calc(100% - 10px)" ...
06:58:10 <heycam> ... we'd have to extend it, because cameron's constraint syntax also takes into account references to attribute values on other elements, and also a notation to refer to the bbox of an element
06:58:13 <heycam> ... so we'd have to take that an extend it
06:58:16 <heycam> ... what do you think about that?
06:58:37 <heycam> CL: we already have things with fallback values, the attribute takes two things
06:58:49 <heycam> DS: i thought that came from css.  did it not?
06:58:52 <heycam> CL: not sure
06:59:03 <heycam> DS: in any case, we're considering adopting that syntax
06:59:19 <heycam> ... if they didn't want us to extend it, we could make our own svg-expression() syntax (or something)
06:59:59 <heycam> CM: this was in the context of turning @width a property, too
07:00:03 <heycam> ... so we could get this calc() for free
07:00:25 <heycam> CL: in svg, when we designed it, we decided that there's separation between content and presentation
07:00:42 <heycam> ... we decided that the geometry was the content (attributes), and the geometry could be styled in various ways (properties)
07:01:02 <heycam> ... given that, you can currently have width="" height="" *and* style="width: ...; height: ..", which mean different things
07:01:29 <heycam> ... if you change them from being an attribute to a property, then you have a conflict with the existing properties
07:01:44 <heycam> CM: except that width/height properties don't have any meaning on svg elements currently
07:02:04 <heycam> ED: but there are presentation attributes currently
07:02:11 <heycam> CL: but width="" on a <rect> isn't one of those currently
07:03:10 <heycam> DS: i know that coming to svg initially, since i knew a bit of css, i was very unclear about what the division was between attributes and properties
07:03:27 <heycam> ... not saying that there won't be problems, but perhaps the gains we would get would outweigh the confusion or other problems
07:03:34 <heycam> ... what would we lose from doing this, and what would we gain?
07:03:47 <heycam> ... gain: for people who already know css, most designers, they would be able to use svg more easily
07:03:56 <heycam> ... also gain the ability to use css classes to define those attributes values
07:03:59 <heycam> ... many times i've wanted to do that
07:04:06 <heycam> ... also we could get this calc() syntax for free
07:04:16 <heycam> ED: what you would lose is backwards compat
07:04:49 <heycam> CM: i don't think there's much that would actually break
07:05:05 <heycam> DS: i understand chris the distinction you make between geometry/styling
07:05:15 <heycam> ... but other things, such as stroke-width, change the geometry of the element
07:05:22 <heycam> CL: well...
07:05:35 <heycam> DS: esp if we make these changes where a bbox takes into account stroke-width/filters/etc.
07:05:37 <heycam> CL: right
07:05:48 <heycam> DS: i'm less convinced that the separation of content and style ...
07:05:56 <heycam> CL: yes, it can never be absolute, it's a sliding scale
07:06:04 <heycam> ... a general principle that you try to keep, rather than argue hard-and-fast
07:06:38 <heycam> DS: i used to argue that it wasn't presentational, that the geometry was the semantics of svg, but i don't think that's affected or changed, by being able to changed with css
07:06:46 <heycam> CL: i wasn't objecting, just saying that we'd need to be careful not to break anything
07:07:10 <heycam> DS: not every attribute could be usefully defined as a css property, for example xlink:href
07:07:17 <heycam> CL: this is for every attribute?
07:07:22 <heycam> DS: no i'm saying there are some that don't make sense
07:07:26 <heycam> ... but for x/y/width/height, sure
07:07:30 <heycam> ... d on path?  probably not
07:07:40 <heycam> ... positional and sizing attributes
07:07:48 <heycam> ... where indeed is the distinction, where do we draw the line?
07:08:03 <heycam> ... xlink:href definitely seems not presentational at all
07:08:13 <heycam> CL: x/y/width/height css absolute positioning uses those
07:08:17 <heycam> ... don't necessarily mean the same thing
07:08:23 <heycam> ... vml tried to use those, and it was a mess
07:08:32 <heycam> DS: i remember i was looking recently at vml, and thinking why didn't they adopt the syntax
07:08:42 <heycam> CL: people told us it was horrible
07:08:49 <heycam> ... relative/absolute positioning isn't as simple as you think
07:09:11 <ChrisL> s/isn't/in CSS2 isnt/
07:09:49 <heycam> CL: a downside is that maybe csswg would then want to define what values we can have in our attributes
07:09:59 <heycam> DS: possibly
07:14:54 <heycam> ACTION: Doug to contact the CSSWG about making some more SVG attributes properties
07:14:54 <trackbot> Created ACTION-2535 - Contact the CSSWG about making some more SVG attributes properties [on Doug Schepers - due 2009-05-06].
07:15:12 <heycam> Topic: Raleigh F2F
07:15:18 <ed> http://www.w3.org/Graphics/SVG/WG/wiki/NCF2F2009
07:15:29 <heycam> CL: i can confirm that i can attend
07:17:09 <heycam> ED: maybe we should gather a few agenda topics
07:17:17 <heycam> ... we'll have all of the modules
07:17:20 <heycam> ... particular requests?
07:17:42 <heycam> CL: test suites for individual modules, and how we'll work on those
07:17:54 <heycam> ... recently in inkscape, there's something that's used by filters
07:17:58 <heycam> ... one of the interpolation properties
07:18:02 <heycam> ... color-interpolation-filters
07:18:09 <heycam> ... i grepped the test suite and found we had none for it
07:18:39 <heycam> http://www.w3.org/Graphics/SVG/WG/track/issues/2219
07:18:49 <heycam> ED: I plan to test all attributes/properties for filters
07:18:52 <heycam> ... for the filter module
07:19:42 <shepazu> fill="url(#myRedGradient) red"
07:20:36 <heycam> ED: so a reminder to fill in the registration form for the f2f
07:20:41 <ed> http://www.w3.org/2002/09/wbs/19480/NC2009/
07:21:42 <ed> ACTION: ed to mail public-svg-wg reminding ppl about the raleigh F2F
07:21:42 <trackbot> Created ACTION-2536 - Mail public-svg-wg reminding ppl about the raleigh F2F [on Erik Dahlström - due 2009-05-06].
07:23:57 <heycam> Topic: SVG script and style parsing in HTML
07:24:00 <ed> http://lists.w3.org/Archives/Public/www-svg/2009Apr/0096.html
07:24:34 <heycam> ED: asking about how <script> and <style> should be parsed in svg-in-text/html
07:25:21 <heycam> CL: this about cdata-marked sections?
07:25:21 <heycam> ED: yes
07:25:29 <heycam> ... what type of behaviour would be the most intuitive to authors?
07:25:46 <heycam> CL: people tend to put in cdata-sections all over the place, just to be sure
07:26:07 <heycam> ... so if you have a "<" it prevents starting a tag
07:26:12 <heycam> ... handy if you've got that in a script
07:26:22 <heycam> ... in many cases it makes no difference; just treat them as tokens to be gobbled up
07:26:35 <heycam> ... but there cases where you need to treat the "<" as character data
07:26:44 <heycam> ... we could define that implicitly there is a cdata-section around script and style
07:26:52 <heycam> ... and that you can't open/close elements inside script/style
07:27:00 <heycam> ... only </script> would close <script>
07:27:12 <heycam> DS: i think that is more-or-less how they handled it
07:28:23 <heycam> ... we have as a requirement that svg extracted from an html should work as standalone svg
07:28:47 <heycam> CM: i think some people were ok with that having to work, and others didn't feel the need for it
07:29:23 <heycam> DS: iirc sicking was suggesting that the cdata-section syntax would be allowed, and would be treated as in xml syntax
07:29:36 <heycam> ... it doesn't really matter what gets put into the dom
07:31:16 <heycam> CM: i don't think it matters whether CDATASection or Text nodes get put into the dom
07:33:47 <heycam> ED: i would prefer it for <script> inside svg-in-text/html to be parsed the same as html <script>
07:35:21 <ChrisL> I would prefer that too
07:35:38 <heycam> CM: as long as the CDATA-sections still work
07:35:49 <ChrisL> would that mean that CDATA marked sections should not be used? Or should be silently ignored?
07:35:56 <heycam> DS: there are other things not being enforced about the xml syntax, so it sort of makes that argument moot
07:36:22 <heycam> ED: if you look at svg content today, most is made by scripts anyway
07:36:54 <heycam> ... i'm not sure how big of a concern it is
07:37:16 <ed> s/svg content today/svg content used on the web today/
07:39:42 <heycam> ACTION: Cameron to reply to the style/script thread
07:39:42 <trackbot> Created ACTION-2537 - Reply to the style/script thread [on Cameron McCormack - due 2009-05-06].
07:40:47 <ChrisL> issue-2260?
07:40:47 <trackbot> ISSUE-2260 -- Value of SVGElement::id not defined when there is no id="" attribute present -- RAISED
07:40:47 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2260
07:40:55 <heycam> Topic: Value of SVGElement::id not defined when there is no id="" attribute present
07:41:11 <ed> http://www.w3.org/Graphics/SVG/WG/track/issues/2260
07:42:05 <ChrisL> "Probably we should backport the behaviour from 1.2T, which says that the value is null."
07:42:14 <heycam> CM: in html5 it's empty string if the id="" attribute is missing
07:42:20 <shepazu> <rect id="" ... />
07:44:03 <heycam> DS: my preference would be null if it's not there, but since html already does it empty string, rather go that way
07:44:24 <heycam> CL: in tiny it says it should be null
07:44:34 <heycam> DS: i don't think it would break any content if we change that
07:44:47 <heycam> CL: if we change 1.1, i would like 1.2T to be errataed to make that empty string
07:50:20 <heycam> RESOLUTION: If it's compatible, make 1.1 return "" for SVGElement::id when the attribute is missing, and port that to 1.2T
07:50:38 <heycam> ACTION: Cameron to check that if it's compatible, make 1.1 return "" for SVGElement::id when the attribute is missing, and port that to 1.2T
07:50:38 <trackbot> Created ACTION-2538 - Check that if it's compatible, make 1.1 return "" for SVGElement::id when the attribute is missing, and port that to 1.2T [on Cameron McCormack - due 2009-05-06].
07:51:01 <heycam> Topic: SVGXXXList interfaces perhaps should not throw SVGException(SVG_WRONG_TYPE_ERR)
07:51:06 <ChrisL> issue-2261?
07:51:07 <trackbot> ISSUE-2261 -- SVGXXXList interfaces perhaps should not throw SVGException(SVG_WRONG_TYPE_ERR) -- RAISED
07:51:07 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2261
07:53:28 <heycam> CM: i think it would be best to just drop the requirement about throwing that exception
07:53:45 <heycam> ED: you tested and none of the implementations threw the SVGException
07:54:04 <heycam> RESOLUTION: Drop those exceptions
07:54:20 <heycam> ACTION: Cameron to drop the SVGExceptions for ISSUE-2261
07:54:20 <trackbot> Created ACTION-2539 - Drop the SVGExceptions for ISSUE-2261 [on Cameron McCormack - due 2009-05-06].
07:54:38 <heycam> Topic: SVGStyleElement should inherit from SVGLangSpace
07:54:40 <ChrisL> issue-2264?
07:54:40 <trackbot> ISSUE-2264 -- SVGStyleElement should inherit from SVGLangSpace -- RAISED
07:54:40 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2264
07:56:33 <heycam> CM: weird that SVGStyleElement doesn't inherit from SVGLangSpace
07:58:11 <heycam> ED: if you allow those attributes you should be able to access them
07:59:01 <heycam> CM: the only difference would be that now you could access .xmllang on a <style>
07:59:21 <heycam> RESOLUTION: Make SVGStyleElement inherit from SVGLangSpace
07:59:36 <heycam> ACTION: Cameron to make SVGStyleElement inherit from SVGLangSpace
07:59:36 <trackbot> Created ACTION-2540 - Make SVGStyleElement inherit from SVGLangSpace [on Cameron McCormack - due 2009-05-06].
08:01:37 <shepazu> \me http://www.w3.org/TR/SVGTiny12/painting.html#SpecifyingPaint <FuncIRI> [ none | currentColor | <color>]  doesn't seem to contain syntax for a fallback value...
08:02:53 <Zakim> -ChrisL
08:02:54 <Zakim> -ed
08:02:57 <Zakim> -heycam
08:03:13 <heycam> RRSAgent, bye
08:03:13 <RRSAgent> I see 7 open action items saved in http://www.w3.org/2009/04/29-svg-actions.rdf :
08:03:13 <RRSAgent> ACTION: Doug to ask HTML WG what they think about parsing <param> and <link> in SVG [1]
08:03:13 <RRSAgent>   recorded in http://www.w3.org/2009/04/29-svg-irc#T06-46-24
08:03:13 <RRSAgent> ACTION: Doug to contact the CSSWG about making some more SVG attributes properties [2]
08:03:13 <RRSAgent>   recorded in http://www.w3.org/2009/04/29-svg-irc#T07-14-54
08:03:13 <RRSAgent> ACTION: ed to mail public-svg-wg reminding ppl about the raleigh F2F [3]
08:03:13 <RRSAgent>   recorded in http://www.w3.org/2009/04/29-svg-irc#T07-21-42
08:03:13 <RRSAgent> ACTION: Cameron to reply to the style/script thread [4]
08:03:13 <RRSAgent>   recorded in http://www.w3.org/2009/04/29-svg-irc#T07-39-42
08:03:13 <RRSAgent> ACTION: Cameron to check that if it's compatible, make 1.1 return "" for SVGElement::id when the attribute is missing, and port that to 1.2T [5]
08:03:13 <RRSAgent>   recorded in http://www.w3.org/2009/04/29-svg-irc#T07-50-38
08:03:13 <RRSAgent> ACTION: Cameron to drop the SVGExceptions for ISSUE-2261 [6]
08:03:13 <RRSAgent>   recorded in http://www.w3.org/2009/04/29-svg-irc#T07-54-20
08:03:13 <RRSAgent> ACTION: Cameron to make SVGStyleElement inherit from SVGLangSpace [7]
08:03:13 <RRSAgent>   recorded in http://www.w3.org/2009/04/29-svg-irc#T07-59-36
08:03:53 <RRSAgent> RRSAgent has joined #svg
08:03:53 <RRSAgent> logging to http://www.w3.org/2009/04/29-svg-irc
08:03:56 <heycam> RRSAgent, make minutes
08:03:56 <RRSAgent> I have made the request to generate http://www.w3.org/2009/04/29-svg-minutes.html heycam
08:04:14 <heycam> RRSAgent, make minutes public
08:04:14 <RRSAgent> I'm logging. I don't understand 'make minutes public', heycam.  Try /msg RRSAgent help
08:04:23 <heycam> RRSAgent, help?
08:04:23 <RRSAgent> I'm logging.  Sorry, nothing found for 'help'
08:04:54 <heycam> RRSAgent, make log public
08:06:24 <heycam> RRSAgent, bye
08:06:24 <RRSAgent> I see no action items