00:44:18 ed has joined #svg 00:46:08 ChrisL has joined #svg 01:09:41 heycam, you asked to be reminded at this time to raid the fridge 01:23:13 fat_tony has joined #svg 01:28:30 the inheritance rules are slightly different for 'd' and child content on 01:28:45 for 'd' attributes particularly: "The resulting, transformed path specification is rendered as if it were a 'path' element, using the styling properties that apply to the characters which correspond to the given glyph, and ignoring any styling properties specified on the 'font' element or the 'glyph' element." 01:29:09 heycam has joined #svg 01:48:55 ChrisL2 has joined #svg 01:58:30 Zakim has left #svg 02:47:22 rrsagent, make minutes 02:47:22 I have made the request to generate http://www.w3.org/2009/09/27-svg-minutes.html anthony 04:37:09 heycam has joined #svg 04:46:42 ed has joined #svg 05:18:33 shepazu has joined #svg 06:28:54 http://www.whitehouse.gov/change/ 06:54:55 http://www.facebook.com/profile/pic.php?uid=AAAAAQAQZQiTAnE1h3v5wHIFoGiaVwAAAAlDOW2CqsLD732wuA_Nspjn 06:57:00 ooh svg 06:57:04 it's a bit slow in firefox :) 06:57:09 shepazu, who is that? 06:57:49 heycam: that's Erik Dahlstrom 06:58:40 DJ Erik Dahlström recommends: http://www.bluesnews.fi/images/EPmuleskinners.jpg :D 07:01:20 http://www.flickr.com/photos/8624599@N07/1300905048/ 07:02:08 heycam: you look so proud! 07:03:16 my wireless is a bit slow :/ 07:03:32 ah there we go 07:03:55 well look, who wouldn't be proud standing next to that moustache with a man attached? 07:04:24 hard to argue with that 07:19:50 heycam: accusing Allen Wirfs-Brock of breaking the Web, are you? 07:19:58 lol yep 07:20:10 maciej made the point more cogently tho 07:20:48 ffs bearded man, stop shouting about the bloody jupiter jack! 07:23:24 mjs is doing well in this thread 16:16:54 RRSAgent has joined #svg 16:16:54 logging to http://www.w3.org/2009/09/27-svg-irc 16:16:55 jwatt has joined #svg 16:16:56 RRSAgent, make logs public 16:16:56 Zakim has joined #svg 16:16:58 Zakim, this will be GA_SVGWG 16:16:58 I do not see a conference matching that name scheduled within the next hour, trackbot 16:16:59 Meeting: SVG Working Group Teleconference 16:16:59 Date: 27 September 2009 16:17:16 fat_tony has joined #svg 16:17:23 Zakim, remind me in 8 hours to play some pool 16:17:23 ok, ed 16:17:46 Meeting: Mountain View 2009 SVG WG F2F Day 2 16:19:26 Scribe: Cameron 16:19:28 ScribeNick: heycam 16:20:25 Topic: Four remaining 1.1 errata 16:20:34 http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.html#capturing-pointer-events-zero-opacity 16:21:21 JW: i've come to the conclusion that i want to propose new value names 16:21:32 ... and make the current value names map to them in some way for html content 16:21:44 ... you might end up inheriting that from html into inline svg and then into svg 16:22:01 ... i still don't like the idea of changing it 16:22:08 ... it's at least got some kind of consistency at the moment 16:22:14 ... even if the rules aren't very memorable 16:22:21 ... so i'm not in favour of changing, but i won't stand in the way 16:22:26 ED: depends what the changes we're discussing are 16:22:39 ... this first erratum is about zero opacity mask 16:23:06 ... in the link, we previously came to the conclusion that elements with mask at opacity 0 still capture point events 16:23:08 ... like an image with transparency 16:24:33 JW: but with some pointer-events values zero opacity pixels in you can do that 16:24:47 See http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty 16:25:32 "For raster images, hit detection is either performed on a whole-image basis ... or on a per-pixel basic (i.e., the alpha values for pixels under the pointer help determine whether the image receives the event)" 16:27:53 ED: i think opera and firefox behave the same way on this 16:28:00 ... i haven't tested ASV, but my guess is they do the same 16:28:06 CM: what behaviour then? 16:28:19 ED: pretty sure zero opacity mask will still capture pointer events 16:28:24 JW: right, but it pays attention to clip 16:28:52 ED: clipping is less expensive 16:29:06 JW: i had a long discussion with roc about this 16:29:08 ... we concluded that it would be pretty inexpensive, you just need to paint one pixel 16:29:15 ... and you only need to do this with specific values of pointer-events 16:29:26 ... so it'd be totally fine to make it perform in the way that the author would expect 16:30:02 ... one of the most common thing author swant is "if this pixel is being painted, you want to capture events there" 16:31:06 DS: there's a case where you're deliberately putting an invisible rectangle on top of something else, to capture events 16:32:14 JW: you want to be able to say visible => goes through (for shadows e.g.), invisible => capture events (like invisible rect), and not painted on a pixel but geometry still on that pixel => event passes through 16:32:21 ... they're the three cases 16:33:06 DS: when does a user think that a pixel is not painted? .001 opacity looks completely transparent 16:33:06 JW: i understand that 16:33:06 ... i don't think we should pick an arbitrary number 16:34:13 ... i don't think we should assume that clip path and mask are interchangeable 16:35:26 DS: i don't remember at this point why were addressing this in the first place, and that the definition is inconsistent 16:35:37 JW: and it's undefined i think, not sure it says anything about clip path and whether that affects pointer events 16:35:50 DS: i'm asking if we designed a comprehensive solution 16:35:56 ED: there's a later errata item 16:36:29 DS: so did we design a solution that allows all use cases at the expense of being slightly unintuitive? 16:36:37 JW: it's very unintuitive 16:37:06 DS: the way it was originally designed, the names are unintuitive 16:37:10 ... we're not trying to solve that problem 16:37:21 ... we're just applying some logical rules with the basic assumptions 16:37:42 ... to a system which is admittedly flawed 16:37:54 ... are we over-engineering this solution? and so not address right now, but get it right in 2.0? 16:38:20 ... can we apply a partial solution? 16:38:36 ED reads the proposed erratum text 16:39:47 JW: why doesn't the text just say "pointer-events aren't affected by masks"? 16:39:53 DS: that's what the spec said originally, and that's ambiguous 16:40:14 ... affects as in makes them always pass through? or doesn't affect the other determination of whether a pointer event is captured? 16:40:25 ED: i don't think the spec said that originally 16:41:31 ... so it was originally completely undefined how clip paths and masks affect pointer events 16:47:17 ... we should say that filters don't affect pointer events 16:51:46 JW: ok so i'm not going to stand in the way of this; but i have some suggestions on wording 16:51:56 ... one of the problems is that it's talking about event capturing but it should be talking about event targetting 16:52:01 ... not quite sure how to word it though 16:53:18 ... the other thing i HATE is the discussion about the distinction between the geometry hard clipping boundary and pixel operations 16:53:40 ... because as a user, removing things with mask or clip it's just another thing for them to think about to work out which pointer-events values to work 16:54:01 ED: i don't think people actually use all of the different pointer-events values 16:54:10 ... they rather use easier solutions like invisible rectangles 16:55:06 ED: we could just remove the talk about pixel operations 16:55:11 ... i don't like the fact that it mentions filters together with masks 16:55:19 ... filters don't have any effect at all, but masks would have some difference 16:55:31 JW: also clipping is not binary anyway, because of antialiasing 16:56:34 ... actually is that in or out? 17:01:53 RESOLUTION: Add a sentence to 1.1SE that filters don't change pointer-events hit testing 17:02:09 AG: so masking will be treated the same as filters 17:04:46 ACTION: Erik to reword zero opacity mask erratum and add it to the spec, along with this resolution about filters & pointer-events 17:04:46 Created ACTION-2671 - Reword zero opacity mask erratum and add it to the spec, along with this resolution about filters & pointer-events [on Erik Dahlström - due 2009-10-04]. 17:05:01 s/HATE/hate/ 17:06:22 http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.html#clippath-affects-bounding-boxes 17:07:40 http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.html#clippath-pointer-events 17:16:04 http://dev.w3.org/SVG/profiles/1.1F2/publish/types.html#__svg__SVGLocatable__getBBox 17:21:39 RESOLUTION: Take out the first para from the clippath-pointer-events erratum and just add mentions of filters/masks in the getBBox definition 17:22:06 ACTION: Erik take out the first para from the clippath-pointer-events erratum and just add mentions of filters/masks in the getBBox definition 17:22:07 Created ACTION-2672 - Take out the first para from the clippath-pointer-events erratum and just add mentions of filters/masks in the getBBox definition [on Erik Dahlström - due 2009-10-04]. 17:24:43 /** 17:24:44 * Returns the tight bounding box in current user space (i.e., after 17:24:44 * application of the 'transform' attribute, if any) on the 17:24:45 * geometry of all contained graphics elements, exclusive of stroking, clipping, masking and 17:24:45 * filter effects). Note that getBBox must return the actual bounding box 17:24:45 * at the time the method was called, even in case the element has not 17:24:46 * yet been rendered. 17:24:48 * 17:24:50 * @return An SVGRect object that defines the bounding box. 17:24:52 */ 17:24:54 SVGRect getBBox(); 17:26:47 ok, committed 17:44:08 JW: from my testing the only value of pointer-events affected by clipping is the 'all' value 17:45:15 s/affected/unaffected/ 17:45:54 ... so the second paragraph would break current implementations 17:46:40 ... in principle, you would say that painted, fill and stroke would not be affected by the clipping path 17:47:42 DS: i don't think implementations are consistent, from testing 17:48:03 ... fore the future, i think we should have a procedure for uploading tests to make arguments 17:48:42 RESOLUTION: We will link to UA tests from ISSUEs, to help document decisions for the future 17:49:37 JW: so should we do nothing for this erratum? 17:49:59 ... that would mean taking out the second and the third paragraph 17:50:08 ED: i think it would be nice to mention clip path in some way 17:50:14 ... don't have to include this whole thing 17:51:07 JW: for authors i'd like to define something, but i think pointer-events is pretty broken at the moment anyway 17:51:23 ... my main concern is being able to define new values and not adding anything to the spec that might have wording that ties down what we could do with those new values 17:51:41 ... like saying "the pointer-events property never does this" but later wanting to have that with a new value 17:52:00 ... it's not clear to me what the best course of action is for these current values 17:52:10 ... if someone wants to make a proposal fair enough, but i think i agree with doug and say drop it 17:52:28 ED: even if we make text that affects pointer-events, we can always change that later 17:53:35 JW: without the information on what implementations do, like what doug mentioned, are we really in a position to make a decision about a change? 18:10:56 http://www.w3.org/Graphics/SVG/WG/wiki/Pointer_Events 18:20:17

