RE: [Resource Timing] Initiator Types

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.

As for the SVG tag, you are correct, it should state resources downloaded due to children of the SVG tag (eg SVG's script), should be included under INITIATOR_SVG.  The <svg> tag itself cannot have a link to an external .svg file.  Note that there are other ways of including external .svgs, via EMBED, OBJECT and IFRAME tags, but those should be covered under INITIATOR_EMBED, INITIATOR_OBJECT and INITIATOR_SUBDOCUMENT respectively.

- Nic

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 they're own class of entries on the Performance Timeline.

INITIATOR_SVG

This one says it's used if "the initiator is the <svg> element," but there's no way for the <svg> element to load something. Should this instead read "elements in the SVG namespace?" That would pick up SVG's <script> or <font-face-uri> for instance.

James