Slashdot Mirror

I'm not so up to date what's the current state of the art, but some years ago, when I was applying DHTML, I always found Dan Steinman's Tutorial Dynamic Duo very helpful (thanks Dan!).

It has been continued as DynAPI

I'm a PHP kinda guy, but somebody already mentioned the PHP manual (which is all I've ever used), so I thought some DHTML resources:

Hold your breath and try MSDN. It's got everything about everything for MSIE, from HTML to scripting, from tutorials to reference. I'm not a big fan of Microsoft, but MSDN is truly useful. It's also a good reference for CSS2 properties, since these are thankfully the same (and reasonably well supported) on both MSIE and Mozilla.

To ensure cross-browser DHTML compatibility however, cross-reference with the Gecko DOM reference from the Mozilla project. It's DHTML for Mozilla; the model is completely different sadly but it works, and it's possible to write code that works for both MSIE and Mozilla/Gecko simultaneously with a little thought -- I learned most of what I know from Dan Steinman's excellent dynamic duo site.

If you're also using PHP, then you'll probably end up using MySQL as well. I learned most of the SQL I know simply by reading the MySQL manual. It's just as useful as the PHP Manual.

There may be javascript tricks you could do with HTML too, now that I think about it.

Yeah, actually... I haven't played with Mozilla much, I'm sure there's a relatively simple way to do it, but with IE and hidden iframes, you can send and retrieve arbitrary data to the server without reloading the page at all. Since IE can dynamically rewrite (almost) any part of the page, you can update the data on your page, or even the UI, while still working off of the same "document". Great examples of how this is used well are all the web apps for doing taxes that I saw this year. Hell, look at MSDN online, they use DHTML all over the place to make it just that much nicer for the user. It was very nearly like using a native application, except no downloads and a little slower at runtime.

Most of what you would want to do is also possible in NS 4, but not nearly as easy as in IE. And NS 4 is definately quirkier in this aspect, and more prone to crash.

Even cooler is IE 5+'s (and I think Mozilla, now, but I think the mechanism is slightly different) ability to generate and view HTML pages with XSL + XML on the client side. So you could hit a site, and it would return an XML document with a processing instruction specifying the location of the XSL... IE will just grab the XSL and use it to transform the XML into HTML, and then display that resulting HTML. That's okay, but also easily done on the server side. The really interesting thing is that you have access to both the XML document and the XSL document via a DOM interface from the client-side javascript. So you can modify your XSL document and then re-transform parts of the XML document into HTML snippets, and then replace parts of the current page with the resulting HTML.

It makes for a very responsive web application - feels like a sluggish native app instead of a set of web pages - but it locks you down to a platform fairly prohibitively. NS 4, Opera, Lynx and most other "independent" browsers do not have XML+XSL support, so you pretty much lock those out. You can't use the same XSLs for server-side transforms and client-side transforms if you want to do the dynamic client-side stuff, really. There might be a way to do a Mozilla and IE cross-platform solution with this, but I haven't investigated it at all.

We did a lot of this at my last company. We had a web application for managing certain database objects, and you could run searches and you'd get back a data set by loading the data (as XML) in a hidden frame, then we could sort the data by making a strategic change to the XSL in memory and retransforming a strategic part of the XML, so it happened in a blip. We even supported pagination completely on the client - we were in a situation where the client to server network connection wasn't really the bottleneck, since both were intended to be on the same internal network. Client memory/rendering speed was the bigger bottleneck. Both bandwidth and table-rendering speed cause this sort of thing to really stop scaling for larger datasets. It also uses a TON of memory, because the (w3c) DOM is a bit heavy, and with this method IE retains everything in a DOM, whether you like it or not.

I suppose this is all somewhat off-topic to a story about a search engine, but this happens to be something I have worked with recently, so I thought I would mention it.

Other good DHTML links:

• Dan Steinman's Dynamic Duo - an good tutorial and DHTML platform abstraction library in JavaScript, but quite a bit slower at runtime than hand-coded DHTML
• HTML Guru - the site wasn't working too well for me just now, but last time I saw it, it did a good job of looking impressive while still being pure HTML+JS and cross-platform.

-If

as much as I hate to reply to my own messages, I did manage to find a site that talks about this "miniscroll" script library, and has a (dead) link to the source:

The Dynamic Duo

one example they show would/might be actually practical. There they have a much smaller layer region that is scrollable. I might actually want to use something like this on a project I'm doing at work.

Implementing this as they do on the supercables site is pretty useless (scrolling a long pane of images and text from top to bottom of the page), but I can see where this might come in useful if you wanted to display a long-ish list of info in a small region on a page and not try to deal with frames to do it.

---

This is a common complaint among developers who want to do relatively advanced dynamic stuff on the client-side - Netscape 4.x (which is still the most common Netscape in use, AFAIK) doesn't give the developer nearly as much as IE 4 does (let alone IE 5), and what it does, it does badly.

Put yourself in the shoes of the developer: You want to do a web app that does nifty UI stuff (because the standard HTML form controls don't cut it for anything other than the most basic interaction). You also want to do lots of live updating on the page without having to go back to the server, which is a reasonable request since you don't want to slow down the user nor overload your server. Netscape 4 makes it a complete pain to do this stuff well, and its API is almost totally incompatible with IE's. You're obviously going to want to cater to as large a share of the market as possible, so you go for IE, thinking you'll do a Netscape version later. (And even if you do get around to attempting the Netscape version, half of the time you'll give up out of frustration)

The usual argument against all the above is that as a conscientious web developer you should be sticking to established, open standards and not falling into the trap of using browser-specific features implemented by greedy companies who just want to get ahead in the web features game. Ironically, it's been my experience that Netscape had always, up until NS 6, been the worst offender here - for every new tag that IE ever stuck in, Netscape did two. And IE's implementations of existing standards have pretty much always (from IE 3 onwards, anyway) been more compliant than Netscape's. So bear that in mind before you start your usual rant against Micro$haft.

Anyway, the situation regarding sticking to standards is definitely better than it was. XHTML + DOM + ECMAscript + CSS2 gives you a ton of flexibility to do almost anything, and the IE 5 and Mozilla support for these is pretty good. Of course, you still have to do client-specific code if you want to do anything outside the browser (e.g. interacting with the rest of the client machine, which a trusted web app might want to do) and the arguments about how to implement this securely (or whether to implement it at all) are still raging. (Java Plug-In + signed applets is probably your best bet at the moment)

In other words, I believe the situation is going to get better, not worse, especially since the way it tends to work is

1. web browsers have new useful features added due to developer demand (useful as opposed to the features that get banged in due to an order from higher up, hated/ignored by all, and then quietly removed two releases later - hello, IE Channels!)
2. the W3C tends to follow suit once they see there's a large amount of developer demand
3. the browser makers move to implement the standard, since they've learnt the hard way that ignoring this is a bad idea

and these days, the browser makers actually go as far as submitting a standards proposal for the new stuff too, which is, of course, what they should have been doing in the first place.

As time goes on the standardised browser feature set gets more and more capable, which means less demand for new features, which means things can settle down. I hope.

BTW, for web developers looking for a nice cross-browser (works in NS 4) API to do dynamic stuff with, check out Dan Steinman's DynAPI.

-- Yoz, using too many brackets as usual

I found Danny Goodman's Dynamic Html : The Definitive Reference an excellent guide for HTML, DOM and JavaScript.

A few helpful sites:

• Dynamic Drive
• DHTML Guru
• Dynamic Duo (cross-browser DHTML API)

Online gaming for motivated, sportsmanlike players: www.steelmaelstrom.org.