SVGGeometry.prototype.isPointInStroke vs. vector-effects

[fsoder]

The section on isPointInStroke lists a number of stroke-related properties that should be considered as part of the isPointInStroke operation - it does not mention vector-effect. Excluding it seems reasonable to me, but looking at the issues leading up to the current spec text (like #456) I didn't see it being (explicitly) considered, so I just wanted make sure that its exclusion from the list of properties was deliberate. If that's the case I can probably make sure that a test is added for that case.

[fsoder]

Extending this query to also include 'pathLength'.

[AmeliaBR]

I think it was definitely overlooked.

From an author perspective, the method is certainly less useful if it doesn't factor in non-scaling-stroke. While most of the other vector effects apply as transformations on the element as a whole (and therefore transform the definition of all points), a non-scaling-stroke doesn't affect the coordinates used for the element.

So the question is: would it be burdensome for implementations to factor in non-scaling-stroke effects when calculating isPointInStroke ?

Extending this query to also include 'pathLength'.

Not sure how you mean? In the sense that pathLength affects stroke dashing patterns, yes, it should affect isPointInStroke.

Perhaps it would be more helpful if the method definition simply referenced the stroke-shape algorithm instead of trying to enumerate the properties that affect the stroke.

[fsoder]

So the question is: would it be burdensome for implementations to factor in non-scaling-stroke effects when calculating isPointInStroke?

I wouldn't think so in general.

Not sure how you mean? In the sense that pathLength affects stroke dashing patterns...

Yes, exactly.

Perhaps it would be more helpful if the method definition simply referenced the stroke-shape algorithm instead of trying to enumerate the properties that affect the stroke.

Yes, that would make sense. non-scaling-stroke would still need to be handled explicitly though I think, so it's not a silver bullet.

[dirkschulze]

I think we have an issue for exactly this question already. I’ll link it when I find it.

@fsoder in WebKit and Blink it is a purely graphical effect. The stroke gets rendered within the „root coordinate system“ and the path transformed to the actual coordinate space temporarily at render time.

Have you checked if WebKit or Blink even include it in the Hit testing code? If yes, you are right and it wouldn’t be a big thing. Otherwise, it might be less performant than the no-vector-effect case. I wonder if the difference is measurable. If it is, there might be a security issue. This should be checked as well before we include it in the calculation.

[dirkschulze]

Here a test: https://codepen.io/krit/pen/ePXmwx Firefox and Blink do take non-scaling-stroke into account for hit testing.

[fsoder]

Yes, I'm aware of what hit-testing and existing implementations do wrt vector-effect - which I was curious about why it had been left out for isPointInStroke.

[dirkschulze]

@fsoder It was added on the agenda a while back but not discussed yet.

Independent of that, since it is a CSS property it would be important to know if the additional computational effort is measurable in JS. I doubt it but would it be possible for you to test?

[fsoder]

I'd expect that it could be observable, but to what degree will likely depend on implementation details and the size of the input (i.e complexity of the path et.c.) I can probably do some measurements tomorrow.

[dirkschulze]

@fsoder my concern is about possible attacking patterns with :visited pseudo selector (
https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector) on the privacy. I could be wrong but would like to rule it out and, if necessary, mention the risk with a fallback path for implementations. Again, we would need to think about attack patterns if there are any.

[fsoder]

vector-effect would not be applied by :visited [1], so I think that should be fine (else I'd suspect stroke-dasharray could easily have the same issue.)

[1] As indicated by https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector#Limits_to_visited_link_styles

[dirkschulze]

@fsoder ah Right. It does not apply. Then I don’t see a reason why it shouldn’t be part of isPointInStroke.

[css-meeting-bot]

The SVG Working Group just discussed SVGGeometry.prototype.isPointInStroke vs. vector-effects, and agreed to the following:

• RESOLUTION: vector-effects property contributes to hit-testing and `isPointInStroke`.

The full IRC log of that discussion

<AmeliaBR> Topic: SVGGeometry.prototype.isPointInStroke vs. vector-effects
<AmeliaBR> github: https://github.com//issues/559
<SairusPatel> "Sairus & Dean at Adobe" should be: "Myles & Dean at Apple". I may have misspoken
<AmeliaBR> s/Sairus & Dean at Adobe/Myles & Dean at Apple/
<AmeliaBR> s/"Sairus & Dean at Adobe" should be: "Myles & Dean at Apple". I may have misspoken//
<AmeliaBR> Dirk: Question is whether vector-effect is just a visual effect or whether it actually affects geometry, and therefore hit-testing and the API.
<AmeliaBR> ... I'd like to get a resolution to adopt fsoder's recommendation: vector-effect should affect these APIs.
<AmeliaBR> Amelia: Agree that's ideal. Only concern was implementation cost, but I think browsers are already doing all the calculations so there shouldn't be much overhead.
<AmeliaBR> Dirk: I don't think there is any implementation concern.
<AmeliaBR> RESOLUTION: vector-effects property contributes to hit-testing and `isPointInStroke`.