- From: Nicolás Peña <npm@google.com>
- Date: Mon, 11 Mar 2019 14:44:31 -0500
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CAAATDikaWayOq=S3FOLx26GquW+iwTYUCX=t7vkb2ZzJ8eMNOA@mail.gmail.com>
Hi all, I've triaged User Timing L3 issues <https://github.com/w3c/user-timing/issues> and I think there are no bugs blocking Chrome from shipping the L3 version which is now in draft version. Here are my thoughts on the outstanding issues: - Issue 40 <https://github.com/w3c/user-timing/issues/40>: editorial work, no changes to API itself. - Issue 47 <https://github.com/w3c/user-timing/issues/37>: editorial too. - Issue 25 <https://github.com/w3c/user-timing/issues/25>: I think we do not intend to add a 'severity' field for this use case. Even if we did, it would have to be a new field and should not affect existing fields of the API. - Issue 17 <https://github.com/w3c/user-timing/issues/17>: there are lots of ideas here, but the core use case is measuring rendering times of elements, which is what our ElementTiming proposal is about. This is probably out of scope of UserTiming. If it was added, it would not break the existing processing. - Issue 15 <https://github.com/w3c/user-timing/issues/15>: the proposal seems more related to our new EventTiming API, and thus also out of the scope of UserTiming. Even if implemented, it would be a completely new feature that should not break the existing processing model. Given my assessment of these issues, I believe there are no blockers for an implementation (Chrome) to ship. Let me know if there are any questions or concerns. Thanks!
Received on Monday, 11 March 2019 19:45:07 UTC