since it has dimensions if you clicked inside that

12:47:39 ... it dispatches the event 12:47:51 CC: Even with transparent background? 12:47:52 DS: Yes 12:48:04 ... so question is have to establish what the default is 12:48:08 ... and how do you change it 12:48:38 ED: We had something like FireFox 12:48:46 ... but we asked to change it 12:48:59 CC: Have to be consistent with SVG in HTML and SVG in SVG 12:49:04 DS: We need to look at the spec 12:49:18 ... currently, Opera and Webkit behave one way with inline SVG 12:49:27 ... the SVG root does not intercept events 12:49:53 ... it passes them through 12:50:37 CC: Nothing happens in the SVG context 12:50:41 ... regards to this event 12:50:48 DS: SVG spec is moderately clear on this 12:51:18 http://www.w3.org/TR/SVG/interact.html#UIEventProcessing 12:51:29 CC: IE9 is doing as Opera is doing 12:51:44 DS: I would prefer that inline and referenced SVG behaved the same way 12:51:52 ED: Changing that now 12:51:56 ... would be bad for SVG in general 12:52:08 ... people have come to expect certain behaviour 12:59:07 All: [16.5 Read through Processing order for user interface events] 13:00:05 DS: Clarify that this section is about hit testing and not propagation 13:00:13 ED: Would be better if there was a graph here 13:00:32 DS: Problem with the section is it confuses hit testing, event propagation and order of processing 13:01:35 ED: It's trying to describe a flowchart or something 13:02:10 DS: Doesn't talk about things like selecting graphics elements 13:03:13 ... when SVG was written we didn't talk about default view or window 13:03:36 ED: How would you change this? 13:03:42 DS: Instead of processing order 13:03:48 ... I would break it down to a section on hit testing 13:04:04 CC: Something has been hit? something not hit? 13:04:14 DS: Yes, if something hit. Go through and process actions 13:04:21 ... If it has not been hit 13:04:26 ... give a context menu 13:04:34 ED: Would be nice to have an SVG graph 13:04:45 ... down the side 13:04:51 ... that matches the text 13:05:09 AG: I agree, much easier to read and implement 13:06:27 ED: It's pretty clear what needs to be done 13:07:08 DS: So we are going to do this in SVG 1.1 Full 2nd edition 13:07:17 CC: We have this text in Tiny 1.2 13:07:29 DS: We pulled out the part on pseudo classes 13:07:49 CC: Has this other bit - 13.8 Event dispatching 13:07:52 ED: It's different 13:07:59 ... but might need an errata on Tiny 1.2 13:09:09 ACTION: Doug to Clarify section 16.5 Processing order for user interface events relating to problems in ISSUE-2364 13:09:09 Created ACTION-2834 - Clarify section 16.5 Processing order for user interface events relating to problems in ISSUE-2364 [on Doug Schepers - due 2010-09-10]. 13:09:18 CC: What about key events? 13:09:24 DS: That's another matter 13:09:35 ... that's why saying this is about hit testing is relevant 13:09:52 CC: That's a whole different discussion. But at some point someone should investigate this 13:10:19 DS: ED you're saying for security reasons, you're not going to allow events to pass through in an iFrame 13:10:26 ... It's the same in object 13:10:31 ... and if you change the one 13:10:36 ... people would expect the other to change 13:11:01 ED: If you have an element it's like a static image with no script and no events 13:11:08 ... so it's the HTML you're getting events on 13:11:16 DS: Do you treat image and object the same? 13:11:21 ED: No 13:11:36 ED: I assume object, embed and iframe behave the same 13:11:42 ... embed not so much 13:11:56 ... object and iframe is mostly the same I think 13:12:26 CC: What about SVG 13:12:33 ED: It's defined in the spec 13:12:42 ... but should behave the way as 13:12:52 DS: I understand why are you doing this 13:13:00 ... but for content creation it's a pain 13:13:21 ... say you have some SVG and you want to click through on the element and where there isn't SVG content you 13:13:25 ... want to get to the HTML 13:13:41 ED: So you if you have transparency you get the HTML? 13:13:52 ... Does the same thing happen for PNG? 13:13:59 ... So we treat it the same 13:14:06 DS: I'm talking for object here 13:14:12 ED: Not sure we are talking about the same thing 13:14:22 DS: Look at my example 13:17:59 ...We need to have a larger discussion about clicking through the transparent content would be a problem 13:19:40 AG: This would be a good thing to discuss at TPAC 13:20:56 CC: When the SVG is in the document it's behaviour is the same as a

