#328: IntersectionObserver V2
Discussions
2019-01-08
Peter: bump until David joining?
Alex: I did have a conversation with Stefan (the engineer working on this). In the timing thing it appears as though it's specified the way David wanted. There is a separate question about other documents that are cooperating - but that's not the root of David's question. I want to get Stefan & David talking about this. Let's punt and maybe invite Stefan.
Peter: Ok - reach out to stefan?
Alex: Ok.
punted to next week
2019-01-15
Alex: was going to have Stefan join... couln't make it. Stefan thought the problems were not what David thought they were, but actually aligned with what David wanted?
David: yes, for the v1 issue... but need to dig in. I'm happy to punt to next week (pretty busy catching up).
Alex: Will hand-off to Stefan, but I may not be able to join next week.
David: Had different concerns around v2. If motivation for v2 is click-jacking prevention, then the spec needs to be truely interoperable. Otherwise you risk cases where overlap differences could lead to a site working in one browser and not others. E.g., a site built for Chrome as anti-clickjacking, but doesn't work in Firefox due to fuzzy borders (or something), and the site denies access. So I really want to be sure Interop is rock-solid.
Alex: So, issue could be with blur?
David: Or what constitutes what the edge of the blur is. Last time I checked, this was very unclear.
Alex: Could be result of compositor issues/bugs... I share many of the same concerns. Also, in addition to clickjacking, could be preventing monotization (which is equally bad). Recall that sites are already doing this, but using poor methods.
David: Makes sense to address the use cases--I just want more detail.
Alex: What can I tell Stefan?
David: When I gave feedback last time, Stefan made changes re: blur--but I haven't reviewed yet.
Dan: Will return next week.
2019-01-22
David: Haven't yet followed up on my ask...
Peter: Punting to next week.
Tess: I will ask Simon how I think and feel.
David: Note there's a V1 and V2.
2019-03-26
David: we wanted to invite stefan at some zeger point.
Dan: put it to the f2f and ask this person to dial in?
David: i should explain my concerns in the issue first... 3 weeks for now or later works for me if someone else can schedule it.
Alice: i can chat with him. What will the date be?
Peter: the 16th - 10 pm west coast time
Alice: i chatted with stefan and he can make it.
2019-04-17
David: recounts the issue including Mozilla's standards position
Dan: Interop diversity is important.
Tess: I can't think of additional areas besides ink overflow for this specific case
Stefan: i made it an up or down flag because I didn't want to get into issues of measurement too much...
David: boolean design will be better...
Stefan: we can define ink overflow better - that would be a good thing.
David: that would be a good thing. There is interop risk - and value in fixing one piece of the foundation.
Stefan: we have shipped it in chrome and i am working out bugs in the implementation - it's intented to be used in the security setting i am discouraging people to rely on it until kinks are worked out. Intention is that this is used very narrowly unline v1. Some time until we see sites using it - and relying on it as a "golden signal" - so some runway to do the ink overflow spec.
David: sounds great
OpenedNov 26, 2018
こんにちはTAG!
I'm requesting a TAG review of:
Further details (optional):
You should also know that...
This feature is currently implemented in chromium, hidden behind a flag:
--enable-blink-features=IntersectionObserverV2
There are some ham-fisted demos:
https://szager-chromium.github.io/IntersectionObserver/demo/cashbomb/hammerz/ https://szager-chromium.github.io/IntersectionObserver/demo/cashbomb/hidden/ http://szager-chromium.github.io/IntersectionObserver/demo/cashbomb/transparent/ http://szager-chromium.github.io/IntersectionObserver/demo/svg/
We'd prefer the TAG provide feedback as (please select one):