<Glazblog/>

HTML 5 needs a way to say some element's contents are ajax-based

Webchunks (the Firefox add-on) lets you select an arbitrary element in a web page to turn it into a webchunk. Nothing magical here. A Webslice is, per Microsoft's "spec", an element carrying an ID and the class slice. In other terms, an element selected by the selector #thatID.slice. Webchunks just extends that notion to be able to use here any CSS selector, not only that one.

But selecting an arbitrary element can lead to unexpected results. Let's take a concrete example :

  • the web page liberation.fr has a block of recent news on the right hand side ("Dernières Dépêches")
  • that block can be selected using the selector #e1b3-1
  • but the contents of that block are not available at load time but rather ajax-based...
  • so comparing a cached version of that element and a recently downloaded version is meaningless if you don't let all JavaScript code in the page run and compare them only afterwards...

I am then unable to say liberation.fr updated its Last News section just loading the source of that HTML page... Painful.

Conclusion : I miss here something standard (an attribute, a class, whatever and I don't care) in the DOM to let me know the contents of that element are retrieved over the wire after page load. I also miss a standard event allowing me to know the contents are now loaded and that the "final" content of the element can now be observed.

Comments

1. On Thursday 12 November 2009, 10:11 by glandium

There are much more ways to have generated content in a web page than ajax. Having information at HTML level is making sure nobody will put that information (we all know how standards are followed by web programmers).
What you need, really, is a way to know if the DOM under a node has been modified after page load. It is more likely browsers will eventually implement this than web programmers to do the right thing.

2. On Thursday 12 November 2009, 10:42 by AndersH

(I haven't tested any of this)
Well, in this particular case it isn't quite ajax, since it is not async (the update is kicked off by the inline script-block "bloc_depeches(1);") and there is no XmlHttpRequest involved (the data is from the "depeches"-array included in the page itself). This also means that not only is the page done when "onload" fires, but it is even done when "DOMContentLoaded" fires, and you could even test the page for changes without running it.

I guess you could wait for onload and any XmlHttpRequest requests that might be in progress (e.g. because it has been kicked of by the onload handler it self). But then there will always be some page that wraps the call in a "setTimeout(..., 0)".

If pages had to raise a "done" flag (for which I guess the definition would be quite hard) them self with no benefit to the user, nobody would use it, or they would raise it early if it made the browser turn of its "loading" indicator to make it seem to the user as if the page loaded faster than it did.

3. On Thursday 12 November 2009, 10:51 by Fabrice

Daniel, what about using DOM mutation events, like DOMSubtreeModified or DOMNodeInserted ?

4. On Thursday 12 November 2009, 10:55 by Dominique De Vito

While you are talking about HTML 5+AJAX, beyond static/dynamic separation, I think HTML 5 is going too to need an application view of HTML elements.

See the section "Idea No 2: an application view is needed within HTML" (encompassing multiple web pages/JS files) into :
GWT and Jetpack are going to shake up the web-based (RIA) desktop application landscape
http://www.jroller.com/dmdevito/ent...

5. On Thursday 12 November 2009, 14:02 by JulienW

How about aria attributes ? There is something about "live regions".

6. On Thursday 12 November 2009, 14:32 by Da Scritch

first one, not talking about "ajax", but more about "xhr" or better, "dynamic"

rel="source-dynamic" ?
type="dynamic" ?

7. On Thursday 12 November 2009, 23:15 by Colby Russell

Julien, indeed. Daniel, see http://www.w3.org/TR/wai-aria/#live... http://www.w3.org/TR/wai-aria/#aria... is the appropriate section dealing with this.

8. On Friday 13 November 2009, 11:19 by glandium

Very frankly, anything based on the developper adding attributes is doomed to be an epic fail. Only a handful of sites will ever implement such attributes.

9. On Sunday 15 November 2009, 20:10 by Jj

What about using rel and <link/> that are already part of HTML?

In ajax based links, it's a good practice to set the endpoint as the href and have its behavior altered with Javascript.

for an onload loaded element, say an updates ticker, the div (or whatever DOM) could have a rel attribute ponting to the source's endpoint.

Just like in <link rel="next" href=""/>