Rick Byers

Hah hah - Twitter just notified me that [PaymentRequest is now on desktop](https://twitter.com/agektmr/status/905289098365210625).

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

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

There are lots of composition scenarios where you're not in a position to heavily restrict what your iframes do. Eg. with any ad network it's virtually impossible for a publisher...

Maybe that's possible, IIRC our layout experts (maybe @esprehn) feel that's not practical to implement efficiently but I may be forgetting. Also in that model it would be pretty hard...

Makes sense, thanks.

Yeah this is tough. There's a lot of things that would be nice but impractical to implement at sub-iframe granularity (even getting performance isolation of frames is a huge task,...

Sounds cool to me. It's hard to know how fine grained these need to be to be useful, but we can start corase and iterate based on feedback if needed.

AppCache is something I think we're going to want to eventually deprecate, so (like sync-xhr) it makes sense to have a feature policy for that alone. So I'm certainly supportive.

We long ago [agreed](https://discourse.wicg.io/t/eventlisteneroptions-and-passive-event-listeners-move-to-wicg/1386) that this feature integrated directly into the core of DOM and so could only be specified properly as part of the DOM spec (rather than try...