Element Timing API - Githubissues

mozilla / standards-positions

https://mozilla.github.io/standards-positions/

Mozilla Public License 2.0

635 stars 69 forks source link

Element Timing API #192

Open digitarald opened 5 years ago

digitarald commented 5 years ago

Request for Mozilla Position on an Emerging Web Specification

Specification Title: Element Timing API
Specification or proposal URL: https://wicg.github.io/element-timing/
Mozillians who can provide input (optional): @ecsmyth, @vickychin

Other information

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

dbaron commented 4 years ago

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

martinthomson commented 4 years ago

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

sefeng211 commented 2 years ago

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

smaug---- commented 2 years ago

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

emilio commented 2 years ago

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 commented 2 years ago

Elements inside shadow trees are not exposed as the resolution of https://github.com/WICG/webcomponents/issues/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.