Re: [ResourceTiming] initiator types

On Wed, May 16, 2012 at 4:33 PM, James Simonsen <simonjam@chromium.org>wrote:

> 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.
>

Exactly. Similarly, I don't think something like "subdocument" gives enough
benefit to justify a new term for web developers to learn. In practice,
there are almost no pages on the web that use both frames and iframes and I
don't expect that to change.

I understand that in theory a predefined list of types could make sifting
through the data easier, but I think the list that's there now only does so
for a very specific set of use-cases. Finding a list that works well for
all use-cases seems impractical to me.

In practice the list of tagNames + constructor names that can cause a
resource load is not that much longer than the current list, so I don't
think it would making filtering/sorting harder.

Ojan


>
> 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
>>
>>
>>
>