[whatwg] API to delay the document load event (continued)

[James Burke]

On Tue, May 7, 2013 at 3:12 PM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
> * James Burke wrote:
>>I just joined the mailing list, so I apologize for not continuing the
>>existing thread started here:
>>
>>http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-April/039422.html
>>
>>Disclaimer: I submitted the Mozilla Bugzilla ticket for some kind of
>>capability in this area.
>>
>>Summarizing previous discussion points:
>
> I think it would be helpful if you could phrase these in terms of what
> various implementations should do. For instance, Google shows screen-
> shots in search results. How should their "take a snapshot" bot work? I
> maintain IECapt and CutyCapt; how should they be changed to support the
> feature being proposed here? Same question for the Firefox and Firefox-
> OS features that motivate creating a new feature here.

If this feature uses the "load' event, as long as those tools listen
to "load", that is enough: when they receive that event, the page
should be rendered in the state the web site developer wanted.

If a use case is identified that makes it difficult to use the
existing "load" event, then the tools would need to listen to a new
event. They would also need to inspect the document state (maybe by
checking for a "loading" attribute on the documentElement?) to know if
this new event is in play.

> Similarily, it would be helpful to approach the problem from the per-
> spective of content creators. Let's say you have a website, and any new
> visitor gets to see an overlay that "encourages" them to "sign up with
> Acme". When would this site signal that it is "ready" for the purposes
> I've mentioned? And would all of the implementations cited above wait
> for this signal?

If the "load" event approach was used, the web site would:

* call document.delayLoadEvent() during JS execution (needs to happen
before the browser would normally trigger the load event).
* Once the Acme overlay DOM element was inserted, call
document.stopDelayingLoadEvent()
* The platform waits for any images/resources for the current DOM to
finish loading. It then fires the normal document load event.

For tools that are listening:

* Just listen for the "load" event for the document.

---

If a separate event/trigger instead of "load" is used, then I am not
exactly sure what is needed. One guess:

For the web site:

* stamp the DOM in some way to indicate this new event would be fired,
perhaps add the "loading" attribute to the documentElement.
* insert the Acme overlay DOM element, then remove the attribute.
* The platform waits for any images/resources for the current DOM to
finish loading (?) then fire "appload" event?

For tools that are listening:

* Inspect the state of the page, looking to see if there is a
"loading" attribute in play. Listen for both "load" and "appload", and
if the "loading" attribute was detected, wait for the "appload" event.

In fact, the tool needs to discount "load" if the page detects
"appload" is in play as it may fire. (So, in response to one of
David's comments, trying to fallback to "load" would not be
feasible/detectable).

James