WICG / ContentPerformancePolicy

A set of policies that a site guarantees to adhere to, browsers enforce, and embedders can count on.
http://wicg.github.io/ContentPerformancePolicy/
Other
73 stars 9 forks source link

Mechanism to indicate desire to opt OUT of a CPP? #8

Open RByers opened 8 years ago

RByers commented 8 years ago

There are some things here (eg. passive-listeners-only) which we're planning on having an intervention to enable when we believe that the benefit is substantially greater than the compat risk. In such cases it may be useful to have a way for a page to indicate that it prefers to explicitly disable a CPP policy. This may not always be honored, but can provide a migration path. Eg. I could imagine saying that passive-listeners-only is enabled by default for pages that perform below a threshold, but can be explicitly disabled for a few releases (or maybe by pages that are relatively close to the defined threshold).

Is there anything similar for CSP? I'm not aware of anything. Worth considering here?

yoavweiss commented 8 years ago

So basically a "don't intervene on my behalf for this feature, as I know what I'm doing" kind of signal?

There's nothing of that sort for CSP that I'm aware of, but that shouldn't stop us from adding such a directive. OTOH, I wonder if such a signal wouldn't just be abused and become a NOOP after a short while.

Do you have the set of use cases that require active listeners and cannot be covered by using semantic HTML elements (e.g. <button>) and intersection observers?

RByers commented 8 years ago

Do you have the set of use cases that require active listeners and cannot be covered by using semantic HTML elements (e.g.

I'm working hard to ensure that almost all use cases for touch events could be handled with passive listeners and touch-action. But there will likely remain some outliers. Eg. a gesture recognition library (like hammer.js) that wants to recognize a fast "swipe" as distinct from scroll (which it doesn't want to prevent). Any such issues are holes in the pointer events model, so should be pretty rare.

But wheel listeners are different, there are still plenty of use cases for active wheel listeners (although we're slowly chipping away at them). Eg. Youtube has a volume slider that responds to wheel events (instead of scrolling), and even Google maps has an active wheel listener to trigger zooming.

RByers commented 8 years ago

I wonder if such a signal wouldn't just be abused and become a NOOP after a short while.

Yeah the use case is definitely limited. I think it's worth keeping our eyes open for a concrete case where we might really want this, but if we can keep things simple and avoid it then that's great. In all these intervention-like things I do think there's a spectrum. The UA is trying to guess what the best tradeoff between user experience and page compat will be, and there is value in taking signals from developers on the page compat side (up to a point).