See also: IRC log
trackbot, start telcon
<trackbot> Date: 27 September 2009
<scribe> Meeting: Mountain View 2009 SVG WG F2F Day 2
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
<ed> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.html#capturing-pointer-events-zero-opacity
JW: i've come to the conclusion that i want to propose new value names
... and make the current value names map to them in some way for html content
... you might end up inheriting that from html into inline svg and then into svg
... i still don't like the idea of changing it
... it's at least got some kind of consistency at the moment
... even if the rules aren't very memorable
... so i'm not in favour of changing, but i won't stand in the way
ED: depends what the changes we're discussing are
... this first erratum is about zero opacity mask
... in the link, we previously came to the conclusion that elements with mask at opacity 0 still capture point events
... like an image with transparency
JW: but with some pointer-events values zero opacity pixels in <image> you can do that
<jwatt> See http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
<jwatt> "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)"
ED: i think opera and firefox behave the same way on this
... i haven't tested ASV, but my guess is they do the same
CM: what behaviour then?
ED: pretty sure zero opacity mask will still capture pointer events
JW: right, but it pays attention to clip
ED: clipping is less expensive
JW: i had a long discussion with roc about this
... we concluded that it would be pretty inexpensive, you just need to paint one pixel
... and you only need to do this with specific values of pointer-events
... so it'd be totally fine to make it perform in the way that the author would expect
... one of the most common thing author swant is "if this pixel is being painted, you want to capture events there"
DS: there's a case where you're deliberately putting an invisible rectangle on top of something else, to capture events
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
... they're the three cases
DS: when does a user think that a pixel is not painted? .001 opacity looks completely transparent
JW: i understand that
... i don't think we should pick an arbitrary number
... i don't think we should assume that clip path and mask are interchangeable
DS: i don't remember at this point why were addressing this in the first place, and that the definition is inconsistent
JW: and it's undefined i think, not sure it says anything about clip path and whether that affects pointer events
DS: i'm asking if we designed a comprehensive solution
ED: there's a later errata item
DS: so did we design a solution that allows all use cases at the expense of being slightly unintuitive?
JW: it's very unintuitive
DS: the way it was originally designed, the names are unintuitive
... we're not trying to solve that problem
... we're just applying some logical rules with the basic assumptions
... to a system which is admittedly flawed
... are we over-engineering this solution? and so not address right now, but get it right in 2.0?
... can we apply a partial solution?
ED reads the proposed erratum text
JW: why doesn't the text just say "pointer-events aren't affected by masks"?
DS: that's what the spec said originally, and that's ambiguous
... affects as in makes them always pass through? or doesn't affect the other determination of whether a pointer event is captured?
ED: i don't think the spec said that originally
... so it was originally completely undefined how clip paths and masks affect pointer events
... we should say that filters don't affect pointer events
JW: ok so i'm not going to stand in the way of this; but i have some suggestions on wording
... one of the problems is that it's talking about event capturing but it should be talking about event targetting
... not quite sure how to word it though
... the other thing i hate is the discussion about the distinction between the geometry hard clipping boundary and pixel operations
... 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
ED: i don't think people actually use all of the different pointer-events values
... they rather use easier solutions like invisible rectangles
... we could just remove the talk about pixel operations
... i don't like the fact that it mentions filters together with masks
... filters don't have any effect at all, but masks would have some difference
JW: also clipping is not binary anyway, because of antialiasing
... actually is that in or out?
RESOLUTION: Add a sentence to 1.1SE that filters don't change pointer-events hit testing
AG: so masking will be treated the same as filters
<scribe> ACTION: Erik to reword zero opacity mask erratum and add it to the spec, along with this resolution about filters & pointer-events [recorded in http://www.w3.org/2009/09/28-svg-minutes.html#action01]
<trackbot> 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].
<ed> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.html#clippath-affects-bounding-boxes
<ed> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.html#clippath-pointer-events
http://dev.w3.org/SVG/profiles/1.1F2/publish/types.html#__svg__SVGLocatable__getBBox
RESOLUTION: Take out the first para from the clippath-pointer-events erratum and just add mentions of filters/masks in the getBBox definition
<scribe> ACTION: Erik take out the first para from the clippath-pointer-events erratum and just add mentions of filters/masks in the getBBox definition [recorded in http://www.w3.org/2009/09/28-svg-minutes.html#action02]
<trackbot> 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].
<ed> /**
<ed> * Returns the tight bounding box in current user space (i.e., after
<ed> * application of the <a>'transform'</a> attribute, if any) on the
<ed> * geometry of all contained graphics elements, exclusive of stroking, clipping, masking and
<ed> * filter effects). Note that getBBox must return the actual bounding box
<ed> * at the time the method was called, even in case the element has not
<ed> * yet been rendered.
<ed> *
<ed> * @return An <a>SVGRect</a> object that defines the bounding box.
<ed> */
<ed> SVGRect getBBox();
<ed> ok, committed
JW: from my testing the only value of pointer-events unaffected by clipping is the 'all' value
... so the second paragraph would break current implementations
... in principle, you would say that painted, fill and stroke would not be affected by the clipping path
DS: i don't think implementations are consistent, from testing
... fore the future, i think we should have a procedure for uploading tests to make arguments
RESOLUTION: We will link to UA tests from ISSUEs, to help document decisions for the future
JW: so should we do nothing for this erratum?
... that would mean taking out the second and the third paragraph
ED: i think it would be nice to mention clip path in some way
... don't have to include this whole thing
JW: for authors i'd like to define something, but i think pointer-events is pretty broken at the moment anyway
... 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
... like saying "the pointer-events property never does this" but later wanting to have that with a new value
... it's not clear to me what the best course of action is for these current values
... if someone wants to make a proposal fair enough, but i think i agree with doug and say drop it
ED: even if we make text that affects pointer-events, we can always change that later
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?
<shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Pointer_Events
<ed> <p>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'.
<ed> </p>
<ed> <p>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.
<ed> </p>
<shepazu> 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'.
<shepazu> 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
<shepazu> 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'.
<shepazu> 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.
<ed> new suggested wording after testing implementations:
<ed> 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.
<ed> 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.
<ed> http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/clip-pointerevents.svg
RESOLUTION: That recently pasted text is how we will clarify pointer-events with clip paths
<scribe> ACTION: Erik to add this pointer-events clip path text [recorded in http://www.w3.org/2009/09/28-svg-minutes.html#action03]
<trackbot> Created ACTION-2673 - Add this pointer-events clip path text [on Erik Dahlström - due 2009-10-04].
JW: i'm happy with that text with a couple of suggestions
... first, the link to DOM links to:
<jwatt> http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-536297177
JW: also, make live link to:
<jwatt> http://www.w3.org/TR/DOM-Level-2-Core/core.html#td-live
JW: and remove the text "static and"
<scribe> ACTION: Cameron do this getIntersectionList erratum [recorded in http://www.w3.org/2009/09/28-svg-minutes.html#action04]
<trackbot> Created ACTION-2674 - Do this getIntersectionList erratum [on Cameron McCormack - due 2009-10-04].
<ed> [break for lunch]
<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_Edition
<ed> 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)
close action-2674
<trackbot> ACTION-2674 Do this getIntersectionList erratum closed
<shepazu> Discussion on the topics of scripting interface design, Web IDL, and coordination between W3C Working Groups, ECMA TC-39, and other interested parties.
<shepazu> This list is not a forum for script authoring.
<ChrisL> issue-2285?
<trackbot> ISSUE-2285 -- Resolving @primitiveUnits and z attribute discrepancies -- RAISED
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2285
