Contact emails
sza...@chromium.org, chri...@chromium.org
Explainer
This is a copy of the current explainer doc for IntersectionObserver, with edits describing the proposed additional functionality.
Spec
This is a copy of the IntersectionObserver spec, with edits describing the proposed spec changes.
Summary
Currently, IntersectionObserver will report the bounding box of a target element relative to the containing viewport, after applying all intervening overflow and CSS clips. However, it does not consider whether a target element has been painted over (“occluded”) by other content, or whether any visual effects have been applied which may alter or obscure the element’s display. The proposal is to augment IntersectionObserver to report information about occlusion and visual effects, in order to provide a strong guarantee about the visibility of a target element in the rendered output.
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Demo link
https://szager-chromium.github.io/IntersectionObserver/demo/cashbomb/hidden/
http://szager-chromium.github.io/IntersectionObserver/demo/svg/
Debuggability
Presently there is no DevTools functionality specifically for IntersectionObserver V2. It has been suggested that it might make sense to add DevTools support to help identify why a particular target element is considered "possibly not visible". This can be investigated after shipping.
Risks
Interoperability and Compatibility
Chrome, Edge, and Firefox have shipped V1 of IntersectionObserver. It is implemented in WebKit and enabled by default in the current Safari developer preview. The V2 proposal is a relatively small change to the V1 spec, and it was discussed extensively at TPAC 2018. Security people from all browsers were uniformly positive. Rendering and web platform people from the other browsers were neutral-to-positive.
Edge: Supportive, no detailed position.
Firefox:Security people are supportive; some concern about interoperability.
Safari: Supportive, willing to accept patches.
Web developers: Positive.
Ergonomics
It is expected that V2 will be signficantly slower than V1, due to the computational complexity of determing occlusion. For that reason, V2, is disabled by default; and it mandates a minimum "delay" parameter to throttle the frequency of computation. Limited experimentation on real-world sites confirms the performance difference, but does not appear to be a significant factor in overall page performance.
Activation
IntersectionObserver V1 is already being used on ~20% of all page views, and V2 is a small additive change to the API, so it should be relatively easy for developers to use. There is no viable strategy for polyfill.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
There are tests in the chromium repository than can be upstreamed to web-platform-tests when appropriate.
Entry on the feature dashboard
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHOQ7J9PU6yOR86orQ3EJvgfJeOaXo6a5CNzH%2B7KhLhFbJ9toQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdoGH-Nn3JkOPb1rtQ0A5gh2m2JTEHxgHvVQOvKtAM_1g%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdoGH-Nn3JkOPb1rtQ0A5gh2m2JTEHxgHvVQOvKtAM_1g%40mail.gmail.com.
Reading the explainer, it talks about protecting the users from fraud, but it's the ones purchasing ad space (and possibly the ad networks they use) this will protect, right? End users are just used as tools when trying to get illegitimate money from ad purchasers.
The explanation talks about a performance hit. Is there any chance that will be a performance gain because ad networks will use less javascript, or is this solving a problem javascript could never address anyway?> There are tests in the chromium repository than can be upstreamed to web-platform-tests when appropriate.It would be appropriate I believe, unless it's not appropriate for some reason? I believe it's all magic now so it should be easy (I say, without having actually created any recent web platform tests myself). (foolip?)
Reading the explainer, it talks about protecting the users from fraud, but it's the ones purchasing ad space (and possibly the ad networks they use) this will protect, right? End users are just used as tools when trying to get illegitimate money from ad purchasers.
The explanation talks about a performance hit. Is there any chance that will be a performance gain because ad networks will use less javascript, or is this solving a problem javascript could never address anyway?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHOQ7J9kj84Ns2Lwuz7FwJt2mfrkQTz6QOx609HBinuER5DEkA%40mail.gmail.com.
SpecThis is a copy of the IntersectionObserver spec, with edits describing the proposed spec changes.
2019年1月24日木曜日 1時08分46秒 UTC+9 Stefan Zager:SpecThis is a copy of the IntersectionObserver spec, with edits describing the proposed spec changes.
Is there any chance we could get this into a proper spec before shipping such that it might encourage wider review?(Concern is that we've had things ship with obvious problems before because they never graduated beyond WICG before shipping and hence missed wider review.)
Firefox:Security people are supportive; some concern about interoperability.
Is there any reference for which security people are supportive?(In any case, I think the standards-positions issue should be preferred over any other signals.)
Somewhat related, is there a PR for folding https://szager-chromium.github.io/IntersectionObserver/ into the main spec? I ask in part for the usual reasons, but also because any spec that isn't on one of the usual places isn't included in https://github.com/tidoust/reffy-reports, which means their IDL won't be automatically extracted and tested in web-platform-tests. The IDL will probably also be useful to determining browser support for MDN.
On Thu, Jan 24, 2019 at 4:22 PM Brian Birtles <bbir...@mozilla.com> wrote:2019年1月24日木曜日 1時08分46秒 UTC+9 Stefan Zager:SpecThis is a copy of the IntersectionObserver spec, with edits describing the proposed spec changes.
Is there any chance we could get this into a proper spec before shipping such that it might encourage wider review?(Concern is that we've had things ship with obvious problems before because they never graduated beyond WICG before shipping and hence missed wider review.)There is a proper spec repository for IntersectionObserver (I am the editor), but I opted not to commit my changes to that repository, because it seems useful to me to be able to compare the existing V1 spec and the proposed V2 spec side-by-side.
I also wanted to have a separate issue tracker, to keep V2-specific issues separate.
Interestingly, IntersectionObserver V1 shipped in multiple browsers well before the spec graduated out of WICG. So, graduating to a proper w3c repository has not been an obstacle in the past.
Can we please get the spec changes merged somewhere more visible before shipping?Best regards,Brian
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF-W_FQa0ww%2B3NRdyahZqcPQk31kfAV8qvkSvLLv-gr_dhTt-w%40mail.gmail.com.
On Thu, Jan 24, 2019 at 4:13 AM Daniel Bratell <bra...@opera.com> wrote:Reading the explainer, it talks about protecting the users from fraud, but it's the ones purchasing ad space (and possibly the ad networks they use) this will protect, right? End users are just used as tools when trying to get illegitimate money from ad purchasers.Ads are not the only (or even the primary) use case for V2. It is broadly applicable to many kinds of UI redress attacks that victimize end users. The first demo link illustrates just such a case involving an embedded third-party digital payment widget.
LGTM3This seems like an important feature that would enable plugging this security hole.At the same time:* I'd love to see the V2 specs get merged to be part of the official repo. You could have them be there on a separate branch, and set up pr-preview to have a PR with diffs between V2 and V1.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEif55Ouc0jPgJ-y6tP%3Dtyn3hHxny7OTt1zB5u_UKebT4w%40mail.gmail.com.
On Thu, Jan 24, 2019 at 11:06 PM Yoav Weiss <yo...@yoav.ws> wrote:LGTM3This seems like an important feature that would enable plugging this security hole.At the same time:* I'd love to see the V2 specs get merged to be part of the official repo. You could have them be there on a separate branch, and set up pr-preview to have a PR with diffs between V2 and V1.FWIW we've successfully used the approach of incubating additions and major changes to a spec within it's existing repo in pointer events - both via a monkey patch and (for a contentious and hard to separate change) a branch. As long as the group is happy with that and it doesn't add process overhead, it seems less of a hassle to me than moving specs between different repos.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_5TmB3fAS2AafcLbNYLKEiEVsgDR0JrfazXFpkJ43O%2BA%40mail.gmail.com.
It is true that the Blink launch process does not mandate a particular location (or set of locations) for specs for changes we ship through that process. I however feel it is reasonable as a minimum step to expect that Chromium contributions from those of us who are Google employees come with specs for things we ship through the Blink lunch process in a place that is well known and easily findable (e.g. WICG, or some other official and well known W3C/WHATWG/IETF/ECMA/etc location). Not only does that make various tooling (as Philip pointed out) easier, but it also makes the specs more easily findable, more likely we'll receive more feedback, and it gives not just us, but those who we expect and hope to get feedback from some level of IPR protection. I can't see any real downside to expecting that. And we would certainly appreciate the same from others who contribute, and maybe at some point it would make sense to actually bake that into the Blink process as well.
And if we for whatever reason find ourselves with a hard time finding good places for specs (i.e. WICG etc isn't working for us) then nothing stops us from creating a Chromium specific place for early stage specs. We could attached some level of IPR protection and publicize that location over time, but that I will not worry about unless there's a strong need to go there (I'm not aware of any current blockers with the set of locations where early stage spec work can happen today).
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhfpWN7y%3DAByouDg%2BfCW%3D-g6-yf0Q3OwoCik4mi-RQWjA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHOQ7J_fk8A4UdieSht8ODjDDz-yt0ZPc%3DauEYnO564U%2BzSwuQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeVcYy5h2t4ciC3jQodV%2BhVWG5PZ8BL26ykpc8hcQurBw%40mail.gmail.com.