Re: User Timing L3 Bugs Triaged

Nice, thanks for triaging these Nicolas! Overall, agree with your
assessment that there shouldn't be any blockers here.

There is a common theme running through #40 and #25, which I'd love to get
more input on from folks working on DevTools and JS frameworks, before we
close them out. Given that dev tools integrations has been one of the key
drivers for UT adoption, and popular JS frameworks have expressed interest
in integrating with DevTools, this seems like an area we should explore a
bit more. That said, none of this is blocking, even if we decide on adding
some new attributes, they would be incremental to what we already proposed.

On Mon, Mar 11, 2019 at 12:45 PM Nicolás Peña <npm@google.com> wrote:

> 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!
>