Re: [w3ctag/design-reviews] Element Timing API for img (#326)

Replying to the comments:
> It's a bit difficult to judge whether or not this is safe based on just the fact that it was "approved" under the privacy and security review process within Google. Could you fill out the S&P questionnaire or at least share us the review report at the very least?

Sure! Here it is https://docs.google.com/document/d/15T51ya-7GCtDQGF_ukGAPXBkygI6WFZBV9e9Bc8mjic/edit


> * I assume only elements that belong to the top-level browsing context are considered for auto-inclusion in the timings? E.g., many ad frameworks manipulate iframes to fill considerable space in the viewport and which oclude other content. Since iframes are not being considered (at this point) in this spec (just img elements and maybe elements with background images), this is additional variability that would potentially decrease reporting value.

Yes, only resources in the current browsing context are measured. An iframe can still measure its own resources though (every window has its own performance object). And the entry creation will not be based strictly on visibility, so elements occluded by transparent iframes would still be reported.

> * The auto-inclusion _seems_ nice, but will add a tremendous amount of variability to the feature that seems like it will be challenging to rationalize and get interop across user agents--thus if an origin wants to compare data across user agents, the correlation may be difficult, leading to uncertainty and lack of confidence in the feature.

We’re thinking of adding some way to identify the element due to this problem (and to help make the API more actionable), for example the URL. Do you think that would help with this concern? Note that entries that are auto-included can be distinguished from entries that are registered via the ‘name’ attribute.

> * 'elementtiming' as an attribute on an element seems quite redundant. Perhaps something a bit shorter like 'timingname' or 'timingid'?

Yea we could go with those, but we wanted to choose something that would not collide with other usage. We’ll discuss these options with the WebPerf WG.

> * Would like additional clarity on the cross-origin availability of this data. E.g., is it proposed that all "hero" timings (including the auto-added items) be available in the performance entry lists for all browsing contexts or just the top browsing context?

Hero timings will be available in the browsing context that contains the element. If a top-level browsing context contains an <img>, then the entry will show up there. If this context has an iframe which contains another <img>, then the entry for this image will be available only in the iframe. This is consistent with how it is handled in ResourceTiming.

> * We suppose that the `elementtiming` attribute, if present in a closed ShadowRoot, would still be included in the Performance timeline? This might break an invarient of the closed ShadowDOM principles?

I agree that a closed ShadowRoot should not report any timing information to DOM trees containing it.



> This would be a interesting feature for larger scale projects (with disciplined development practices and a strict review process), but feels like (in the average case) this is a property that could easily be "leaked" out into the wild unwillingly by busy developers on a tight schedule. Given that there is potential that this could also leak out in templates/libraries/components, it feels like there should be a mechanism that acts as a global off switch (equivalent of #ifdef DEBUG 0) so that you don't have to go in and patch up a bunch of third party code.

Not sure I understand what you mean by ‘leak’ here? Javascript should intentionally query for entries or use PerformanceObserver in order to obtain the entries.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/326#issuecomment-461927476