IRC log of svg on 2009-04-27

Timestamps are in UTC.

06:29:36 [RRSAgent]
RRSAgent has joined #svg
06:29:36 [RRSAgent]
logging to http://www.w3.org/2009/04/27-svg-irc
06:29:38 [trackbot]
RRSAgent, make logs public
06:29:39 [Zakim]
Zakim has joined #svg
06:29:40 [trackbot]
Zakim, this will be GA_SVGWG
06:29:40 [Zakim]
ok, trackbot; I see GA_SVGWG()2:30AM scheduled to start in 1 minute
06:29:41 [trackbot]
Meeting: SVG Working Group Teleconference
06:29:41 [trackbot]
Date: 27 April 2009
06:29:54 [Zakim]
GA_SVGWG()2:30AM has now started
06:29:54 [Zakim]
+Shepazu
06:30:10 [Zakim]
+[IPcaller]
06:30:11 [Zakim]
-[IPcaller]
06:30:11 [Zakim]
+[IPcaller]
06:30:12 [heycam]
Zakim, [ is me
06:30:13 [Zakim]
+heycam; got it
06:30:20 [heycam]
Zakim, who is on the call?
06:30:20 [Zakim]
On the phone I see Shepazu, heycam
06:32:44 [shepazu]
nope
06:33:25 [Zakim]
+??P1
06:33:28 [Zakim]
+[IPcaller]
06:33:32 [ed]
Zakim, ??P1 is me
06:33:32 [Zakim]
+ed; got it
06:33:38 [anthony]
Zakim, [IP is me
06:33:38 [Zakim]
+anthony; got it
06:38:25 [ed]
scribe: erik
06:38:26 [heycam]
Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0072.html
06:38:29 [ed]
scribeNick: ed
06:39:07 [ed]
Chair: heycam
06:39:10 [ed]
Topic: Publishing the Compositing spec
06:39:51 [ed]
CM: we discussed previously to publish the spec this week, sent some comments today, but those doesn't need to hold up the publication
06:40:35 [ed]
AG: those comments are good, mostly typo corrections, and a couple of things that need to be explained
06:40:51 [ed]
...as long as everyone else is ok with publishing
06:41:00 [ed]
DS: has it been FPWD?
06:41:08 [ed]
AG: this would be the FPWD
06:41:23 [ed]
CM: parts were published before in the 1.2 full draft
06:41:40 [ed]
DS: this is a new spec though
06:42:18 [ed]
CM/DS: we can do the cleanups/typos after the FPWD
06:42:35 [ed]
CM: are we resolved to publish compositing?
06:42:48 [ed]
DS: any objections?
06:42:52 [ed]
all: no
06:43:18 [ed]
s/all: no/all: no objections, let's publish/
06:43:43 [ed]
RESOLUTION: to publish SVG Compositing as a FPWD
06:44:34 [ed]
ACTION: DS to publish the SVG Compositing spec
06:44:34 [trackbot]
Created ACTION-2527 - Publish the SVG Compositing spec [on Doug Schepers - due 2009-05-04].
06:44:50 [ed]
Topic: Updating broken CSS2 links
06:44:59 [ed]
DS: doesn't need discussion?
06:45:16 [ed]
CM: we need to decide how to deal with it, in the existing spec
06:45:50 [ed]
...summary: because of the shortname /CSS2 and /CSSREC2 are now redirected to CSS21, various links in SVG 1.1 are now dangling
06:46:14 [ed]
...full dated uri:s should have been used from the start in the spec
06:47:01 [ed]
...we can replace the SVG 1.1 spec links in place to fix the links
06:47:16 [heycam]
s/CSSREC2/REC-CSS2/
06:47:36 [ed]
ED: are we still pointing to CSS2, or 2.1?
06:47:42 [ed]
CM: css2
06:48:47 [ed]
CM: if there are no objections, we can fix the links, have link to the files that need to be switched
06:49:32 [ed]
...there are a couple in tiny 1.2 too, not broken ones, but it's now pointing to css21...and those features are still in css21 anyway
06:49:44 [ed]
...but css2 is in the ref-section
06:49:58 [ed]
...will forward the mail with the fixups
06:50:48 [ed]
ACTION: heycam to mail DS the info for fixing up CSS2 links in the SVG 1.1 spec
06:50:48 [trackbot]
Created ACTION-2528 - Mail DS the info for fixing up CSS2 links in the SVG 1.1 spec [on Cameron McCormack - due 2009-05-04].
06:51:14 [ed]
Topic: Referencing CSS 2.1 from SVG 1.1 Second Edition
06:51:34 [ed]
CM: I'm not that familiar with what's changed
06:51:58 [ed]
...one thing I know of is the webfonts stuff, which is now in CSS3 webfonts
06:52:18 [ed]
DS: I don't think we should change SVG 1.1 that much
06:52:27 [ed]
CM: probably more effort than its worth
06:52:58 [ed]
...we don't want to change things, but rather to point to the more up-to-date spec (CSS21)
06:53:08 [ed]
...they may be in CR for awhile anyway
06:53:22 [ed]
DS: it wouldn't be correct to change it
06:53:43 [ed]
...we may be changing things dramatically for older svg useragents
06:54:11 [ed]
...we should definately reference CSS21 going forward, but not in the SVG 1.1 second edition
06:54:18 [ed]
ED: yes, I agree with that
06:54:24 [ed]
CM: fine with me
06:54:45 [ed]
Topic: Pattern and rendering order
06:54:51 [heycam]
http://lists.w3.org/Archives/Public/www-svg/2009Apr/0088.html
06:55:28 [heycam]
ED: he's asking about the case when the pattern tile has some overflow, asking how it's supposed to render
06:55:34 [heycam]
ED: of course, UAs differ on how they interpret this
06:55:43 [heycam]
ED: i think he's saying that the most logical solution would be to use the painters model
06:56:14 [heycam]
ED: he's saying that because at least opera and asv don't support overflow, you can't do all types of overlapping patterns
06:56:30 [ed]
http://lists.w3.org/Archives/Public/www-svg/2009Apr/0093.html
06:56:57 [heycam]
ED: he refers to the 17 known tiling patterns
06:57:06 [heycam]
ED: in my response i ask him what kinds of patterns couldn't you do
06:57:10 [heycam]
ED: he replied with those 17 groups
06:57:21 [heycam]
ED: because you can do quite a few types by rearranging the tile itself
06:57:32 [heycam]
ED: if you want to be able to do all these other ones, then the pattern rendering would have to be a bit more advanced
06:58:03 [heycam]
ED: the 1.1 spec doesn't really say how you render those cases, it just says that you can have overflow:visible, doesn't say what that's supposed to look like or handled
06:58:35 [heycam]
ED: i haven't tested that many implementations, it would probably be nice to have examples of each of these 17 groups of periodic tilings, and to see what all of the current UAs do
06:58:44 [heycam]
ED: one problem would be that there are not that many UAs that support patterns
06:58:53 [heycam]
ED: i don't think safari does it
06:59:07 [heycam]
ED: batik, asv, opera and i think firefox 3
06:59:13 [heycam]
ED: those should be tested for all those groups
06:59:49 [heycam]
ED: i think batik/asv/opera all just take the rectangle and tile that
07:00:01 [heycam]
ED: i think for 1.1 Second Edition we should disallow it, or state that it's undefined explicitly
07:00:36 [heycam]
CM: would we say that overflow has no effect, and that it always clips to the pattern viewport?
07:00:46 [heycam]
ED: or we could say that it's undefined behaviour, so we could leave it open for fixing later
07:01:14 [heycam]
CM: is it worth having it undefined so that we can define it later?
07:01:17 [heycam]
DS: it's worth considering
07:01:20 [heycam]
AG: should email olaf back
07:02:26 [heycam]
ED: we should test the fallback behaviour; it's possible it's just clipped to the viewport
07:02:59 [heycam]
DS: this is definitely something we should consider following up on, not necessarily something we should change now
07:03:29 [heycam]
DS: IME patterns are useless sometimes
07:05:06 [heycam]
ED: so we could just say that overflow:visible is undefined
07:05:12 [heycam]
AG: raise an issue on svg 2 to define it
07:06:56 [ed]
ACTION: ed to add an svg 1.1 errata for making overflow=visible on patterns be undefined behaviour and to raise an issue on solving the pattern tiling for overflow=visible (core2)
07:06:56 [trackbot]
Created ACTION-2529 - Add an svg 1.1 errata for making overflow=visible on patterns be undefined behaviour and to raise an issue on solving the pattern tiling for overflow=visible (core2) [on Erik Dahlström - due 2009-05-04].
07:07:21 [ed]
Topic: ‘image-fit’ vs preserveAspectRatio
07:08:34 [ed]
ED: so the only remaining issue really is the naming it seems
07:08:46 [ed]
...the feature is useful for both CSS and SVG
07:10:01 [ed]
CM: so it would be fine if UAs implented both pAR and image-fit/content-fit
07:11:00 [ed]
DS/CM/ED: all like 'content-*'
07:11:13 [ed]
s/all/we all/
07:12:01 [ed]
ACTION: ed to reply to the image-fit thread saying that the SVG WG would prefer the name(s) 'content-*'
07:12:02 [trackbot]
Created ACTION-2530 - Reply to the image-fit thread saying that the SVG WG would prefer the name(s) 'content-*' [on Erik Dahlström - due 2009-05-04].
07:12:25 [ed]
Topic: ref/params spec
07:12:58 [ed]
DS: any reviews so far, besides heycam?
07:13:06 [ed]
AG: not yet
07:13:24 [ed]
ED: only read the proposals so far
07:13:41 [ed]
DS: heycam has proposed an alternate syntax
07:14:28 [ed]
...a suggestion about an alternate syntax that got rid of the ref element, and directly put a functional values in the attribute values
07:14:41 [ed]
CM: yeah, wanted to see if I could get rid of the ref elements
07:14:53 [ed]
DS: yeah, we talked about it at the TPAC
07:15:04 [ed]
...paintservers are similar
07:15:17 [ed]
...would it be easier to implement if it used the same mechanism?
07:15:29 [ed]
...thinking about it now, I could implement it in script either way
07:16:12 [ed]
CM: the weird part in my proposal is the content attribute, which is similar to :content in css
07:16:41 [ed]
...so it would be more general way of inserting text content
07:17:12 [ed]
DS: one problem with tref, if the content doesn't resolve then the user is left unknowing, nothing will be shown (no fallback content)
07:17:26 [ed]
...so I liked the idea of allowing fallback content for tref
07:17:43 [ed]
...are we talking about markup or just strings?
07:17:56 [ed]
...tref just takes a string
07:18:57 [ed]
...having fallback for tref and having content, not so keen on having stirngs in attributes though
07:20:00 [ed]
CM: in svg normally if you have a tref reference to a switch would it give you the textContent or would it do the switch processing?
07:20:08 [ed]
ED: I think it's just textContent
07:20:28 [ed]
CM: a problem is that one of the role attributes is named 'content'
07:21:00 [ed]
...the reason I chose 'content' is that it offers the same functionality as the css content property
07:21:20 [ed]
...what do you want in terms in of publication?
07:21:46 [ed]
...might be good to publish this to let people know we want to add this functionality
07:22:23 [ed]
AG: yeah, we should get it out and get comments
07:22:40 [ed]
CM: DS you could add some notes there, for these things
07:23:51 [ed]
DS: what do you think of changing the values of things like geometric values of things like x and y, to have functional values?
07:24:00 [ed]
CM: you mean turning attributes into properties?
07:24:09 [ed]
DS: did you see the primer?
07:24:37 [shepazu]
http://dev.w3.org/SVG/modules/ref/SVGRef.html
07:25:12 [shepazu]
http://dev.w3.org/SVG/modules/ref/SVGRefPrimer.html
07:25:54 [ed]
DS: scroll down to the maps
07:26:12 [ed]
...there's a little dot the, parameterising the cx and cy
07:26:33 [ed]
...and same for links, to pass in links for e.g ads
07:26:45 [ed]
CM: like the examples
07:28:35 [ed]
DS: right now we cna only use functional notation for attribute values in presentation attributes
07:28:48 [ed]
...i'd like to extend that to all attributes
07:29:04 [ed]
...one, why wouldn't you want to set anything with css?
07:29:18 [ed]
...two, it would work for camerons constraints stuff
07:29:34 [ed]
CM: it will be important to think about how this would work for future things
07:30:30 [ed]
DS: parameterised attribute values is probably how I would go with extending the syntax
07:30:45 [ed]
...so I'd like to say e.g 100%-5px without having it in a URL
07:31:00 [ed]
CM: calc in CSS provides that
07:31:21 [ed]
...if we're looking at promoting the attributes to properties, then we could gain from that
07:31:36 [ed]
...it makes enough sense to be able to put them there
07:31:45 [shepazu]
http://www.w3.org/TR/css3-values/#calc
07:31:57 [ed]
...it does make sense to upgrade them to being properties
07:32:13 [ed]
ED: all attributes?
07:32:22 [ed]
DS: most, href would be an exception
07:33:07 [ed]
ED: lists of things e.g, sometimes you might want to override only parts of a list (or a path)
07:34:29 [ed]
DS: anything that takes a list couldn't have a fallback
07:34:45 [ed]
...any other attributes could have a fallback
07:35:48 [shepazu]
<rect ... fill="param(color) blue" stroke="param(outline) navy" />
07:36:30 [ed]
CM: that might mean we have to think about types
07:36:57 [ed]
DS: if we do it, it's done, there's going to be flaws with any model we come up with
07:37:05 [ed]
...i like functional values
07:37:13 [ed]
...it builds on things laid out in css
07:37:28 [shepazu]
width: calc(100%/3 - 2*1em - 2*1px);
07:39:14 [ed]
CM: i would be in favor of investigating making existing svg attributes into properties
07:39:27 [ed]
DS: given that we want to allow this syntax anyway
07:39:48 [ed]
...I think it makes sense for parameterising things like stroke and fill
07:39:59 [ed]
...might make sense for other things (I think it does)
07:41:02 [ed]
...less work to specialcase the ones that aren't properties
07:41:18 [ed]
CM: would make it easier to reuse content
07:42:19 [ed]
DS: markers is one thing, had to duplicate the markers several times to style them differently
07:43:38 [ed]
ED: yeah, it's annoying that it behaves different from use, which do inherit style into the shadowtree
07:45:06 [ed]
DS: i like having an ref element, because you can animate those in the document
07:45:26 [ed]
...and we don't have the equivalent of <param> in svg
07:45:51 [ed]
...if I wanted to use a button multiple times, I might like to actually like to use this syntax
07:46:12 [ed]
...I was thinking of the <animation> element, or the <image> element, anything that references
07:46:23 [ed]
...even the <use> element
07:46:56 [ed]
AG: would we run into problems with optional arguments?
07:47:29 [ed]
DS: <ref> have default values, but the example with the rect above, you could also pass defaults there
07:47:37 [ed]
...it's important
07:48:19 [ed]
AG: multiple optional elements
07:48:54 [ed]
...or multiple optional arguments
07:49:56 [ed]
DS: this is a new class of things we could start doing...calc, or url() and param
07:50:25 [ed]
...there's an attr() function
07:50:48 [ed]
CM: often used with css content
07:51:50 [anthony]
transform="param(blah) translate(20 20)"
07:52:21 [ed]
DS: we should talk to the csswg about this
07:52:54 [ed]
AG: so, would the translate be an additonal transform, or a fallback?
07:52:59 [shepazu]
transform="scale(param(blah)) translate(20 20)"
07:53:05 [ed]
DS: it's a list, so would need to be specialcased
07:53:36 [ed]
AG: needs special consideration yeah
07:53:58 [ed]
DS: might be handy with translateX,Y,Z
07:54:58 [ed]
DS: will add notes with the functional notation for param
07:55:17 [ed]
...and if we're not going to have an element, then it could be applied to css as well
07:55:34 [ed]
CM: yeah, that might be good
07:57:49 [ed]
RESOLUTION: publish the param/ref spec as FPWD
07:59:42 [ed]
ACTION: heycam to get the ref spec building with the new scripts
07:59:42 [trackbot]
Created ACTION-2531 - Get the ref spec building with the new scripts [on Cameron McCormack - due 2009-05-04].
08:00:22 [ed]
ACTION: DS to integrate the new potential syntax, and publish the ref spec
08:00:23 [trackbot]
Created ACTION-2532 - Integrate the new potential syntax, and publish the ref spec [on Doug Schepers - due 2009-05-04].
08:02:33 [ed]
ACTION: heycam to look into making attributes into properties, and potential problems with that
08:02:33 [trackbot]
Created ACTION-2533 - Look into making attributes into properties, and potential problems with that [on Cameron McCormack - due 2009-05-04].
08:03:16 [Zakim]
-ed
08:03:18 [Zakim]
-anthony
08:03:19 [Zakim]
-heycam
08:03:28 [ed]
Zakim, bye
08:03:28 [Zakim]
leaving. As of this point the attendees were Shepazu, [IPcaller], heycam, ed, anthony
08:03:28 [Zakim]
Zakim has left #svg
08:03:34 [ed]
rrs-agent, make minutes
08:03:41 [ed]
RRSAgent, make minutes
08:03:41 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/04/27-svg-minutes.html ed
08:06:54 [shepazu]
ed: watch our for the pirate ArrrghArrrghSAgent
08:44:38 [heycam]
heycam has joined #svg