Bug 202661
| Summary: | Add support for Element Timing | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Jash Sayani <jashsayani> |
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | Normal | CC: | achristensen, beidson, bfulgham, joepeck, youennf |
| Priority: | P2 | ||
| Version: | Safari Technology Preview | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Jash Sayani
Add support for Element Timing API: https://wicg.github.io/element-timing/
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Brent Fulgham
As discussed in webkit-dev mailing list:
"Apple's WebKit team reviewed this API and we have a few concerns including
but not limited to:
- The proposed API exposes timing at which a given element is painted.
Implemented naively, this exposes the implementation detail of what kind of
compositing tiles are used on a given web page. Hiding this
implementation detail and recording the exact theoretical paint timing will
be prohibitively expensive to do on all websites.
- The definition of the set of owned text nodes and how they compute
intersectionRect seems inadequate. It's unclear what "border box" of
*Text* node would mean. The spec doesn't seem to ever populate "set of
elements with rendered text" either.
- The use of this API seems to incur a significant runtime as well as
memory cost."
Moving to "RESOLVED | WONTFIX". We can reopen if we revisit this, or the spec issues are resolved.