Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Element Timing API #192

Closed
digitarald opened this issue Jul 19, 2019 · 10 comments
Closed

Element Timing API #192

digitarald opened this issue Jul 19, 2019 · 10 comments

Comments

@digitarald
Copy link

digitarald commented Jul 19, 2019

Request for Mozilla Position on an Emerging Web Specification

Other information

A similar metric approach has been used in Firefox's performance automation https://bugzilla.mozilla.org/show_bug.cgi?id=1418368 .

@adamroach adamroach added the venue: W3C CG Specifications in W3C Community Groups (e.g., WICG, Privacy CG) label Nov 16, 2019
@dbaron
Copy link
Contributor

dbaron commented Feb 27, 2020

There may be some useful info in w3ctag/design-reviews#326 and w3ctag/design-reviews#395.

@martinthomson
Copy link
Member

We just learned from Microsoft that this is shipping unprefixed in Edge and Chrome. We'd like to have a position soon.

@sefeng211
Copy link
Member

I think we can resolve it as worth prototyping, cc @smaug---- @Bas-moz

@smaug----
Copy link
Collaborator

@emilio might have an opinion.
I didn't immediately see anything too harmful.

@emilio
Copy link
Collaborator

emilio commented Oct 22, 2021

Yeah I don't see anything particularly problematic. I'm a bit confused about how nodes in shadow trees are intended to be handled.

https://wicg.github.io/element-timing/#get-an-element seems to try not to expose them (but seems like they should still generate an entry). But https://wicg.github.io/element-timing/#sec-element-processing doesn't handle shadow DOM and shouldn't even look at shadow trees. So something there is clearly confused.

@sefeng211
Copy link
Member

Elements inside shadow trees are not exposed as the resolution of WICG/webcomponents#816. If the #sec-element-processing step doesn't handle shadow DOM, then no entries will be generated for nodes in shadow trees, right? And this should be the desired behaviour.

@Bas-moz
Copy link

Bas-moz commented Nov 18, 2024

Based on the earlier comments it seems the standard looks reasonable.

As to the extend of timing leakage, which was discussed, we can apply the appropriate amount of jitter/clamping as we do with many other timings, and this in itself does not make for a concern with the standard.

As per Sean's comment, the shadow tree issue has also been resolved in the original standard.

I suggest our position here should be positive.

@zcorpan zcorpan moved this from Unscreened to Position is proposed in standards-positions review Nov 18, 2024
@zcorpan
Copy link
Member

zcorpan commented Nov 18, 2024

Is there an issue for moving this spec into the Web Performance WG (or somewhere else)?

@Bas-moz
Copy link

Bas-moz commented Dec 18, 2024

See: https://lists.w3.org/Archives/Public/public-web-perf/2024Dec/0005.html

This now lives here: https://w3c.github.io/element-timing/

@zcorpan zcorpan added venue: W3C Specifications in W3C Working Groups position: positive and removed concerns: venue venue: W3C CG Specifications in W3C Community Groups (e.g., WICG, Privacy CG) labels Dec 18, 2024
@zcorpan zcorpan closed this as completed Dec 18, 2024
@keithamus
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Position is proposed
Development

No branches or pull requests

10 participants