IRC log of svg on 2009-03-23

Timestamps are in UTC.

19:34:02 [RRSAgent]: RRSAgent has joined #svg
19:34:03 [RRSAgent]: logging to http://www.w3.org/2009/03/23-svg-irc
19:34:04 [trackbot]: RRSAgent, make logs public
19:34:04 [Zakim]: Zakim has joined #svg
19:34:06 [trackbot]: Zakim, this will be GA_SVGWG
19:34:06 [Zakim]: ok, trackbot; I see GA_SVGWG()2:30PM scheduled to start 64 minutes ago
19:34:07 [trackbot]: Meeting: SVG Working Group Teleconference
19:34:07 [trackbot]: Date: 23 March 2009
19:34:32 [Zakim]: GA_SVGWG()2:30PM has now started
19:34:33 [Zakim]: +Shepazu
19:35:06 [Zakim]: +??P5
19:35:17 [ed]: Zakim, ??P5 is me
19:35:17 [Zakim]: +ed; got it
19:36:11 [Zakim]: +[IPcaller]
19:36:14 [heycam]: Zakim, [ is me
19:36:14 [Zakim]: +heycam; got it
19:38:19 [heycam]: Zakim, who is here?
19:38:19 [Zakim]: On the phone I see Shepazu, ed, heycam
19:38:20 [Zakim]: On IRC I see RRSAgent, ed, heycam, shepazu, jwatt, anthony, trackbot, ed_work
19:39:17 [Zakim]: + +39.524.9.aaaa
19:39:18 [ChrisL]: ChrisL has joined #svg
19:43:39 [heycam]: Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0290.html
19:44:06 [heycam]: Zakim, pick a scribe
19:44:06 [Zakim]: Not knowing who is chairing or who scribed recently, I propose +39.524.9.aaaa
19:44:22 [censor-bot]: zakim, who is here?
19:44:22 [Zakim]: On the phone I see Shepazu, ed, heycam, +39.524.9.aaaa
19:44:23 [Zakim]: On IRC I see censor-bot, Zakim, RRSAgent, ed, heycam, shepazu, jwatt, anthony, trackbot, ed_work
19:44:36 [censor-bot]: zakim, where is +39?
19:44:36 [Zakim]: country code 39 is Italy
19:44:51 [Zakim]: +[IPcaller]
19:44:59 [anthony]: Zakim, +[IP is me
19:44:59 [Zakim]: sorry, anthony, I do not recognize a party named '+[IP'
19:45:02 [censor-bot]: zakim, drop +39
19:45:02 [Zakim]: +39.524.9.aaaa is being disconnected
19:45:03 [Zakim]: - +39.524.9.aaaa
19:45:05 [anthony]: Zakim, [IP is me
19:45:05 [Zakim]: +anthony; got it
19:46:18 [Zakim]: + +39.524.9.aabb
19:47:04 [Italian-Chris]: scribe-niick: Italian-Chris
19:47:33 [heycam]: ScribeNick: Italian-Chris
19:48:11 [heycam]: Topic: Additional value for image-rendering
19:49:44 [Italian-Chris]: CL: disable-resampling might give thr idea that the image is at 1:1 with device pixels
19:49:55 [Italian-Chris]: ... so I prefer nearest-neighbor explicitly
19:50:30 [Italian-Chris]: DS: In favour
19:50:41 [ed__]: ed__ has joined #svg
19:50:57 [Italian-Chris]: Cam: [bxxxxxt ... dd ... guh ]
19:51:19 [Zakim]: -ed
19:51:35 [heycam]: CM: should it added to Core?
19:51:43 [heycam]: s/added/be added/
19:51:49 [ed___]: ed___ has joined #svg
19:52:28 [ed____]: ed____ has joined #svg
19:52:29 [Zakim]: +??P3
19:52:35 [ed____]: Zakim, ??P3 is me
19:52:35 [Zakim]: +ed____; got it
19:53:22 [Italian-Chris]: action: doug to add nearest-neighbor as a value of image-rendering to Core
19:53:23 [trackbot]: Created ACTION-2500 - Add nearest-neighbor as a value of image-rendering to Core [on Doug Schepers - due 2009-03-30].
19:53:47 [Italian-Chris]: ed: camelCase it or hyphen-ate it?
19:54:15 [Italian-Chris]: Cam: camel
19:54:23 [Italian-Chris]: CL: Other values are camel - http://www.w3.org/TR/SVG11/painting.html#ImageRenderingProperty
19:54:34 [Italian-Chris]: auto | optimizeSpeed | optimizeQuality
19:54:41 [Italian-Chris]: DS: Not sure
19:55:30 [Italian-Chris]: CL: Is it appropriate to do this as image-rendering is a hint. Whats the conformance?
19:55:42 [Italian-Chris]: Cam: Seems like the other values are hints
19:55:50 [heycam]: s/are hints/are not hints/
19:56:08 [Italian-Chris]: DS: rendering hints are ok for single vendor, get predictable behaviour
19:56:13 [heycam]: CM: for example, optimizeQuality requires something at least as good as bilinear resampling
19:57:40 [Italian-Chris]: CL: Yes, the existing description uses shall
19:58:11 [Italian-Chris]: CL: We want something that forces NN even if, say, there is hardware support for bicubic
19:58:58 [heycam]: CM: there was some support for crispEdges on the mailing list
19:59:17 [heycam]: CM: it's not quite an accurate description, but it is used by other similar properties
19:59:42 [Italian-Chris]: CL: could be confused with photoshop bicubic-sharper though
20:00:24 [Italian-Chris]: CL: at some point we should think about allowing unsharp masking after image resampling
20:00:34 [heycam]: Topic: Sizing of <video poster=svg>
20:00:39 [heycam]: http://www.w3.org/mid/op.uq3g00j2idj3kv@zcorpandell.linkoping.osa
20:00:57 [Italian-Chris]: http://lists.w3.org/Archives/Public/www-svg/2009Mar/0174.html
20:01:50 [Italian-Chris]: ED: Have taled with simon, video in html5 can omit defined width and height, use the intrinsic size from the video which may not be known before decoding
20:02:08 [Italian-Chris]: ... so you have poster images to show before the first frame, how big are they
20:02:34 [Italian-Chris]: DS: Where the hell does 300x150 come from?
20:02:48 [Italian-Chris]: ... seems arbitrary and almost always wrong
20:04:04 [Italian-Chris]: DS: I guess authors can easily override it with real values
20:04:26 [Italian-Chris]: ... wonder if it can be changed. Does content rely on this?
20:05:14 [Italian-Chris]: ED: Object gives you 100% width, and height from the intrinsic ratio
20:06:10 [Italian-Chris]: ED: This is something we coordinated with fantasai for CSS 2.1 and Tint 1.2
20:06:34 [shepazu]: s/easily override it with real values/easily override it with real values, by giving intrinsic dimensions to the video element or the SVG itself/
20:06:34 [ed____]: s/Tint/Tiny/
20:07:10 [heycam]: CM: i guess using 100% width is going to be less useful, if the video will resize to the intrinsic width of the video once it starts playing
20:08:16 [Italian-Chris]: ED: If you have a table with svg poster frames for the tables, then 300x150 is much less useful than 100%
20:08:36 [ed____]: s/for the tables/in a table cell/
20:08:40 [Italian-Chris]: rrsagent, make logs public
20:08:55 [heycam]: CM: does 100% mean use the width of the table cell?
20:09:24 [Italian-Chris]: CL: Yup, a table cell is a containing block
20:10:12 [heycam]: CM: i think 300x150 is the way to go. if you specifically want the avoid affecting the table cell width, you can put 100% on it
20:10:24 [heycam]: CM: since the instrinsic video size is going to be a fixed pixel width, and not 100% anyway
20:11:05 [Italian-Chris]: ED: Might be
20:12:11 [heycam]: CM: if we can't decide now, we can at least reply and give our reasons for choosing (or not) 300x150
20:13:17 [Italian-Chris]: ED: this is not something defined in SVG. Its an html or css issue
20:13:36 [Italian-Chris]: DS: Don't agree. Could define default behaviour for generic languages
20:14:12 [Italian-Chris]: ... when SVG is used as an image what should it do. is it animated, scripts run, click through etc
20:14:34 [Italian-Chris]: ... other langueges would want to know what do do - DocBooc, ODF, XSL FO, and so on
20:15:01 [Italian-Chris]: s/gueg/guag/
20:17:29 [heycam]: CM: should we just get back to them and give them our various thoughts then?
20:18:05 [Italian-Chris]: are we converging on 100% and height from aspect ratio? we can point to the css 2.1 spec for why
20:19:01 [heycam]: CM: i figure that, with typical browser window sizes, 100% is going to be less close to the final video size than 300x150
20:19:22 [heycam]: CM: but in the end i think it's not that important, so i don't mind too much
20:19:37 [Italian-Chris]: its of the containing block, not the window
20:20:54 [heycam]: CM: given <img>, <embed> and <object> get 100%, i'd be ok with going with 100%
20:20:54 [Italian-Chris]: It seems odd that CSS 2.1 specifies a behaviour but HTML 5 changes that to another value
20:21:24 [Italian-Chris]: DS: Yes, the CSS rules make more sense here. HTML5 should play well with CSS
20:21:48 [Italian-Chris]: DS: Fullscreen is a common requirement
20:22:41 [Italian-Chris]: ... having a way to do that is desirable
20:23:29 [Italian-Chris]: ... perhaps we could ask CSS WG to do that.
20:23:42 [Italian-Chris]: could be triggered by script or transitions or animation
20:24:32 [Italian-Chris]: ED: does that only happen for video?
20:24:52 [Italian-Chris]: DS: No, used for slideshows too . Covers the chrome
20:25:14 [Italian-Chris]: ... also good for webapps where the chrome is a distraction
20:27:06 [heycam]: CM: maybe an onfullscreen event?
20:27:08 [Italian-Chris]: DS: fullscreen mode should only be in response to user interaction
20:28:39 [heycam]: CM: although: i can see that you'd want to have a full screen button like in a youtube player
20:29:53 [Italian-Chris]: Topic: Missing Resources Indicator
20:30:01 [Italian-Chris]: http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0268.html
20:31:49 [Italian-Chris]: DS: missing image - defined in html5?
20:31:50 [Italian-Chris]: http://t-shirts.cafepress.com/item/tmwg-missing-image-tshirt/131168141
20:32:33 [Italian-Chris]: cam: make an issue for it
20:32:40 [Italian-Chris]: ds: not urgent
20:33:30 [shepazu]: there is an HTML convention for this, I'm not sure it's defined anywhere, but we should add some behavior similar to what HTML does, in SVG 2.0
20:33:41 [Italian-Chris]: Topic: SVG <title> containing markup or RCDATA
20:35:16 [Italian-Chris]: ds: tiny has different behaviour to head off complaints, and tiny tends to be for lower end devices. Can excpand in full. No need to change in Tiny
20:36:35 [Italian-Chris]: CL: switch is a good use case, inside title
20:37:37 [Italian-Chris]: cam: otherwise the <title>s would be titling the <switch> element itself
20:38:47 [Italian-Chris]: cl: xliff is an industry use case where markup is required
20:38:56 [heycam]: CM: are we agreed then that we want markup inside <title>?
20:39:01 [Italian-Chris]: yes
20:39:11 [heycam]: CM: is continuing to parse in "foreign content" mode what we want?
20:39:21 [heycam]: CM: (i think so)
20:39:42 [Italian-Chris]: cl: what does foriegn content mode do?
20:39:50 [Italian-Chris]: ok
20:40:40 [heycam]: CM: at one point there was talk about allowing only phrasing content inside <title>
20:40:46 [heycam]: CM: so <p> elements e.g. wouldn't be allowed
20:41:15 [Italian-Chris]: yeah but a quick display:block can screw that up
20:41:28 [heycam]: CM: only if it were rendered in a CSS context
20:41:31 [heycam]: CM: which <title> isn't
20:41:33 [Italian-Chris]: true
20:42:38 [heycam]: CM: we're at least settled on it not being plain text
20:42:42 [Italian-Chris]: CM: So it sounds like restricting it to plain text is not a good idea
20:42:53 [heycam]: CM: so someone should reply to the thread on www-svg that mentioned RCDATA to say that, perhaps
20:45:41 [Italian-Chris]: (discussion on member vs public mailing lists; public is preferred)
20:46:27 [heycam]: CM: i'll look into the parsing modes in html
20:46:33 [Italian-Chris]: cam: title in html ...
20:46:36 [heycam]: CM: to see what is appropriate to get <title> working as we want
20:46:55 [Italian-Chris]: ed: whats the current proposal in the svg-in-html spec?
20:47:09 [Italian-Chris]: ds: yes, stays as foreign content
20:48:34 [Italian-Chris]: cam: urgency?
20:48:38 [Italian-Chris]: ds: immediate
20:49:45 [Italian-Chris]: cam: state of dfeedback from mozilla?
20:49:55 [Italian-Chris]: ds: we have heard from some but not all of them
20:51:08 [heycam]: CM: discussions on points that we hadn't agreed upon haven't progressed really
20:51:20 [heycam]: CM: we did say at one point that we'd start off the proposal document being just the agered upon points
20:51:29 [heycam]: CM: but i don't want the others to be forgotten
20:51:46 [heycam]: CM: in a recent telcon we agreed that someone should collate the not-agreed-upon points, so we know where we're at
20:51:50 [heycam]: CM: but there wasn't an action assigned for that
20:51:55 [Italian-Chris]: we can add ednotes to log the unresolved parts. or create issues
20:52:28 [heycam]: CM: yes i think adding ednotes in the proposal document is reasonable
20:52:38 [heycam]: CM: so that when we submit it to the HTML WG they can see which things we haven't decided on yet
20:52:59 [Italian-Chris]: cl: agreed
20:53:09 [heycam]: CM: somebody needs to find those not-agreed-upon points though; it's not obvious to me right now what they are
20:53:34 [Italian-Chris]: zakim, list participants
20:53:34 [Zakim]: As of this point the attendees have been Shepazu, ed, [IPcaller], heycam, +39.524.9.aaaa, anthony, +39.524.9.aabb, ed____
20:53:49 [Italian-Chris]: zakim, +39 is Chris
20:53:49 [Zakim]: +Chris; got it
20:53:53 [Italian-Chris]: zakim, list participants
20:53:53 [Zakim]: As of this point the attendees have been Shepazu, ed, [IPcaller], heycam, +39.524.9.aaaa, anthony, +39.524.9.aabb, ed____, Chris
20:56:27 [Italian-Chris]: action: cameron make the spec golden wonderful
20:56:27 [trackbot]: Created ACTION-2501 - Make the spec golden wonderful [on Cameron McCormack - due 2009-03-30].
20:57:01 [heycam]: ACTION-2501: Add happy rainbow unicorns
20:57:01 [trackbot]: ACTION-2501 Make the spec golden wonderful notes added
20:57:03 [Italian-Chris]: action: cameron make the spec golden wonderful with ponies and rainbows, and twinkly glitter dust
20:57:03 [trackbot]: Created ACTION-2502 - Make the spec golden wonderful with ponies and rainbows, and twinkly glitter dust [on Cameron McCormack - due 2009-03-30].
20:58:13 [Italian-Chris]: action: cameron ad ednotes to the svg-in-html spec noting points where agreement is still lacking
20:58:13 [trackbot]: Created ACTION-2503 - Ad ednotes to the svg-in-html spec noting points where agreement is still lacking [on Cameron McCormack - due 2009-03-30].
20:58:27 [Italian-Chris]: close action-2501
20:58:27 [trackbot]: ACTION-2501 Make the spec golden wonderful closed
20:58:30 [Italian-Chris]: close action-2502
20:58:31 [trackbot]: ACTION-2502 Make the spec golden wonderful with ponies and rainbows, and twinkly glitter dust closed
20:59:35 [Italian-Chris]: adjourned
20:59:43 [Italian-Chris]: rrsagent, make minutes
20:59:43 [RRSAgent]: I have made the request to generate http://www.w3.org/2009/03/23-svg-minutes.html Italian-Chris
21:01:03 [Italian-Chris]: chair: Cameron
21:01:13 [Italian-Chris]: rrsagent, make minutes
21:01:13 [RRSAgent]: I have made the request to generate http://www.w3.org/2009/03/23-svg-minutes.html Italian-Chris
21:05:51 [Zakim]: -heycam
21:06:44 [Italian-Chris]: ok see you guys later
21:07:42 [Zakim]: -Chris
21:07:56 [Zakim]: -ed____
21:07:58 [Zakim]: -anthony
21:08:09 [Zakim]: -Shepazu
21:08:10 [Zakim]: GA_SVGWG()2:30PM has ended
21:08:11 [Zakim]: Attendees were Shepazu, ed, [IPcaller], heycam, +39.524.9.aaaa, anthony, +39.524.9.aabb, ed____, Chris
21:08:37 [anthony]: Zakim, bye
21:08:37 [Zakim]: Zakim has left #svg
21:58:09 [anthony]: shepazu, as I was saying on the call earlier the compositing module contains the alpha equations
21:58:19 [anthony]: and equations from the PDF spec
21:58:33 [anthony]: so for example if you look at soft-light
21:59:01 [anthony]: the PDF equation (non-alpha) is given, followed by the derived alpha equation
21:59:20 [anthony]: should I go ahead and remove the PDF equations from the blend modes?
22:00:30 [anthony]: because like you said the PDF spec is an ISO... the thing is though the PDF equations have been in there since Full 1.2 was drafted...
22:00:55 [anthony]: but I'll take them out if that's the easiest solution
22:01:05 [anthony]: anyway let me know what you think
22:02:01 [shepazu]: anthony: hmmm
22:02:50 [shepazu]: anthony: the best solution is where we provide all the equations necessary to implement SVG Compositing
22:03:09 [shepazu]: I honestly don't know enough about it to answer your question directly
22:03:34 [shepazu]: will taking out the existing equations leave the spec less complete?
22:10:22 [shepazu]: anthony: also... these equations you're calling "PDF equations"... are they correct? will the new equations supersede them, or supplement them?
22:11:48 [shepazu]: if they are still necessary or useful, we should keep them in, because by having them in the FPWD of SVG Full 1.2, they have implicitly given their consent for us to use them (I think)
22:27:17 [heycam]: heycam has joined #svg
22:35:52 [anthony]: shepazu, In answer to your questions: leaving the "'PDF" equations out just makes the spec look less complete. BUT implementers will have the required information for implementing it
22:36:06 [anthony]: The "PDF" equations serve as kind of a reference
22:37:16 [anthony]: The "PDF" equations are correct. Adobe provided corrections to the "PDF" equations. The ones I've added provide more information
22:38:21 [anthony]: In a way they are useful, it's just the new PDF equations are in the ISO standard where as the old ones don't
22:41:42 [shepazu]: anthony: you have a minute to chat via skype?
22:41:48 [anthony]: sure
22:42:18 [shepazu]: what's your id?
22:42:31 [anthony]: ossarga
22:44:03 [shepazu]: says you're not online
22:44:09 [anthony]: just logged in
22:45:02 [anthony]: what's your id?
22:46:01 [shepazu]: schepersda, I think
22:51:34 [anthony]: http://www.w3.org/TR/2004/WD-SVG12-20041027/rendering.html
22:52:26 [anthony]: http://dev.w3.org/SVG/modules/compositing/master/
23:15:49 [anthony]: http://www.w3.org/Graphics/SVG/WG/track/issues/2095
23:15:53 [anthony]: http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0032.html
23:20:35 [anthony]: http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0036.html
23:20:55 [heycam]: RRSAgent, bye
23:20:55 [RRSAgent]: I see 4 open action items saved in http://www.w3.org/2009/03/23-svg-actions.rdf :
23:20:55 [RRSAgent]: ACTION: doug to add nearest-neighbor as a value of image-rendering to Core [1]
23:20:55 [RRSAgent]: recorded in http://www.w3.org/2009/03/23-svg-irc#T19-53-22
23:20:55 [RRSAgent]: ACTION: cameron make the spec golden wonderful [2]
23:20:55 [RRSAgent]: recorded in http://www.w3.org/2009/03/23-svg-irc#T20-56-27
23:20:55 [RRSAgent]: ACTION: cameron make the spec golden wonderful with ponies and rainbows, and twinkly glitter dust [3]
23:20:55 [RRSAgent]: recorded in http://www.w3.org/2009/03/23-svg-irc#T20-57-03
23:20:55 [RRSAgent]: ACTION: cameron ad ednotes to the svg-in-html spec noting points where agreement is still lacking [4]
23:20:55 [RRSAgent]: recorded in http://www.w3.org/2009/03/23-svg-irc#T20-58-13