Re: [Resource Timing] Initiator Types

Sorry to revive this thread from the dead.

At one point, we'd explicitly removed <audio> and <video> tags from
Resource Timing. This thread appears to be where we agreed to remove them.

Since then, we removed the enum of initiator types, so it's no longer clear
that <audio> and <video> are missing. Worse, we still list them as examples
of things that should show up in Resource Timing in section 4.1.

I think we should explicitly say these elements are excluded for the
reasons listed below. It's already on our charter to support them in
Resource Timing 2.

James


On Wed, Aug 31, 2011 at 1:42 PM, Nic Jansma <Nic.Jansma@microsoft.com>wrote:

>  As a follow-up to our conf call today, we agreed to remove resources
> associated with VIDEO and AUDIO tags (INITIATOR_AUDIO and INITIATOR_VIDEO)
> for now, as there are several complex scenarios associated with downloading
> resources via those tags (streaming scenarios, range requests, seeking,
> etc).  We may be able to tackle it better with guidance from another W3C
> group.
>



> *From:* public-web-perf-request@w3.org [mailto:
> public-web-perf-request@w3.org] *On Behalf Of *James Simonsen
>
> *Sent:* Monday, August 29, 2011 5:37 PM
> *To:* public-web-perf
> *Subject:* [Resource Timing] Initiator Types****
>
> ** **
>
> I have a few questions on the initiator types:****
>
> ** **
>
> INITIATOR_AUDIO****
>
> INITIATOR_VIDEO****
>
> ** **
>
> These ones are a little tricky to time. They don't necessarily load like
> other resources. Sometimes they're never-ending streams. Sometimes they're
> only partially loaded (user skips ahead). And sometimes they're only loaded
> lazily when the user hits play. I could imagine a situation where we had to
> open multiple connections too, which would make some of the timing
> attributes ambiguous. What are we supposed to do in these cases?****
>
> ** **
>
> It's possible that Resource Timing isn't sufficient for describing these
> elements. Maybe they should have their own class of entries on the
> Performance Timeline.****
>
> **
>

Received on Thursday, 21 March 2013 01:08:54 UTC