13:21:19 DS: I'm saying for the inline case 13:22:04 ... Maybe this needs to happen during a telcon 13:22:30 ... because we want all browsers to have the correct behaviour 13:24:23 ED: There might be use cases the other way 13:24:37 ... not just having events go through 13:24:57 DS: I said you set pointerEvents to all 13:25:34 ... as I suggested 13:26:41 ED: I just think this is something that goes beyond SVG content 13:27:42 CL: Could probably put that wording in the integration spec 13:29:04 DS: A quick test that mouse move on an empty SVG document intercepts i.e. the root dispatches the event 13:29:26 ... All the modern browsers I tested 13:29:54 ... this is contrary to ASV and seems to be contrary to the spec 13:30:03 ... but is consistent with HTML 14:05:10 ACTION: Doug to Add a table to the integration document about the embedded and inline SVG with regards to pointer events on the SVG root 14:05:11 Created ACTION-2835 - Add a table to the integration document about the embedded and inline SVG with regards to pointer events on the SVG root [on Doug Schepers - due 2010-09-10]. 14:05:24 ISSUE-2363? 14:05:24 ISSUE-2363 -- Last Call Comment: Reconcile 'stroke' presentation attributes on -- raised 14:05:24 http://www.w3.org/Graphics/SVG/WG/track/issues/2363 14:05:46 ED: I think Cameron and me have responded to this on the list 14:05:51 ... saying what we have now in the spec 14:06:12 ... is a lot better than what was in previous 1.1 spec 14:06:29 ... so in the previous 1.1 spec we had DTD to say what attributes where on each element 14:06:45 ... so now have something that can be expanded and is more readable and made it more clear 14:06:52 ... that presentation attributes can be specified anywhere 14:07:05 ... even if they don't apply to it 14:07:26 CL: So specified and applied to are distinguished? 14:07:29 ED: Yes 14:07:36 CL: Therefore we should reject the comment 14:07:49 s/apply to it/apply to the element it's specified on/ 14:08:00 ... because it's a no change required 14:08:36 CL: The issue was raised by Doug 14:10:05 http://www.w3.org/TR/SVG11/masking.html#ObjectAndGroupOpacityProperties 14:10:07 DS: Please show me where it's specified 14:10:11 ED: That's one example 14:10:17 ... it clearly says applies to 14:10:27 http://www.w3.org/TR/SVG/struct.html#ImageElement 14:10:27 DS: However if you go to here 14:10:43 DS: And you click on the, presentation attributes, it lists it 14:10:48 CL: That's right 14:10:51 ... exactly 14:10:55 ... it doesn't apply to it 14:11:16 DS: I was talking to someone on IRC and they were trying to do this 14:11:23 ... (stroke image element) 14:11:33 ... and they go to the presentation attributes they can set on the elemnt 14:11:44 s/elemnt/element/ 14:11:59 DS: I think we should change the spec to things that have an effect on the element 14:12:08 CL: So it's currently done the other way 14:12:14 ... for each property it says what it applies to 14:12:26 ... this is an argument we've had since the entire life time on the SVG 14:13:02 ... then others say somethings should be set only on an element only 14:13:14 ... in some cases things would be disallowed because when children 14:13:22 ... were placed in the element 14:13:29 ... sometimes things apply 14:13:49 DS: Maybe it's the choice on how fine grain things are categorised 14:14:06 CL: This is going against a decision that was made 2 -3 years ago 14:14:11 ... it's a huge change 14:14:15 ... to be doing this 14:14:18 DS: Let's be clear 14:14:22 ... we all agree it is confusing 14:14:28 CL: It could be confusing 14:14:32 ED: In some cases yes 14:14:44 DS: It has been proven to be confusing to some people 14:14:47 ... including me 14:15:33 CL: Presentation attributes are in the form of properties 14:15:52 tbah has joined #svg 14:16:00 CC: As an implementer it reads well 14:16:03 ... as an author 14:16:06 ... it probably doesn't 14:16:13 ... what matters at least someone can be confused 14:16:21 ED: What are you suggesting? 14:16:22 tbah has joined #svg 14:16:34 DS: Is it work the extra time to do this, to change it 14:16:41 CL: Change how? 14:17:05 DS: So, maybe in this case if we wanted to do the minimum work if it could some how be styled differently 14:17:09 ... if it has an effect an element 14:17:15 ED: Yes, that would be nice 14:17:18 ... make them bold 14:17:23 ... if they applied to the element 14:17:31 CC: As long as it is editorial 14:17:38 CL: It will be editorial 14:17:57 ... with all the presentation attributes it is a link which takes you to the definition 14:18:07 DS: How is this generated? 14:18:16 ED: It's generated from the XML, IDL 14:19:32 CL: Another thing we could do to make the spec better 14:19:43 ... is to say the difference between applies to and specified on 14:20:35 CC: Adding the new sentence you said will help 14:20:44 ... but changing the style and linking to that 14:20:49 ... would at least give a hint that it's not that simple 14:21:02 ... having it in bold would say would it apply 14:21:11 ... it's precise and it's clear 14:21:16 ... but it doesn't speak to most of the people 14:21:29 ED: My objection is don't we have that sentence somewhere? 14:21:38 ... styling? 14:21:51 ... I would not want to have two sentence that say two different things about the same topic 14:21:57 DS: There is a sentence here in styling 14:22:01 ... two links away 14:22:32 ED: Specificity of 0 is in there 6.4 14:22:35 [[ 14:22:43 For user agents that support CSS, the presentation attributes must be translated to corresponding CSS style rules according to rules described in Precedence of non-CSS presentational hints ([CSS2], section 6.4.4), with the additional clarification that the presentation attributes are conceptually inserted into a new author style sheet which is the first in the author style sheet collection. The presentation attributes thus will participate in the CSS2 cascade 14:22:43 ]] 14:23:06 CL: The section on presentation attributes could have it in there 14:23:14 DS: That would be two links away 14:23:15 http://www.w3.org/TR/SVG/intro.html#TermPresentationAttribute 14:23:21 ... could have it here so that it's one link away 14:24:48 DS: Could say "Note not all presentation attributes specified on an element will apply to the element. For a list of elements that a property applies to see... blah" 14:26:33 ... how hard would it be style them bold or normal? 14:26:39 ED: I think that would be a bit of work 14:26:48 ... I don't think we have a list or things 14:26:58 ... adding the sentences here would be less work 14:27:21 DS: In SVG 2. I would like us to re examine if we can have a stroke around the edge of an image? 14:27:28 CL: Wouldn't that be a border? 14:27:54 DS: Depends on if we allow padding around it and borders have different properties to borders 14:29:09 ACTION: Chris to Include the above disclaimer about the applicability of presentation attributes on elements 14:29:09 Created ACTION-2836 - Include the above disclaimer about the applicability of presentation attributes on elements [on Chris Lilley - due 2010-09-10]. 14:29:47 Topic: SVG 1.1 2nd Edition Candidate Recommendation 14:35:08 tbah has joined #svg 14:38:45 cyril has joined #svg 15:12:03 ChrisL has joined #svg 15:12:15 back from break 15:14:13 DS: First we need to agree on the set of tests that make up the SVG 1.1 2nd edition test suite 15:16:00 CL: Previously, the action of building the test suit generated all the files to do the testing 15:16:20 f1lt3r has joined #svg 15:16:32 AG: I believe the reporting stuff is working 15:16:54 ACTION: Anthony to Check if report generation for the test suite is working and report back 15:16:54 Created ACTION-2837 - Check if report generation for the test suite is working and report back [on Anthony Grasso - due 2010-09-10]. 15:17:32 AG: So the way the test suite generation scripts work is you have a list of tests and every component in the test suite 15:17:42 ... is generated according to that list 15:20:39 DS: For all the tests we don't have results on, each implementer can run the tests and report back to us 15:25:14 ACTION: Doug to Run the tests on Safari on Mac 15:25:14 Created ACTION-2838 - Run the tests on Safari on Mac [on Doug Schepers - due 2010-09-10]. 15:25:31 ACTION: Chris to Run the tests on Firefox on Windows 15:25:32 Created ACTION-2839 - Run the tests on Firefox on Windows [on Chris Lilley - due 2010-09-10]. 15:26:01 ACTION: Erik to Run the tests on Opera 15:26:01 Created ACTION-2840 - Run the tests on Opera [on Erik Dahlström - due 2010-09-10]. 15:26:35 ACTION: Cyril to Run the tests on GPac 15:26:36 Created ACTION-2841 - Run the tests on GPac [on Cyril Concolato - due 2010-09-10]. 15:26:50 ACTION: Tav to Run the tests on Inkscape 15:26:50 Sorry, couldn't find user - Tav 15:27:12 ACTION: Tavmjong to Run the tests on Inkscape 15:27:12 Created ACTION-2842 - Run the tests on Inkscape [on Tavmjong Bah - due 2010-09-10]. 15:33:41 Topics: Connectors 15:34:08 CL: So that was news to me that you could make a complex path going through a few points 15:36:18 TB: We have a sophisticated routing than what's proposed. But because the path between objects can be enhanced 15:36:29 ... we wouldn't be losing anything that's already in inkscape 15:39:00 DS: [Demo's current connectors implementation] 15:43:02 ... Connector goes from centroid to centroid 15:44:14 AG: This could be difficult to calculate 15:44:26 ... particularly if you're clipping parts of an object out 15:44:45 CL: Why not the center of the bounding box? 15:45:35 cyril has joined #svg 15:48:23 DS: Different possible syntax for point 15:48:32 ... if you're looking at the bounding box of the parent 15:48:50 ... it'd be useful to allow a percentage of the parent bounding box 15:49:41 ... A port has a specific role of point 15:49:49 ... it is a child of a shape 15:50:07 ... point is a non rendering element 15:50:15 ... you can style it with a marker 15:50:23 CL: Effectively it's a zero length line 15:51:32 DS: Each node being linked to has a port that will be preferential to where connection is made 15:51:54 ... it will always go to the nearest between two ports 15:51:59 TB: Can you specify 15:52:40 ... the port? 16:02:13 DS: Yes 16:02:37 ... I've got a sample implementation and done some work on this 16:02:49 ... I want to know if we agree to work on this 16:03:34 CL: Do we agree that this is the direction we should go in? 16:03:52 CC: How would you add it, if you were to add it? 16:04:00 ... a separate module? 16:04:03 DS: Yes 16:04:09 ... I'd intend for it to be part of SVG 2 16:04:52 ... we've had a level of requests for this 16:05:00 TB: We've had requests for this as well 16:05:55 DS: This is a common case I've seen again and again 16:06:23 ED: Not convinced yet 16:06:41 DS: This is does not add, drag and drop, it does not add routing 16:07:04 ED: Does it add any dependencies that you need to resolve? 16:07:16 DS: There are very well defined dependencies 16:07:24 ... when a shape is moved 16:07:31 ... the connection changes 16:07:45 ED: We have to track a lot of dependencies already 16:07:51 ... the less we need to do the faster it will be 16:08:01 ... the graph of dependencies grows 16:08:11 ... you can do this in script 16:08:18 ... just not convinced 16:08:21 DS: Yes, you're right 16:08:39 ... it's a common use case that is not easy to do in script 16:08:53 ... it doesn't establish the semantics and behaviour 16:09:44 ... I think it is a compelling feature that makes SVG very attractive for use 16:10:49 CC: You could do the opposite 16:10:52 ... and say this is a line 16:11:00 ... and this is connector 16:11:05 ... and then put a marker on it 16:11:24 ... This could also be done with Cameron's constraints 16:11:48 DS: This is a subsection of constraints. Gives people a lot of power to build things in SVG 16:12:07 ... getting the connector for free gives people something accessible 16:12:39 ... and graphics like this will not be accessible without this 16:12:48 CC: Couldn't you do this with a line 16:12:53 ... and give it a role of connector? 16:13:15 DS: Yes, but it doesn't give the author any reason to do this 16:14:23 ED: Why does it have to be in SVG? 16:14:27 ... why not stand alone? 16:14:31 ... in a completely different spec 16:14:38 ... used in other languages 16:14:44 DS: What other languages? 16:14:52 ED: Connect this div to another div 16:14:59 DS: But that is not a visual language 16:15:03 ... SVG is a visual language 16:17:21 ... this would pretty much the highest thing we would have at this level 16:17:39 CC: There are two parts the rendering constraints and the semantics 16:18:13 ... I think we can have either the semantics or the constraints 16:22:11 CL: So I think that he is arguing 16:22:19 ... that use instead of 16:22:22 ... point is fine 16:23:35 ED: We should close for the day 16:23:41 ... and continue discussion later 16:24:32 RRSAgent, make minutes 16:24:32 I have made the request to generate http://www.w3.org/2010/09/03-svg-minutes.html anthony 16:24:39 Zakim, bye 16:24:39 Zakim has left #svg 17:17:52 ChrisL, you asked to be reminded at this time to go home 19:14:35 cyril has joined #svg 19:19:49 f1lt3r has joined #svg