Completeness markers

James and I took a step back today to look at the completeness markers. Now
that things have settled down, we'd like to double check that we are really
happy with how they turned out.

We have:
*domInteractive* Marks completion of parsing. This means that the root
document has been fully received, all HTML has been parsed and all
synchronous (inline and external) scripts have been executed.
*domContentLoadedEventStart* Marks just before the DOMContentLoaded event is
fired. In addition to the above, deferred scripts have now been executed.
*domContentLoadedEventEnd* Marks just after the DOMContentLoaded event,
including time spent in any event handlers.
*domComplete* Marks completion of the document. In addition to the above,
async scripts have now been executed and all subresource loads have
completed.
*loadEventStart* Identical to domComplete.
*loadEventEnd* Like loadEventStart, but includes time spent in load event
handlers.

While we realize that different markers might be important to different
pages, it seems a bit hard to justify 6 markers. Some observations:

1. All of these metrics can be gathered without Navigation Timing by
listening to onreadystatechange, ondomcontentloaded and onload. So we are
just offering them for ease of access and lazy loaded scripts.
2. domComplete is identical to loadEventStart. Perhaps we should kill
domComplete like we killed requestEnd (which was identical to
responseStart). We talked about completeness of all ready state change
events, but is that really a good argument to expose an identical marker?
3. loadEventEnd and domContentLoadedEventEnd probably aren't too useful. The
*EventStart markers are useful because if a page doesn't have event handlers
for those events, they can still get the time without listening. But by
definition, if the *EventEnd markers are different from start, the page did
some work in the handler and could have easily marked a completion time
(either using Date() or the forthcoming User Timing). Perhaps we should kill
these two end metrics before we set a precedent that every event we measure
will have both start and end markers (which could be expensive for Resource
Timing). Note that unloadEventStart/End still makes sense since the page
could not have timed that event.

To summarize, we think trimming down to these 3 would make the interface
easier to learn and use without sacrificing any information:
*domInteractive *Immediately before readyState transitions to interactive
*domContentLoadedEvent* Immediately before the DOMContentLoaded event is
fired
*loadEvent* Immediately before the window's load event is fired
*
*
We'd like to consider this only if it won't put the IE9 implementation at
risk. Thoughts?

-James,Tony