Take a Stand and Understand the Standard - HTML with Style | 4

Take a Stand and Understand the Standard

How not to build a Web application (or, why forms are bad form)

You see, I'm all for interactivity on the Web. I think it's a great idea. The problem is that people are trying to re-implement already existing technologies by hacking HTML just because it's so immensely popular. And that's the wrong way to do things.

First of all, HTML will never, ever be a good user interface design language. Ever. It just isn't built for that kind of thing. If you want to design a user interface, use a proper toolkit for heaven's sake. Forms are cute if you want to add a quick way to perform a query, but ultimately, just about everything that adds interactivity to HTML is in the wrong place.

I, amongst many others, keep complaining about authors who use tables to position form controls on Web pages in order to give them the look and feel of a dialog box. The real cause of the problem, however, is not the lack of a proper (e.g. CSS-based) way of creating dialog boxes in HTML. It's that dialog boxes have no place in HTML.

After people were frustrated with the inability of HTML forms to create a proper, fully-functional user interface, JavaScript came along and made things even hairier. There are tons of sites (this one included, I'm afraid) that use JavaScript scripts to check the data the user has entered into the form before it is submitted. This is good practice, but it is entirely the wrong way to do things. Someone can still submit the form without having the script validate the data just by turning off JavaScript. Not to mention that the entire contents of the form, including the script, are visible to anyone who uses them; anyone with a clue can hack up an alternative form into an HTML document on his own hard disk and submit data without any checks.

As JavaScript got more advanced, a new technology evolved, which has been given the unfortunate name of "Dynamic HTML." Dynamic HTML is nothing more than JavaScript (or, rarely, some other alternative) being used to alter a document after it has been displayed on the browser, usually involving some user interaction.

This is a good thing. There are lots of neat effects you can create using DHTML, but the problem is that a lot of people are beginning to use DHTML techniques to build real applications. What do I mean by real applications?

The line between Web page as document and Web page as interactive application is very fuzzy. The first problem is when you have Web pages that serve no purpose other than providing an interactive service. Examples of such Web pages are online ordering systems, Web-based front-ends to databases and other similar efforts.

Sometimes, you only need that kind of functionality in part of a Web page. An example would be a form that allows the user to search through a site that exists in every document in that site. Another example is the form that allows you to subscribe to our newsletter that appears on the HTML with Style front page. Here, we have the problem that we want an interactive application inside an HTML document. Currently, the subscription form uses HTML forms for the user interface toolkit, CSS for the user interface layout, and a CGI script to process the form submission. The amount of code you have to write, and the amount of trouble you have to go to in order to get what is essentially a dialog box that asks you your e-mail address and whether you want the HTML or plain text newsletter is staggering.

But that's not really the distinction. You see, the question is, what is HTML (and all of its associated technologies) used for? When it is used to present a hypertext document, that is, a body of text, containing hyperlinks, that someone is expected to read, and perchance decide to follow some of said links, then it is fulfilling its purpose. Technologies such as JavaScript can be used to make the document more presentable, easier to navigate, or to add simple visual effects such as rollovers, and this is all good.

But when you start using HTML, CSS, and scripting to create an interactive application, you've got a problem. You're using the wrong tool for the job. You'll probably create an invalid document that will definitely not make sense if seen as a document and not an application. You'll probably have huge development costs because you have to work with buggy implementations, as well as the incredibly limited features of the HTML-CSS-JS trio compared to a fully-featured programming language.

URL: https://www.webreference.com/html/watch/standards/3.html

Produced by Stephanos Piperoglou
Created: August 25, 1999
Revised: August 26, 2089