Clarify relation of isPointInFill and pointer-events

<BogdanBrinza> GitHub: https://github.com/w3c/svgwg/issues/416

<scribe> scribenick: AmeliaBR

<krit> https://svgwg.org/svg2-draft/types.html#InterfaceSVGGeometryElement

Dirk: The specification isn't clear about how isPointInFill/Stroke should be calculated?
... in particular, what does it mean that "normal hit testing rules apply" with respect to pointer-events property

https://svgwg.org/svg2-draft/interact.html#PointerEventsProp

scribe: the way it's written, it suggests that the point would return false if pointer events setting would make it not sensitive
... I don't think we should take the pointer events property into account at all
... if its none, the method would always return false; if bounding-box, would all parts of the box be both fill and stroke? It doesn't make sense

Amelia: I agree, as written it doesn't make sense. Not sure of original intent. Maybe the intention was to reference some of the algorithms in the pointer-events section.

Dirk: Maybe it would make sense to say that isPointInStroke should include all points that would be sensitive with pointer-events: stroke.
... If we follow that definition, however, it would mean that it would be affected by clip-paths.
... There are also confusion about shapes in <defs>. They don't have pointer-events, but they could still use this interface.

(or children of pattern, clipPath, mask, etc.)

scribe: The current Chrome implementation isn't affected by whether the shape is rendered or clipped.

<krit> https://html.spec.whatwg.org/multipage/scripting.html#dom-context-2d-ispointinpath

scribe: Results are similar to the canvas isPointInPath API, although that also takes a winding-order (equivalent to fill-rule)

Amelia: So, if we don't have that parameter, we need to use the fill-rule on the element?

<krit> https://drafts.fxtf.org/css-masking-1/#the-clip-rule

Dirk: Yes, but for children of a clipPath, the relevant property is clip-rule.

Amelia: That's a pain. We have these two properties that do the same thing, but which to use depends on context.

Dirk: So, first question: Do we agree that the pointer-events property on the element shouldn't affect the API results?

RESOLUTION: isPointInStroke/Fill methods shouldn't be affected by current value of pointer-events property

Dirk: Next question is how do we calculate it?
... My general suggestion is to align with HTML canvas spec.

Amelia: Do you know implementation status for the canvas methods?

Dirk: I did WebKit, a colleague did Gecko, Blink has it as well.

<dstorey> https://developer.microsoft.com/en-us/microsoft-edge/platform/catalog/?page=1&q=isPointIn <- browser support

Amelia: So essentially, the canvas API is fixed

Dirk: The downside is that we then can't set it up to automatically match clip-rule

Amelia: But the canvas API accepts a parameter when you call the method, so we could extend our method as well, if an author wanted to query the clip-rule and pass it to the method.

Liam: But we could probably add that later, right? It doesn't have to be now.

Dirk: Probably
... It's not just clip-rule, it's also parent clip-path

Amelia: Oh, I see. Yes, I agree to keep the simpler approach for now.
... We could later extend it by adding an options object, similar to the proposed options for getBBox()

Dirk: I'd still recommend we use the pointer-events algorithm (for fill versus stroke), just with not taking clipping paths into account

Amelia: Can you come up with a draft text for review?

Dirk: Yes

RESOLUTION: Use the pointer-events algorithms for defining which areas are fill and which are stroke, EXCEPT for ignoring clipping

Dirk to create proposal

github-bot, end topic

Clarify hit testing behavior of <foreignObject>

<BogdanBrinza> GitHub: https://github.com/w3c/svgwg/issues/427

Dirk: Browsers seem to agree to use the bounding box

Amelia: It looks like its currently not defined at all in the spec?

https://svgwg.org/svg2-draft/interact.html#PointerEventsProp

Dirk: Or should we leave it up to the document that gets embedded to define how hit testing works.

Bogdan: I'm not sure that's well defined anywhere, but we seem to have interoperable behavior.

Amelia: `pointer-events` in general isn't defined anywhere for CSS box layout, but it is interoperable

Bogdan: For this specific issue, should we define it somewhere to match browsers?
... Can you make that edit?

Dirk: I think the proposal is that child document types should define hit testing.

Amelia: That's find for child elements. But for the `<foreignObject>` itself, should it be transparent (so only gets hits if a child element is hit), or should it be a full rectangle.

Dirk: I think it should be the full rectangle. That's what's implemented.

<krit> https://wiki.csswg.org/spec/css4-ui#pointer-events

Bogdan: I would also recommend using the full rectangle, since the browsers are interoperable. I'd like to capture this in the spec.

Dirk: Are we OK adding a "May" section about child elements may have hit-testing rules defined according to their own document language.

Bogdan: That seems fine, just a short "may" sentence & that's it.

RESOLUTION: Add rule for pointer-events of foreignObject, to match browser implementation (exact wording TBD)

github-bot, end topic

Do we really need not to reflect additional enum values in SVG 2

<BogdanBrinza> GitHub: https://github.com/w3c/svgwg/issues/424

Bogdan: We discussed this briefly on the last calll, but deferred a resolution

Amelia: I think, if we aren't going to add new values for new attributes, then we should just deprecate the entire enum, because it's rather confusing as is.

Dirk: For WebKit, I think I had to add special cases to test whether a value was in the SVG 1.1 set or a new value.

Amelia: So it's possible that by not adding the new values, we just complicate implementations anyway?

Bogdan: I agree with David's point on the issue.

Amelia: Meaning, you agree with Robert Longson's original proposal, that we SHOULD expose the new attribute values through the DOM?

David: Yes, and it looks like Firefox already has a bug for exposing a new value?

Amelia: But what new value are they exposing, if it's never defined as an enum constant?

Dirk: But internally they need a value, and it's probably just an ordered int. So we can follow Firefox.

Amelia: Well, it looks like we have agreement between implementers. And for authors it would definitely be an improvement.
... Do we know all the places this is an issue?

Dirk: There are two places, for markers and for filter blend mode.
... I'm not sure if both are even implemented.

Amelia: Both are existing attributes, existing enums, with new attribute values but not yet new enum values.
... I'd assume we want both to be consistent.

RESOLUTION: Where SVG 2 has added a new attribute value for an attribute that has an existing DOM enumeration, we will add matching new enumeration values

github-bot, end topic

Speeding up resolution for GitHub discussion

Dirk: Is there any way to get a resolution for a GitHub issue, other than through the teleconference?

Amelia: Other working groups do "Call for Consensus" emails, with a time limit asking for objections.
... would be helpful, since we also don't get everyone on these calls

Dirk: So, just an email to www-svg?

Amelia: Probably both that at the public working group list, so that "votes" on the issue could go to the working group list.

<liam> https://www.w3.org/2017/04/svg-2017.html#decisions

Liam: We actually do have a WG decision policy that specifies 10-day call for consensus, so we can definitely follow that.
... Although I think we can ignore the point where resolutions from telcons are not binding without it, as that would slow everything down completely.

Dirk: Well, it's non-binding in the sense that another resolution can override it.

Bogdan: A reminder that next week's call is for reviewing features at risk. I hope to be able to go through that quickly.
... Dirk has worked with Cameron, to create parallel versions of the spec, one version for CR, and one version with all the text, so we can potentially use it to jumpstart future module specs.

trackbot, end telcon

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: dstorey, liam, ericwilligers, BogdanBrinza, AmeliaBR, Tavmjong, krit
Present: dstorey liam ericwilligers BogdanBrinza AmeliaBR Tavmjong krit
Found ScribeNick: AmeliaBR
Inferring Scribes: AmeliaBR

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 07 May 2018
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)