Sexy DHTML Tricks Abound!

July 7, 2000 10:25 PM

Sexy DHTML Tricks Abound! Have you seen the DHTML pop-up items at PHP.net? These things are cool, cutting edge and amazingly groovy! Nice to see additional features added to the page without bloating the design. I like it! (DHTML compatible browser needed!) [ref: nublog!]
posted by DragonBoy (21 comments total)

In a similar vein, I love copyleft's search mouseover dhtml, it has the gee-whiz factor, plus the graphics work very well with the 50's kitsch.
posted by mathowie at 11:01 PM on July 7, 2000

Is it just me, or are most people not seeing the potential of DHTML?

I mean, so far, all I've seen it used for is gay popup menus and cheesy things that follow the cursor...

Woo! I can move things based on the position of the mouse!

I'm sorry, but CSS lets you do WAY more cool stuff than that... Basically as soon as we can embed postscript into html (or eps or some shit) we'll have no need for flash... You can already do everything else... (that I can think of)...

I've been looking at it... and, you could prolly write a whole word processor in dhtml... I bet you could port WordPad to it fairly easily... (still not easy)

And, through the curse^H^H^H^Hmiracle of Microsoftisim^TM you can do all sorts of whacked stuff...
ever seen a DirectX OCX controlled by dhtml?

posted by Bane at 1:39 AM on July 8, 2000

allow me to be the first to introduce topic drift to this thread by saying that "gay" used synonymously with "lame" pisses me off no end. thank you, now back to regularly scheduled idle chatter.
posted by Sapphireblue at 8:11 AM on July 8, 2000

But to drift some more... didn't "gay" once have another definition, meaning something else entirely?
posted by owillis at 8:21 AM on July 8, 2000

Nope, it didn't.
posted by alana at 9:08 AM on July 8, 2000

Maybe I'm just old fashioned, but I *hate* it when UI elements jump up and bite me without provocation. Yeah, php.net's layout is all nice and groovy if you're a cutting-edge-web-gadgets fan, but it's a damned nuisance to have to carefully keep track of where your mouse is so you don't accidentally cross one of the magic zappy things that take over the part of the screen you were trying to look at. The convention that a UI element is not triggered until the user actually clicks on it exists for a very good reason: it makes sense, and if you break it, the UI becomes much more difficult for the user to understand and navigate.

It's like that old game we used to play as kids where you had to walk through the entire store only stepping on the grey tiles, never touching the white ones... lots of fun, but it took an hour to get the shopping done, and that never made my mum very happy. Now I'm all growed up and can see her point. Browsing the web that way is no fun.

Yeah, I'm sure there are plenty of other things you can do with DHTML that are less annoying. I'm still not looking forward to it - just look what happened when everyone discovered javascript.

-Mars

P.S. again, maybe I'm just old fashioned, but when I hear people use "gay" as a derogative I want to slap them.

P.P.S. No, I haven't had any coffee yet.

posted by Mars Saxman at 11:04 AM on July 8, 2000

The potential is definitely there for DHTML to cleanse the Web of the thing called Flash, but I don't expect that to happen, and that's just fine. The problem is that DHTML will probably always be more difficult to author than Flash, which makes Flash particularly well-suited to things like splash screens, intros, demos, and games. DHTML will continue to pop up in more subtle places - like navigation systems and more intelligent forms - more often than taking center-stage.

As far as what you're saying about Postscript, something similar will happen, eventually, via Scalable Vector Graphics. Scriptable, XML-based, low-bandwith, vector graphics. Good stuff.

If you're looking for some things that realize the "potential" of DHTML, I'd suggest checking out The 5k Contest, Terrarium, Borgstrom, and DoubleYou.

