Consider refactoring navigation-timing to extend resource-timing about navigation-timing HOT 9 CLOSED

We have attributes that were surfaced in one but not the other (e.g. linkNegotiation{Start,End}), and others use out of sync language, etc... big +1 to this!

As we discussed on the call today, it seems like we can build NT on top of RT?

/cc @plehegar

from navigation-timing.

How would the prototype chain look like? We have 2 choices imho.

1. we simply add NT attributes into the RT interface:
   partial interface PerformanceResourceTiming {}
2. we extend the interface and define the NT attributes there:
   interface PerformanceNavigationTiming : PerformanceResourceTiming {}

I believe option 2 is the least disruptive.

from navigation-timing.

NT is a superset of RT.. +1 to option 2.

from navigation-timing.

+1 to option 2. Also, "algorithm" piece of the spec that refers to these fields should probably also be a pointer to a section within resource-timings spec as well.

from navigation-timing.

A lot of the attributes in RT have the following text:
[[
If the last non-redirected fetch of the resource is not the same origin as the current document, secureConnectionStart/responseStart/requestStart MUST return zero unless the timing allow check algorithm passes.
]]

However, NT doesn't have the text. I presume this is intended and will have to be taken into account, correct? Ie the the document being navigated to isn't from the same origin, you still return a proper value (and not zero).

from navigation-timing.

RT has initiatorType but NT doesn't. How about, in the case of NT, we return "navigation" for initiatorType (same as entryType)?

from navigation-timing.

Reassigning this one to me so that I get around it.

from navigation-timing.

See #36

from navigation-timing.

Resolved via #36, closing.

from navigation-timing.