[ResourceTiming] Resource timing details

Now that some of the higher level issues are resolved, I took a more
detailed pass through the spec. This is kind of a mix of questions and
comments.

*Section 4.2*

> "A downloadable resource is any resource that the user agent asks the
networking layer to retrieve."

I believe this means we won't have entries for data: URLs. It might be nice
to explicitly mention that in an example.

In general, this relies too heavy on examples. The examples should be marked
non-normative and we should have an appropriate normative description.

*Section 4.3*

> type attribute

Apologies if this has been covered, but what is the rationale for basing the
type attribute on the initiator element rather than content-type of the
resource?

> url attribute

I think we all understand this, but the spec should probably explicitly
state that this is the resolved URL (as opposed to the string found in the
attribute). http://dev.w3.org/html5/spec/Overview.html#resolve-a-url

> fetchStart attribute: "This attribute must return the time immediately
before the user agent starts to fetch the resource."

This doesn't seem to adequately distinguish it from resourceFetchStart
(which I believe we discussed should be renamed resourceStart).

> fetchStart attribute: "This time should not be overwritten if the user
agent retries fetching the same resource due to failures."

This sounds like a must-level requirement rather than a should-level. Also,
wouldn't this be true of some other attributes as well?

*Section 4.4*

> clearResourceTimings method: Only the first 150 PerformanceResourceTiming
resources will be stored, unless otherwise specified by the user agent or
setResourceTimingBufferSize.

This sentence doesn't relate to the functioning of this method. The buffer
limit behavior needs to be specified in the processing model.

> getResourceTimings method

I thought we talked about dropping the get-by-type functionality. Shouldn't
this instead take an optional location and then we can drop the
getResourceTimingsByLocation() method?

> setResourceTimingBufferSize method: If this method is not called, the
default maximum number of PerformanceResourceTiming resources stored is 150,
unless otherwise specified by the user agent.

This needs to use more precise verbs defined in section 2 (MUST,
RECOMMENDED, etc). I think the buffer size should be a variable defined and
used during the processing model. The normative requirement for this method
should really just be something along the lines of "The
setResourceTimingBufferSize(size) method, when invoked, must set the value
of |resource-timing-buffer-size| to |size|"

> onbufferfull attribute

Do we still need this handler? Isn't it enough to be able to control the max
size?

*Section 5.1*

These requirements only describe the behavior for each resource, but they
should also include the behavior during the overall lifecycle of the page
(for instance when is the resource timing list created/destroyed, when does
resource collection begin/end?)

These requirements need to explain when a resource is actually added to the
resource timing list. Is it added at resourceStart or at responseEnd. If
resourceStart, then we also need to define how the rest of the attributes
behave while the fetch is pending.

This also needs to explain what happens when the buffer limit is reached.
For instance, do additional resources get dropped on the floor or does
everything get shifted? At what point in the steps is the buffer limit
checked?

When and exactly how the url and type attributes are populated is also
missing.

> For each resource initiated on the page:
This isn't specific enough to be implemented. It should be tied to something
in the HTML5 spec.

> If the fetched resource results in an HTTP redirect or equivalent, then...
Since this happens after all the other attributes are already set, it would
be possible to observe a redirect resource with all the network values in
place for the redirect itself, before they have flipped over to the resource
being redirected to. I don't think this is what we want.

-Tony