Re: [ResourceTiming] initiator types

I kinda like the idea of exposing more detail. If users want to track
different elements separately, then they should be able to do that. I don't
know that the way we've bucketed things is right for everyone.

For instance, we're assuming the app is predominately HTML. However, if it
was mostly SVG, then it's not helpful for us to clump all the SVG elements
into one bucket.

James

On Tue, May 15, 2012 at 5:15 PM, Jatinder Mann <jmann@microsoft.com> wrote:

> The goal of the initiatorType attribute was so developers can easily
> categorize and sort their timing information by the type of initiators.
> Developers generally know their own markup and the element tags they've
> used, so I don't think the goal is necessarily to iterate through exactly
> every type of element used.
>
> Using the element's localName and the JavaScript object's constructor will
> give the same sort of information to developers and eliminates the need for
> an "other" bucket. However, I wonder if this will make the initiatorType so
> noisy that its less useful as a filtering/sorting technique. For example,
> all the various SVG elements would be reported individually as opposed to a
> general "svg" bucket. Also, iframe and frame would be reported
> individually, as opposed to a general "subdocument" bucket.  A pre-defined
> list of initiator types may make the goal of sorting the data easier.
>
> I'm not opposed to making a change here. I agree that we should make the
> feature simple enough that a developer doesn't need to refer the spec every
> time they are using the feature. However, I think we should make sure the
> feature is still achieves its goals.
>
> I will add this topic to our conference call agenda and get back to this
> thread.
>
> Thanks,
> Jatinder
>
>
>