(And of course, there's another guy that used to do a lot more DHTML than he does now, but that could change sometime soon.)
posted by endquote at 11:16 AM on July 8, 2000

And as far as you were saying with doing a word processor online, that's exactly what MS will do with .NET, and already what HalfBrain did with its does-all-the-important-stuff version of Excel.
posted by endquote at 11:38 AM on July 8, 2000

DHTML has a big problem with compatability *cough (netscape) cough*, and I think that's why it's not catching on as much as it could. All the frustration of making a webpage compatable with both browsers must be tripled with DHTML. I do enjoy the popups, but some times when they don't go away that causes a problem, and if you take your mouse off the link sometimes it goes down before you can click on the text box.
And DAMN! Where did you find emucult? I've seen it 4 times and all 4 times it gets destroyed! this time I thought it was GONE!
posted by starduck at 11:49 AM on July 8, 2000

For cross browser stuff, Steve Champeon covered it pretty well in his DHTML book. Check out some of the demo code, like the color picker and poetry game, they're pretty slick, and actually work in NN 4.x.
posted by mathowie at 12:12 PM on July 8, 2000

or check out assembler.org.

(you didn't hear this from me.)
posted by vitaflo at 12:53 PM on July 8, 2000

As a designer, I can tell you very easily why DHTML isn't more prevalent than it is: there's no goddamned GUI for building it. I for sure am not going to sit around and hand code that crap and I don't think anybody working on any kind of deadline is either. Both Dreamweaver and GoLive try, but much as I like both of them for their various qualities, neither one of them has a Flash- or Director-like environment for creating DHTML-based output (no, that "timeline" thing in Dreamweaver is not good enough). Flash, on the other hand has... well, FLASH, a development environment designed to create that kind of content. Where's the "Export as..." command to save that as "DHTML"?!
posted by m.polo at 4:58 PM on July 8, 2000

Well, HTML seems pretty prevalent, and that seems to work just fine without a GUI to develop it with.

And a "timeline" is not a good metaphor for authoring anything interactive. Ever done anything in Director? The concept of the "score," and "frames," imported from its video-editing roots just doesn't work very well when shoehorned into interactive authoring.

Use Flash and Dreamweaver for their timelines when producing linear or minimally interactive animation. Use DHTML when you're actually going to take advantage of its interactivity, and when you want to make something that actually does something, most commonly as an interface for accessing pieces of data from a larger pool of data.

When making a DHTML interface, you're actually making a Web-based application - not a "Web page." You have to code it by hand, like any other computer application. It's called programming. People have been doing it for a long time, and it's not gonna go away.

There are ways around having to deal with all the details, but I don't think there will ever be a "complete" DHTML authoring tool, just as there isn't a complete make-your-own-desktop-app-without-writing-any-code tool.
posted by endquote at 5:57 PM on July 8, 2000

Josh makes some good points. Designers who rely on the WYSIWYG tools will never truly understand the functionality (guts) of the technology they are using. This is true for both HTML and DHTML. It's important for designers to understand that DHTML is really nothing more than a combination of HTML, Javascript, and CSS -- with the Javascript accessing the DOM of the browser (the platform).

Before Photoshop was around, designers invented their own techniques for high-quality imagery. These techniques basically were hacks of the tools they had at their disposal: scissors, film and its processing tricks, glue, sticks, pencils, and pens -- all mixed, molded and applied with a healthy dose of creativity and talent.

This is the downfall of most designers today. They jump on the computer far too soon, and end up relying on the digital image processing, the fancy Flash environment and canned effects, the pieces of code that get re-used again and again without any experimentation. In short, just a shitload of hackwork.

Put your Dreamweaver and GoLive in the Recyvling Bin/Trash, remove those bookmarks that you rely on far too often, start to really study the code and foundations of the technologies you are using, and let's see what you can do.
posted by camworld at 8:10 PM on July 8, 2000

Okay. Point of Order time here. Personally I could care less about arguing over DHTML. We've had this problem since regular HTML had the blinking tag. There's something about everything on the 'Net that chaps someone's ass.

However, the subtopic drift about gays which popped up is strikingly hilarious to me. [warning: sarcasm] I've certainly never seen a gay person filled with angst and woe over how they've been treated in modern society. They're always happy go-lucky guys and gals and naturally deserve to use their gay moniker [end sarcasm].

This would probably just get ignored and disregarded, but after seeing Alan's link I think this is deserving of its own thread. However, how are we to properly do this without upsetting the proper use of Metafilter? Do we start a new thread at the top of the Metafilter page? Do we create a new thread over at Metatalk? Considering that now I'm talking about MetaFilter, maybe that's where it's suppose to go now, but what if it was just a fun silly little topic drift thing where someone like me doesn't come along and talk about talking about MetaFilter's proper use?

It would be ideal if there was some way, if ever someone could see ahead of time that their remark might start a topic drift as it was in this case, where the guy could post what s/he wanted to about the topic in the Metafilter page, and then easily compose a link that would go somewhere else. So if others want to join in the topic drift, they can, without upsetting people who'd rather talk about DHTML over the use of dated definitions for common words.

Uhm... I'm gonna manually try to create a thread in Metatalk about this and when I find out what the URL is I'll post it back in here. I just wish there was an easier way of doing this cuz it ruins the flow of conversation.
posted by ZachsMind at 9:32 PM on July 8, 2000

Okay. Done. God how annoying it is trying to do the right thing while having a normal conversation in here.
posted by ZachsMind at 9:40 PM on July 8, 2000

Here's an off topic comment:

Why do we have to be so anal about the 'rules'? Discussions naturally wander a bit - why can't we allow them to do so here on MeFi?

--> return to topic:

I've yet to see anything produced with DHTML that comes close to what can be accomplished with Flash.

That said, DHTML effects are generally tasteful, and very bandwidth friendly.

Indeed, it's not that DHTML is *better* than Flash - only that lots and lots and lots of Flash designers are churning out megabytes of bloated crap. It makes DHTML look much better by comparison.
posted by aladfar at 10:29 PM on July 8, 2000

The comparison between DHTML and flash is outdated, we really need to move beyond that. As Josh pointed out, DHTML has much more potential to be integrated into navigation/interaction systems while flash is the best choice for intros and other primarily time based animations that are not really interaction-centric. There are a number of reasons for this, we can go through the list: why flash breaks normal web navigation paradigms (in a bad way), or how it leads to bloat, or how it's built from the ground up as a timeline based production environment, but one of my biggest problems is that its hard to integrate flash and HTML content effectively without using frames. err, I find that with DHTML you can acheive a much tighter integration.

Arguing over Flash vs. DHTML isn't the issue-- they are not mutually exclusive technologies and shouldn't be treated as such-- it's finding the appropriate times to use each technology.
posted by bryanboyer at 10:55 PM on July 8, 2000

Sorry, but anyone who thinks I should simply "move my copies of DW and GoLive to the Trash Bin" because it's somehow preventing me from understanding the underlying technology has made is in total ignorance of what it takes to make a technology prevalent. I'll forego any lengthy defense of my professional character, but I absolutely guarantee you that I have been hand-coding web-based content longer than either of the people how made this comment (probably longer than the two of you combined). The GUI tools I describe aren't for me, they are for the "masses" who will actually make your precious DHTML ubiquitous. My point was simply that as long as it's hard to create content in DHTML, it will linger on the margins of design work. Personally, I don't use it because for all that code, it still cannot be made to act predictably on two OS platforms across the four major browser versions that supposedly support it or some subset of it. With that instability and the lack of general market tools, it's dead in the water from a major adoption standpoint.
posted by m.polo at 8:30 AM on July 9, 2000

It seems to me that the only kind of "major adoption" which matters is the degree to which a feature is supported by web browsers. What difference does it make whether twelve other websites use your chosen cool technique or twelve thousand, so long as you can use it when you need it?

And, as endquote pointed out, the point at which HTML becomes interactive is the point at which it stops being "layout" and starts being "programming". Most people involved in that industry can attest to the fairly dismal history of such tools. Don't get your hopes that they'll be able to pull off with DHTML what's never worked for anything else up too high.

-Mars

posted by Mars Saxman at 12:11 PM on July 9, 2000

there really is no place for a dhtml gui because things are changing too quickly and the knowledge required to do both is too much for one profession (generally speaking). what you need is an adept programmer who can understand fundamental design issues (or will listen to the designer) and a designer who has a very basic understanding of programming and can communicate, together these people can use the design/programming tools they are proficient in to work together in building really dynamic designed applications that have both a high-design aesthetic and are not limited by a gui based dhtml app. as a design student our visual problems take months to work out and taking the time to hard-code an application would just be too overwhelming (at this point) so I'd say that producing the design statically in storyboard fashion for a programmer to then work on is the ideal model for real dhtml development. I think Hornall Anderson does this based on their employee's work.
posted by greyscale at 2:14 PM on August 20, 2000