The effects of masking and clipping differ with respect to pointer-events. A clip path is a geometric boundary, and a given point is clearly either inside or outside that boundary; thus, pointer events must be targetted normally over the visible areas of a clipped element, and is only captured normally over the clipped areas if the pointer-events property is set to 'all'. 18:20:17

18:20:18

By contrast, masks and filter effects do not affect how pointer-events are targetted, even in areas where the mask goes to zero opacity or a filter makes the element invisible. If an author wishes to achieve an effect where the transparent parts of a mask allow pointer-events to pass to an element below, a combination of masking and clipping may be used. 18:20:20

18:22:12 pointer events must be targetted normally over the visible areas of a clipped element, and must be targeted normally over the entire clipped areas if the pointer-events property is set to 'all'. 18:24:53 The effects of masking and clipping differ with respect to pointer-events. A clip path is a geometric boundary, and a given point is clearly either inside or outside that boundary; thus, pointer events must be targetted normally over the visible areas of a clipped element, but are only targeted over the clipped areas if the pointer-events property is set to 'all'. By contrast, masks and filter effects do not affect how pointer-events are targetted, even in ar 18:51:37 ed has joined #svg 18:52:31 The effects of masking and clipping differ with respect to pointer-events. A clip path is a geometric boundary, and a given point is clearly either inside or outside that boundary; thus, pointer events must be targetted normally over the visible areas of a clipped element, but are only targeted over the clipped areas if the pointer-events property is set to 'all'. 18:52:32 By contrast, masks and filter effects do not affect how pointer-events are targetted, even in areas where the mask goes to zero opacity or a filter makes the element invisible. 19:01:58 new suggested wording after testing implementations: 19:01:59 The effects of masking and clipping differ with respect to pointer-events. A clip path is a geometric boundary, and a given point is clearly either inside or outside that boundary; thus, pointer events must be targetted normally only over the visible areas of a clipped element. 19:01:59 By contrast, masks and filter effects do not affect how pointer-events are targetted, even in areas where the mask goes to zero opacity or a filter makes the element invisible. 19:05:05 http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/clip-pointerevents.svg 19:11:47 RESOLUTION: That recently pasted text is how we will clarify pointer-events with clip paths 19:13:47 ACTION: Erik to add this pointer-events clip path text 19:13:47 Created ACTION-2673 - Add this pointer-events clip path text [on Erik Dahlström - due 2009-10-04]. 19:13:52 http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.html#liveness-getintersectionlist-getenclosurelist 19:22:50 JW: i'm happy with that text with a couple of suggestions 19:22:57 ... first, the link to DOM links to: 19:23:00 http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-536297177 19:24:13 ... also, make live link to: 19:24:15 http://www.w3.org/TR/DOM-Level-2-Core/core.html#td-live 19:24:27 ... and remove the text "static and" 19:25:36 ACTION: Cameron do this getIntersectionList erratum 19:25:36 Created ACTION-2674 - Do this getIntersectionList erratum [on Cameron McCormack - due 2009-10-04]. 19:51:55 [break for lunch] 21:33:21 ed has joined #svg 21:35:29 http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_Edition 21:35:51 topic: writing/reviewing tests for 1.1 second edition 21:49:54 why is http://dev.w3.org/SVG/profiles/1.1F2/test/svg/masking-path-06-b.svg a draft (the test claims to have been reviewed and accepted) 22:01:11 close action-2674 22:01:11 ACTION-2674 Do this getIntersectionList erratum closed