W3C home > Mailing lists > Public > public-web-perf@w3.org > March 2019

User Timing L3 Bugs Triaged

From: Nicolás Peña <npm@google.com>
Date: Mon, 11 Mar 2019 14:44:31 -0500
Message-ID: <CAAATDikaWayOq=S3FOLx26GquW+iwTYUCX=t7vkb2ZzJ8eMNOA@mail.gmail.com>
To: public-web-perf <public-web-perf@w3.org>
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

This archive was generated by hypermail 2.3.1 : Monday, 11 March 2019 19:45:08 UTC