W3C

SVG Working Group Teleconference

27 Sep 2009

See also: IRC log

Attendees

Present
Anthony, Cameron, Chris, Doug, Erik, Jonathan
Regrets
Chair
Erik
Scribe
Cameron

Contents


trackbot, start telcon

<trackbot> Date: 27 September 2009

<scribe> Meeting: Mountain View 2009 SVG WG F2F Day 2

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

Four remaining 1.1 errata

<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].

<ed> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.html#liveness-getintersectionlist-getenclosurelist

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

writing/reviewing tests for 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

Summary of Action Items

[NEW] ACTION: Cameron do this getIntersectionList erratum [recorded in http://www.w3.org/2009/09/28-svg-minutes.html#action04]
[NEW] 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]
[NEW] ACTION: Erik to add this pointer-events clip path text [recorded in http://www.w3.org/2009/09/28-svg-minutes.html#action03]
[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009-03-02 03:52:20 $