14:07:18 <RRSAgent> RRSAgent has joined #svg
14:07:18 <RRSAgent> logging to http://www.w3.org/2009/06/08-svg-irc
14:07:20 <trackbot> RRSAgent, make logs public
14:07:22 <trackbot> Zakim, this will be GA_SVGWG
14:07:22 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
14:07:23 <trackbot> Meeting: SVG Working Group Teleconference
14:07:23 <trackbot> Date: 08 June 2009
14:07:36 <heycam> RRSAgent, this meeting spans midnight
14:18:58 <heycam> Zakim, pick a victim
14:18:58 <Zakim> sorry, heycam, I don't know what conference this is
14:19:35 <jwatt> jwatt has joined #svg
14:20:19 <shepazu> Zakim, this will be SVG
14:20:19 <Zakim> I do not see a conference matching that name scheduled within the next hour, shepazu
14:20:36 <ChrisL> ChrisL has joined #svg
14:21:45 <shepazu> Zakim, this is SVG
14:21:45 <Zakim> sorry, shepazu, I do not see a conference named 'SVG' in progress or scheduled at this time
14:21:57 <ChrisL> zakim, remind us in 8 hours to go home
14:21:57 <Zakim> ok, ChrisL
14:40:10 <ChrisL> (discussion of agenda and priorities)
14:40:28 <ChrisL> Meeting: SVG WF f2f
14:41:04 <ed> trackbot: close ACTION-2594
14:41:04 <trackbot> ACTION-2594 Raise an issue to determine the encoding of external <script> closed
16:16:09 <shepazu> Topic: Pointer-events
16:16:10 <shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_Edition#Doug
16:16:15 <ed> Chair: heycam
16:16:17 <ChrisL> Chair: Cameron
16:16:21 <shepazu> http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-errata.html#capturing-pointer-events-zero-opacity
16:16:27 <ChrisL> ScribeNick: jwatt
16:16:31 <shepazu> http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-errata.html#clippath-affects-bounding-boxes
16:16:32 <ed> Present: CL, ED, DS, JW, CM
16:16:40 <shepazu> http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-errata.html#clippath-pointer-events
16:27:34 <shepazu> http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
16:59:26 <ChrisL> filters in safari (but out of date) http://webkit.org/projects/svg/status.xml
17:00:33 <heycam> [doug discusses the problem, jwatt will gather his thoughts and we'll return to the problem later]
18:39:59 <ed> ed has joined #svg
18:50:26 <heycam> ScribeNick: heycam
18:50:34 <heycam> Topic: Some 1.1 errata
18:50:55 <jwatt> http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-errata.html#mention-live-values
18:51:52 <heycam> JW: first, about the second change (initialize) the text added
18:51:58 <heycam> JW: in mozilla, there's no heavyweight dom there
18:52:05 <heycam> ... so these list objects are created on demand
18:52:21 <heycam> ... if we insert an item into the list, we just copy the value in and put it into our compact internal representation
18:52:36 <heycam> ... so the text about it being a copy and not a reference isn't good
18:52:57 <heycam> CL: we should just clarify if these are just handles to the values
18:53:19 <heycam> ED: in opera, too. the list types say that you have to take the objects out of any previous lists they're in. so there's no overhead at all for us to move them between lists.
18:53:25 <heycam> ... making the lists live is cheap for us
18:53:49 <heycam> JW: so they're live in one direction only? if you get the object, say item #2 in the list, and get an object back, if you change the object it will change the attribute that it's mapped to?
18:53:50 <heycam> ED: yes
18:54:00 <heycam> JW: but only the object that you asked for has a reference back to the element
18:54:24 <heycam> ... you can change the object you get back, e.g. change the SVGTransform
18:54:28 <heycam> ... because that object has a handle back to the element
18:54:47 <heycam> ... but we don't want the elements to have memory for all of the pointers to the objects
18:55:18 <heycam> CM: if you call getItem(0) twice in a row you get back two different objects?
18:55:22 <heycam> JW: for some of our list classes yes
18:55:35 <heycam> ... we could have one pointer to a tearoff wrapper object
18:55:42 <heycam> ... for what was being asked
18:56:20 <heycam> ... i don't particularly like that they're different objects
18:56:29 <heycam> ... but people don't in general check the identity of these objects
18:56:47 <heycam> ... so that's why we went with this optimisation
18:56:59 <heycam> ... adding text like in this erratum means it has to be the same object
18:57:13 <heycam> CM: but we already say that objects can't be in two lists
18:57:22 <heycam> ED: right, but you only need one pointer back to the list that it's in
18:57:44 <heycam> JW: but also you need to have the list keep a pointer to the list item that was asked for
18:58:12 <heycam> CM: it's only one pointer
18:59:38 <heycam> JW: i'm thinking also about consistency with other things, like rectElt.x
18:59:42 <heycam> ... should that return the same object all the time?
19:00:23 <heycam> ED: so you're concerned about having an element with an attribute x="", and use elt.x.baseVal to get to it, then change it with setAttribute(), would it update the object?
19:00:28 <heycam> JW: no that would, that's ok
19:00:48 <heycam> ... for an SVGLength object, it keeps a reference to the element, but the element doesn't keep a reference to the SVGLength object itself
19:00:56 <heycam> ... it saves memory on each element object
19:01:27 <heycam> ... if every time you ask for .x.baseVal you get the same SVGlength object, then you need to start keeping references
19:02:06 <heycam> ... i'm not concerned about cpu so much, just memory
19:04:18 <heycam> ... i withdraw my objection, i can use a hash table to store the tearoff objects
19:07:10 <jwatt> http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-errata.html#container-element-rewording
19:08:17 <heycam> JW: apart from two obvious typo changes, it changes "can" to "will"
19:08:24 <heycam> ... (disable progressive rendering)
19:08:35 <heycam> ... and adds "if that container includes elements that reference external resources"
19:08:47 <heycam> ... if eRR="true"
19:08:52 <heycam> CL: which i think is the intent of the original text
19:09:06 <heycam> ... so just setting it won't freeze rendering, only if it's triggered will it do that
19:09:23 <heycam> JW: my issues with that is that it will disable prog rendering but only if the container has external refs
19:09:31 <heycam> ... so in mozilla, chunks come in over the network and it paints as you go
19:10:12 <heycam> CL: that's fine, you go along and when you find the missing external reference, you stop rendering there
19:10:25 <heycam> CM: it doesn't remove the rendering for the preceding elements in the container
19:10:47 <heycam> CL: it's analagous to well formedness error handling
19:11:00 <heycam> ... there are two ways to interpret what's written
19:11:30 <heycam> ... 1) stop rendering just when you find a missing external reference, or 2) disable rendering of the whole container when you find a child missing external reference
19:16:12 <heycam> DS: if eRR="true" on the root, then nothing should be rendered until all external refs have downloaded, imo
19:16:23 <heycam> ... don't want the user to think they've got the whole document if they haven't
19:17:49 <heycam> ... i think the default should be that eRR="true" simply stops the rendering
19:18:06 <heycam> ... but progressiveRendering="true" (if that existed) would allow progressive rendering
19:19:08 <heycam> ... JW said yesterday that another use case is to delay script so that you can get at contentDocuments and so on
19:20:52 <heycam> [some discussion of SVGLoad delaying]
19:21:10 <heycam> CM: so with eRR="false", the default, SVGLoad won't be delayed for external resources
19:21:13 <heycam> ... which is unlike HTML's load
19:21:57 <heycam> [some discussion of the usefulness of SVGLoad being dispatched to elements without external refs]
19:22:13 <heycam> CM: just about every element can have external refs, like fill="url(...)"
19:22:28 <heycam> JW: i want SVGLoad to be dispatched only AT_TARGET (with no capturing)
19:24:00 <heycam> CM: but progressiveRendering="" doesn't exist, and we can't add that for a second edition
19:24:04 <heycam> ... or in an erratum
19:27:52 <heycam> CM: who implements eRR=""?
19:27:54 <heycam> ED: opera does
19:32:26 <ed> http://dev.w3.org/SVG/profiles/1.2T/test/svg/struct-progressive-201-t.svg - http://dev.w3.org/SVG/profiles/1.2T/test/svg/struct-progressive-204-t.svg
19:44:53 <jwatt> here's my eRR test:
19:44:57 <jwatt> <svg xmlns="http://www.w3.org/2000/svg"
19:44:59 <jwatt>      xmlns:xlink="http://www.w3.org/1999/xlink"
19:45:01 <jwatt>      externalResourceRequired="true">
19:45:02 <jwatt>   <rect width="100%" height="100%" fill="lime"/>
19:45:04 <jwatt>   <image xlink:href="doobydoo" width="100" height="100"/>
19:45:05 <jwatt>   <rect width="100%" height="100%" fill="red"/>
19:45:07 <jwatt> </svg>
19:45:09 <jwatt> shows red in Opera 10 beta
19:45:39 <jwatt> so it looks like it doesn't implement externalResourceRequired at all
19:51:24 <eseidelDesk> eseidelDesk has joined #svg
19:54:27 <heycam> [after some discussion, we decide to move this erratum back to draft and discuss the larger issue of eRR/progressive rendering at a later stage]
19:55:41 <heycam> ACTION: jwatt to move the eRR erratum back to draft
19:55:41 <trackbot> Created ACTION-2600 - Move the eRR erratum back to draft [on Jonathan Watt - due 2009-06-15].
19:56:05 <heycam> RRSAgent, make minutes
19:56:05 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/08-svg-minutes.html heycam
19:57:19 <jwatt> http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-errata.html#container-element-rewording
20:01:57 <ChrisL> created ISSUE-2277
20:01:58 <ChrisL> eRR useful?
20:01:58 <ChrisL> Is externalResourceRequired useful?
20:02:13 <jwatt> http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-errata.html#svgload-does-not-bubble
20:02:47 <heycam> JW: the reason svg doesn't implement SVGLoad firing on every element is that it would have a negative impact on load time
20:02:54 <heycam> ... even if it doesn't bubble, it still has to go through the whole height of the tree for each element
20:03:01 <heycam> ... since it still has capture phase
20:03:20 <heycam> ... a possible solution is to make SVGLoad only have an AT_TARGET phase, no capture, no bubble
20:03:23 <heycam> ... there are no facilities in DOM 3 Events to say you can do that
20:03:25 <heycam> ... but it could be added
20:03:51 <heycam> ... currently for this erratum, the current text implies there is no capture or bubble phase, but the proposed changed text makes it have a capture phase
20:04:01 <heycam> ... so maybe this change makes things worse
20:04:33 <heycam> ... when it says that on the 'g' it won't be fired, it doesn't say it won't be fire in the bubbling phase, it says it won't be fired
20:04:51 <heycam> ... so it implies there is no capture phase
20:05:40 <heycam> ... with initEvent() there's no param to say there's no capture phase
20:06:00 <heycam> ... (there's a canBubble arg)
20:06:27 <heycam> ... olli pettay agreed that it's a bit hacking, but maybe having a canCapture attribute on Event (or setCaptures() method) could be used here
20:06:36 <heycam> ... so i wonder if we should make the change in this erratum
20:18:52 <heycam> [jwatt does some testing]
20:20:21 <heycam> JW: we dispatch SVGLoad only to <svg> elements, and any other elements that have onload="" attributes
20:20:33 <heycam> ... registered event listeners don't affect it
20:22:50 <heycam> ... and onload="" attributes only fire for bubbling/at_target phase
20:26:52 <heycam> CL: i agree that dispatching capture phase listeners for svgload events on every element is bad
20:27:06 <heycam> JW: should we leave the text suggest that there isn't a capture phase?
20:27:10 <heycam> CL: but dom events doesn't allow that
20:27:33 <heycam> ... it does seems like the best way would be to fix dom 3 events
20:27:33 <heycam> ... but then that would only affect SVG 2 (since 1.1 references dom 2 events)
20:27:42 <heycam> JW: but if we apply this erratum, then we would conflict with our future SVG 2
20:30:32 <heycam> ... how about we dispatch events to all elements under a certain container if a capture event listener is registered on that
20:30:47 <heycam> ... so specifically using addEventListener for a capture listener
20:31:22 <heycam> ... my concern that the default cause of onload="" on the root <svg> not be hammered
20:31:29 <heycam> ... i'm less concerned with the use of addEventListener
20:31:36 <heycam> CL: would that still require the erratum?
20:31:46 <heycam> JW: it's covered under the original
20:31:57 <heycam> ... i'm just wondering if my concerns about performance are legitimate
20:32:14 <heycam> ... all the bubbling listeners, we don't need to dispatch load events to their children, since there's no bubble phase
20:36:17 <heycam> [we'll return to this issue later]
20:55:32 <ed> trackbot, close ACTION-2575
20:55:32 <trackbot> ACTION-2575 Remove the negative index size error exception on list interface methods and mention in changes appendix in 1.1SE closed
20:57:42 <heycam> Topic: CSS
20:57:52 <heycam> CL: the spec which contains calc, values and units, i'm an editor of
20:58:07 <heycam> ... i can change that to be in line with implementor experience
20:58:33 <heycam> DS: i wanted to know how they felt about using calc and extending it
20:59:03 <heycam> CL: they were happy about svg using it, but open to it being changed/extended based on what implementors wanted to do
20:59:12 <heycam> ... there was no agreement on what level the expressions should be (just constant, or more)
21:08:37 <heycam> ... on web fonts, i had raised an issue on the variability of the font weight stuff
21:08:56 <heycam> ... i argued that platform problems shouldn't matter
21:09:09 <heycam> ... now the module has an appendix saying to watch out for issues on certain platforms
21:09:26 <heycam> ... in css2, it says there are 9 different weights and you fill in the holes using some algorithm
21:09:34 <heycam> ... but it says at the end that that's just an example of matching weights
21:10:05 <heycam> ... in jdaggett's draft, there was some vague wording using SHOULDs
21:10:17 <heycam> ... but there's a better algorithm later in the spec which is fine
21:10:24 <heycam> ... so there was no issue there, and it's testable, so i'm happy with that
21:10:35 <heycam> ... i've satisfied myself that it gives mostly the same results as the old alg
21:10:47 <heycam> ... john had xhtml test cases for assertions in the spec
21:10:49 <ed> CSS3 webfonts: http://dev.w3.org/csswg/css3-fonts/
21:11:11 <heycam> ... in a month or two they'll be ready to convert to svg tests
21:11:18 <heycam> ... there are some issues with font-variant smallcap
21:11:35 <heycam> ... that was removed, but now it's back
21:12:24 <heycam> CM: do descriptors override data in the font?
21:12:25 <heycam> CL: yes
21:15:55 <heycam> ... xsl still want an xml representation of @font-face
21:22:34 <ed> ed has joined #svg
21:26:10 <heycam> ... there was a proposal to add cmyk to css3 gcpm
21:27:23 <heycam> ... it didn't distinguish between calibrated cmyk and device cmyk
21:27:35 <heycam> ... i have an action to suggest better syntax, which i'll present tomorrow for svg print
21:27:38 <heycam> ... xsl also want it
21:35:03 <heycam> ... there was also a bit of discussion about layout
21:35:07 <heycam> ... flexible boxes
21:35:14 <heycam> ... summarizes the xul model
21:36:53 <heycam> JW: any discussion about non-xul models?
21:36:54 <heycam> CL: no
21:37:43 <heycam> ... the one complaint mentioned in the f2f was that you need to put in many spacer elements to stretch
21:38:01 <heycam> CM: elt::after { flex: something }?
21:39:18 <heycam> JW: is there any plan to get markup tag names?  or would people use <span style='flex: ...'>?
21:39:36 <heycam> CL: we could add a bunch of elements with default styles
21:43:34 <ChrisL> http://dev.w3.org/cvsweb/csswg/css3-flexbox/
21:49:11 <heycam> http://www.w3.org/2009/06/05-CSS-minutes.html
21:58:00 <ed> http://twitpic.com/6nuje
22:05:38 <heycam> Topic: MAE
22:05:43 <heycam> CL: nobody's editing this
22:05:50 <heycam> CM: how much overlap does it have with progress events?
22:05:52 <heycam> CL: a lot
22:06:09 <heycam> ED: mae is geared more towards real time video streaming
22:07:41 <ChrisL> http://www.w3.org/Graphics/SVG/Group/repository/spec/streaming-events/publish/StreamingEvents.xhtml 
22:07:57 <ChrisL> (meber only, sorry)
22:09:29 <ChrisL> so to what extent does that overlap with html5?
22:14:07 <ed> http://dev.w3.org/html5/spec/Overview.html#mediaevents
22:21:58 <Zakim> ChrisL, you asked to be reminded at this time to go home
22:22:47 <heycam> DS: html5 duplicates the functionality of mae
22:23:57 <heycam> ... so before we move forward on mae we should email the htmlwg and see what they propose be done
22:24:11 <heycam> ... maybe those events defined in html should be split out into a spec so that it can apply to svg <video> etc.
22:29:35 <heycam> ACTION: Doug to ask the htmlwg about mae vs html5 media events
22:29:36 <trackbot> Created ACTION-2601 - Ask the htmlwg about mae vs html5 media events [on Doug Schepers - due 2009-06-15].
22:29:55 <heycam> RRSAgent, make minutes
22:29:55 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/08-svg-minutes.html heycam
22:30:30 <heycam> Zakim, bye
22:30:30 <Zakim> Zakim has left #svg
22:30:35 <heycam> RRSAgent, bye
22:30:35 <RRSAgent> I see 2 open action items saved in http://www.w3.org/2009/06/08-svg-actions.rdf :
22:30:35 <RRSAgent> ACTION: jwatt to move the eRR erratum back to draft [1]
22:30:35 <RRSAgent>   recorded in http://www.w3.org/2009/06/08-svg-irc#T19-55-41
22:30:35 <RRSAgent> ACTION: Doug to ask the htmlwg about mae vs html5 media events [2]
22:30:35 <RRSAgent>   recorded in http://www.w3.org/2009/06/08-svg-irc#T22-29-35