The DIV_SRC Tool
Potential Problems in Using DIV_SRC
This section touches on a couple of problems that could potentially arise with the use of DIV_SRC, and suggests ways of handling them.
What if Some Page Pieces Never Arrive?
The Internet runs on the TCP/IP protocol, and it operates on a "best effort" basis; there are no guarantees that anything requested will ever arrive, or will arrive in its entirety. TCP/IP can detect when chunks of a page are missing, and will re-request missing chunks; but if the source server dies, or all network links to it stop working, then a page may be truncated. The situation becomes even more complex when DIV_SRC is used in an environment where networks are very unreliable. The base page may be fetched completely, but some of the secondary sections may be truncated, or not arrive at all.
If the web server is a news feed and some articles don't arrive at the users' browsers, or are truncated, it's probably not too serious. If the network's that bad, it's likely that even an old-fashioned monolithic page would have been truncated. On the other hand, it often happens that a particular server gets so overloaded (it gets Slashdotted, for example) that it discards a large percentage of the requests sent to it. If the server's content had been segmented with DIV_SRC then many / most of the remote users would get copies of the various page segments that it serves from caching proxy servers in their upstream network connections, relieving pressure on the source web server and reducing the number of dropped connections. So if you run a news feed server, you may be able to deliver more stories to more people more reliably by using DIV_SRC than by using large, monolithic pages with short expiry times. At least that's the theory. It's too early to tell how this thing will pan out.
If you're planning to deliver a legal document to a browser user then partitioning it into segments and using DIV_SRC to deliver them is probably a bad idea. If it comes to that, an HTML page would also be a poor choice for this application. Rather format the document as a PDF and invite the users to download it and open it on their own PCs. The Acrobat reader will tell them if the document is incomplete or corrupt, and refuse to open it.
What if I need to Change a Page Piece?
Suppose a news feed service breaks their content into pieces and uses DIV_SRC to deliver them, and one of their stories has to change; perhaps more information comes in and the story needs to be corrected or expanded. But copies of the story have already been distributed to browser users, and are cached in browsers and caching proxy servers. How can the news feed service make sure that their subscribers don't continue to see the old copies of the story? It's quite easy – they change the name of the file segment that contains the story. Remember that all of their stories are referenced by the base page that they deliver, and they can continue to set headers that limit the time that caching servers can hold a copy of their base page, just as they do today. When they change the story, they give the file that contains it a new name and update the base page accordingly. Anyone who gets a fresh copy of the base page will get the latest versions of the stories that it references.
Apart from this technique, web server administrators are still able to set the HTTP headers that will be delivered with page pieces, and these can include caching directives that will govern how long the page pieces can remain in cache before they must be refreshed. This is how administrators manage the cache times for normal HTML pages today.
What if the Page Already Has an onLoad in its <body> tag?
The recommended way of getting DIV_SRC to load referenced content is to run it as soon as the document has loaded by
While we're about it, let's also note that mobile screens are pretty small, and that large HTML pages swamp them. A growing number of popular web sites offer their content in two different formats, XL for normal desktop browsers (http://cnn.com/, for example), and "mobile" or "wap" for mobile devices http://cnnmobile.com/, for example). Wap sites are more compact, often showing a list of the various topics available rather than trying to cram them all into one page. The viewer can click on any topic of interest and see it in more detail, returning to the topic list when done.
Different applications may require different approaches, so we describe several different ways below in which DIV_SRC could be used to display content in such a way that it can be seen by either an AJAX-enabled web browser (generally a desktop browser) or a browser without (generally a mobile). The solutions fall into two categories:
If You Own the Web Server
If You Don't Own the Web Server
Increasingly, companies are offering space on their web servers to members of the public at little or no charge. People can register themselves on such sites and then upload whatever web pages they wish. Generally, people can't upload and run web applications on such websites, because these applications might interfere with the underlying service or one another.
Bimodal Page Segments
Starting with version 2.0, the DIV_SRC package has been enhanced to help websites to deliver their content in a "bimodal" mode, so that if a given browser implements AJAX, it can assemble the segmented content into a single large page, while if the browser doesn't implement AJAX (which at this stage of technology probably means that it is a mobile browser), it can nonetheless deliver all of the content of the composite page to the browser user, but in a segmented mode where each page segment is presented as a separate small HTML page, and yet the user can move freely between the various page segments.
DIV_SRC has been changed so that it does not remove or replace the content enclosed within the DIV_SRC tags that it discovers. This content becomes the default, which will remain visible in browsers that don't implement AJAX. The default text can contain a brief description of the content of a page segment, and a hyperlink to it. If the user wishes to see that piece of content, he or she click on the link provided. After viewing the segment, return links will bring them back to the page from which they came. A DIV_SRC tag with default, non-AJAX content might look like this:
<div src="URI"><a href="URI">URI Teaser</a></div>The URI Teaser will give the browser user an indication of what content deals with. Those that are interested in the teaser it can click on it, and its hyperlink will tell the browser to fetch the corresponding page segment and display it as a page in its own right.
If on the other hand the browser supports AJAX then DIV_SRC will replace the default tag content with the content
referenced by the
This approach is not in strict conformance with w3.org standards because the content referenced by the
Alternatively, the page segments could be composed without the
Null <div src="#"> References
When page segments are designed to be included into a single composite document, they would not normally
carry hyperlinks to one another or to the base page that includes them.
But when these same page segments are rendered as stand-alone pages in AJAX-challenged browsers, no navigational links would
be displayed to help users to navigate between segments.
To solve this problem and several other related ones, DIV_SRC now recognises a special "null" form of URI, namely:
The use of bimodal pages is illustrated in the mock newsfeed demo that forms a part of the DIV_SRC package. Bimodal pages will fragment large composite pages into many separately-viewed component pages, but this fragmentation may well be counted a blessing by mobile users.
How do we Test Mobile Browser Rendering?
Ultimately the only sure way of testing what mobile browser users will see is to use mobile browsers to do the testing. But this can only be done once the content has been uploaded to a public web server so the mobile browser can see it, which is tedious, and one runs the risk that members of the public will discover the test content and find it to be broken while in test.
Search Engines Won't Index Our Content!
Search engines won't follow
You're Breaking the Rules!!
The W3 Organization draws up and issues web standards, and none of their HTML standards permit the DIV, TD or SPAN tags to have SRC attributes, so DIV_SRC requires pages to be coded in HTML that does not conform to standards. Will this HTML break in some browsers?
I have so far tested DIV_SRC successfully in these browsers:
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">The second DOCTYPE references a DTD, and this DTD does not permit DIV tags to have SRC attributes, but the browsers that I have tested ignore this fact. Should it ever become an issue then we could create a variant DTD that permits DIV, SPAN, TD and other selected tags to use the SRC attribute. I'm not offering to host that DTD, the access frequency could become large. But if asked, I would be happy to build one and provide it in zipped format for content providers who choose to use DIV_SRC to install on their own web servers.
I have also tested XHTML pages with the following DOCTYPE and namespace declarations:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">and they work fine too. In theory they shouldn't, since XHTML is a form of XML, and the rules state that is an XML document doesn't conform exactly to its DTD then it should be discarded. It looks like browsers still give us latitude, and if they stop doing so then we can, as with HTML, prepare and publish an extended DTD that permits SRC attributes where needed
While it's true that DIV_SRC requires the use of "illegal" tag attributes, browser builders are instructed to ignore
tag attributes that their browsers don't recognise so that they don't immediately break every time a new attribute is
Several major software projects depend on browsers following this rule.
The Tapestry web application development framework for example requires
the inclusion of the "illegal" attribute
Using DIV_SRC will mean that the HTML will fail syntax checkers such as this one provided by the W3 Organization. Since clean HTML is a really good idea, we need a work-around.
© Trevor Turton, http://turton.co.za, 2008-11-05