Dru pointed out HTML Overlays which are the application of XUL Overlays (for Firefox and Thunderbird) to HTML.
Basically the idea is to break up a document into two groups:
- The parts that change.
- The parts that don’t (like the template).
The first group is actually delivered in the requested document. The second group is dynamically inserted by Javascript. The idea is that the script and the static parts will be cached on the browser, greatly reducing bandwidth and the load of the server.
1
Looks interesting. It would be nice to allow the linking of multiple overlay files though.2
However, in many ways this is just a more primitive version of XSL templating. XSL suffers three main disadvantages (in order of decreasing importance).
- Web developers and designers don’t think in the “callback” mentality that XSL demands.3
- XSL requires a lot of processing power and RAM. The former will cause noticeable delays in busy websites; the latter is in short supply on a web application server.
- XSL-T née XSL is overly complex. It was designed to transform XML to XML, not act like a simple templating language.
This hard-earned knowledge was based on past experiences:
- In early 2000, I built an entire portal using XML + XSL processed on server-side. You would start with an XML content file written in any language4 and, using various processing rules. it would add the chrome, navigation elements, pagination, banner ads and contextual hyperlinks. Before launch I found out that I couldn’t train the content people how to write XML nor the web developers on how to make XSL-T. But damn, it looked cool! (It was a game site.5)
- Later that year I built a hotel search engine that would render a results set in XML. Since I didn’t have access to the presentation server, I used XSL-T on the application server to write the result set as HTML for rendering. Again, it was impossible for the designers to iterate after the XSL-T template had been made from their initial designs. Once I was able to hack it into the website, the product never got rev’d.
- Had it been launched, speed would have become a serious issue in the first case. The templates were lightweight enough in the second that it never became an issue. In both instances, I was depending on Moore’s Law to take care of this problem.
I had gotten into an argument with Sterling last year about this. Sterling had written a hyper-fast XSL-T compiling processor into PHP.6 See my problem? The issues in my case were always developer/designer time (reasons 1 and 3), not CPU time (reason 2). I felt Sterling was solving the wrong problem! Basically, XSL-T had a bunch of negatives with not one single redeeming feature.
Sterling then pointed out something I hadn’t considered: in the intervening four years, web browsers had appeared that could do XSL processing on the client-side and cache the XSL-T sheet. This meant that you could offload the processing to the client and deliver a lightweight XML document containing only the “differences” and leverage your XML-XSLT workflow. (That sounds a lot like HTML Overlays.)
Of course, HTML Overlays has one thing going for it that XSL-T doesn’t. It’s not complicated (3).
But it still doesn’t address the callback issue (1).
3 What is a callback template? This is a bottom-up approach in which you create a set of event-based rules. It is like saying, “If you happen across something called navigation then insert this your HTML page.” It’s like listing the parts of the page methodically the way your left brain does.
The problem is that in the callback mechanism, you have to build the entire page before you can “see” what it is going to look like.
It is important to realize that most people design top-down. By this I mean they design a page by segmenting the page into areas that it may be composed of and is like saying, “The page consists of a navigation header, footer, and body here like this.” and then they break the body into the parts it is composed of, and so on. This is a neatly hierarchical view in which you can visualize the page layout in the same way that your right brain composes it.
I chose XML because it was built to handle any character set. The site had to run in Japanese, Korean, Chinese (Simple and Traditional) as well as English. Using an XML file would ease internationalization and localization since only the XML file needed to be translated. The XSL-T processor would decided on which stylesheets and headers to provide to add the proper localization. I never figured out if this would work though. I know the XML file could write Japanese, but I never got to switch out any chrome other than the stylesheet used. And since this was still the days of Netscape 4, that didn’t amount to much!
He created this for a company that will remain nameless. In my opinion, “the idea is bollix!” (in my best Theis Germanic lisp).
One thought on “HTML Overlays are bollix”