When I started writing my own web code, I took it for granted that my code should be standards compliant. I also chose the standard that seemed most forward-looking and compatible with present and future standards, XHTML 1.0 Strict with CSS. I also made sure to use linked CSS and to do my best to make sure my code passed W3C validation. This has not been easy, as the code must be well-formed and some HTML 4.01 tags are deprecated under XHTML 1.0. In the course of searching for some bit of information, I stumbled across an interview with Swiss web developer Tommy Olsson from April 26, 2005. I don't know much about him, but he seems to figure prominently in the pantheon of highly regarded standards advocates such as those who reside at the Web Standards Project. It's an old interview; but web standards and their implementations in web browsers evolve slowly. Olsson makes some good points and it seems to me that his arguments still hold water.Read the 2005 Tommy Olsson Interview

In the interview, Olsson argues that there is no advantage to using XHTML 1.0 Strict instead of HTML 4.01 Strict when writing web pages. As he sees it, HTML Strict offers all the advantages of using XHTML Strict, HTML 4.01 Strict is a valid W3C standard with widespread support, and the Strict component is more important than the X. Moreover, XHTML is not even supposed to be served as text/html. It's supposed to be served as application/xhtml+xml.

This idea seems counter-intuitive, since current browsers have no trouble handling XHTML code as html/text. But the idea of using HTML 4.01 Strict makes sense to me. HTML has no real need to be "tag soup." It can be defined in the doctype as HTML 4.01 Strict. When written that way, HTML 4.01 strongly resembles XHTML 1.0 Strict and supplies access to the full capabilities of CSS. This seems preferable to me, since a number of tags that are deprecated under XHTML 1.0 Strict work just fine under HTML 4.01 Strict. You can also use those tags with an XHTML 1.0 Transitional doctype, but then you're still serving XHTML as text/html. To Olsson, this is a step back for web standards, but maybe it's just semantics. Strict seems powerful, since the code is written to the highest standard for the dialect in use. Transitional seems somehow weak. Yet, the result is almost the same. Certain tags that are deprecated or not supported under XHTML Strict are still available in both HTML 4.01 Strict and XHTML 1.0 Transitional.

As one who would write standards-compliant code, I wonder, which standard do I follow? Do I continue to use XHTML 1.0 because that is regarded in some circles as the purest, cleanest way of coding a webpage? Or do I accept Tommy Olsson's assertion that XHTML is not needed and should not be served as text/html? It is especially prickly since XHTML may turn out to be a dead-end dialect for writing web pages. The W3C intends HTML 5 to supercede HTML 4.01, and Olsson points out that XHTML 1.1 is not entirely backwards-compatible with HTML. So, the answer is pretty clear. Despite the fact that web browsers have no problem serving XHTML 1.0 Strict as HTML, there is no compelling reason to use it. Well, a client might insist; but that's a different issue. Basically, HTML 4.01 Strict is every bit as well-formed as XHTML 1.0 Strict. HTML 4.01 Strict also retains the full power of CSS. Thus, it seems to me that HTML 4.01 Strict is just fine for writing clean, well-formed web pages. That's what it was made for, and I may start using it right now.

I've been thinking about this for a while. It's a work in progress. The Modern Program for architecture is alive and well on the web. It comes to us through Robert Louis Sullivan, Mondrian, the Bauhaus, LeCorbusier, Adolf Loos, and Mies van der Rohe. The pioneers of the Modern Program meant to enforce efficiency and better living while eradicating decoration. Their tenets are alive and well on the web. Web designers are one with the Grid. It is enforced through Tables and the Box Model. You might say, the architecture of the web reinforces the clean efficiency of a gridded structure. Breaking that is challenging; I think it has become a comfortable thing, so few bother to try. We have leading designers who urge us to write clean, efficient code while keeping decorative design to a minimum. I suppose LeCorbusier and Adolf Loos would be pleased, but where does that leave us? With a web that is boring.

What to do about that? Designers must work within parameters. I accept that. We design for clients, and clients have practical needs. Thus, in the best Bauhaus fashion, we must bring art and design together to produce websites that works. I reject the idea that the web must be boring, that it must be made of safe colors in an arrangement of sterile boxes. I think I fell for it in the latest iteration of my own site, but I will soon change it. Now, I'm thinking of Robert Venturi. Where Mies claimed "Less is more," Venturi retorted, "Less is a bore." I agree. We need more ambiguity in design. I'm no nihilist, and I'm not at war with the web. I simply want to break the tyranny of the grid. The web is oh-so-efficient. It's clean to the point of sterility. Page after page is covered with different words and pictures; but ultimately, every page we visit features some variation of the same boring, block design. It's even worse when you look at the source code of many pages, as I do, and find that the underlying code is made of gibberish, a mish-mash of content swirled into tables and shot through with odd bits of JavaScript. It's DHTML, the evil genie required to make the last generation of browsers display dynamic content. It's deprecated, but that doesn't matter. People still write it because that's what they know. Or maybe they don't write it. People can use most any app capable of exporting HTML to generate a web page, and most of those apps produce garbage code that happens to run on most any browser. Where's the art in that?

I think the web would benefit from more more art, more style, more chaos. The risk of exciting design is that clients may reject it. The reward is that something better comes from the effort. To me, the reward is worth the risk. I think it will lead to better user experience and more interesting websites. The web has too much brown and grey. It also has too much red, yellow and blue. It lacks violet, orange and green. It lacks complexity and ambiguity of design. I think we're discouraged from showing our true selves, especially on professional pages. Those must "look professional." They must conform to tenets of the Modern Program. and that leads to more of the same dull, safe design that infests most every major site on the internet. I don't have some magical method for achieving my lofty goals, but I can help aspire to write pages and sites that are more visually interesting than what we have now.

Yet, any coherent discussion of web design must at least attempt to address why the web looks the way it does.

I was poking around on Andy Rutledge's Design View site and found a link to a short article< by Lorenzo Romero. In the article, Lorenzo argues that web design and art both have an inherent value. He uses Picasso as an example. At that point, his argument falls apart. I'm sure it sounds great to most people, but art emphatically does not have an inherent value. It's a commodity with a market value that has little to do with the artist's experience. It also has little to do with the quality of the work, the material cost of the work, or the time and effort required to make the work. It has everything to do with the artist's position with respect to the sociopolitical structures that govern the art world. The Lorenzo Romero article

In that structure, Picasso is a major deity. He was a galvanizing figure in the early Modern movement. He enjoyed a long and successful career; and he's still considered one of the most important artists of the 20th century. Picasso is a household name. Even people who know nothing about art know Picasso is a big deal. So choosing him as an example is misleading. Perhaps Picasso was making the right art at the right time, but more important than that, he cultivated the right social relationships to develop strong market value for his work.

Web design is much the same. Web designers who position themselves to work with major advertising firms and large corporations can charge higher fees than designers working with small-to-medium businesses or hobbyists. This is modified by the designer's technological proficiency. A good graphic designer who does not know how to code and relies on a program to generate code is going to have problems as the web becomes more standards-compliant.

That designer's design skills may rock the world, but prospects are limited due to a lack of technological proficiency. A designer who actually writes slick, standards-compliant XHTML and CSS with cross-browser compatibility has an advantage over the non-coder. The competent AJAX designer trumps the CSS/XHTML coder, and all may benefit from learning some Flash with Actionscript. It's demanding and people know it's demanding. Clients can't do it, but they want it on their sites. Thus, the designer who can do it can charge a higher fee, has a better chance of building social relationships with big-money clients, and earns a better living. It's not the inherent value of the work that matters; it's the market value.

As an artist and as one now offering the service of building portfolio sites for other artists, I am interested in issues and methods for building gallery viewers. It seems the main issues are visitor experience, load time, and ease of maintenance. As a designer, I want the visitor to have a good experience viewing the gallery. I want image files that are large enough for the visitor to see whatever is shown, but not so large that visitors must wait a long time for images to load. I also want to limit the quantity of files that must load before the visitor sees anything because people are impatient. Whizzy gallery code looks spectacular once it's loaded, but when galleries take too long to load, the visitor may decide to leave without looking at anything. I also consider ease of maintenance. Artists like to shuffle what they show in their galleries. So, the method used to display the gallery should allow the artist to easily make changes. The questions are, how best to address these issues and which gallery viewers best address the issues?

Methods for presenting a gallery in order from most common to most specialized include html scrolling galleries, html linked galleries, CSS hoverboxes, javascript slideshows, and flash presentations.

HTML scrolling galleries are ridiculously easy to implement and maintain while offering the viewer a decent viewing experience. The designer arranges the images on the page in one or more columns with descriptive text as desired. At its simplest, there are no thumbnails to make or additional links to consider. The site owner can easily swap images and text with simple edits to the html code. The visitor loads the page and scrolls through the gallery, viewing the images as desired. It's simple and effective. Since the images come through in order, the visitor should see something right away. A page with many large images will suffer increased load time, but the images should load quickly enough to maintain the visitor's interest. The HTML scrolling gallery is an easy, intelligent, and flexible way to set up a gallery, especially when the designer optimizes images for the web.

HTML linked galleries offer the simplest way to produce a slide show. They are easy to implement and supply a pleasant viewing experience, but linked galleries are a pain to maintain. The designer sets up an index of thumbnails. Clicking the thumbnail opens a larger version of the image on a separate, linked page. Each large image resides on its own page. It's easy to set up links that allow the viewer to flip through the collection of slides, moving forward or backward at will, but adding or removing an image means replacing the thumbnails and possibly adding or removing whole html pages. Editing the structure of the gallery page is also time-consuming as this may have to be repeated on every page. The html linked gallery works best with careful planning.

CSS hoverboxes are slick toys and surprisingly easy to implement. I developed some very nice custom CSS hoverboxes. They're self-contained slide viewers that display images when the visitor rolls the mouse cursor over the thumbnail. Once they load, they provide a good experience for the visitor. They behave a lot like javascript slideshows, but they require no javascript. Unfortunately, they're sensitive to file size and quantity. The viewer will not work properly until all the images load. If you have many large files to load into the viewer, people may think the viewer is broken and leave before they see anything. So, these work better with a reasonable number of small files. A CSS hoverbox is almost as easy to maintain as an html scroller because the thumbnails, images, and captions all reside in a list on the same page.CSS Hoverbox Viewer

Javascript slideshows are slick toys that require a bit of programming skill to implement. Sophisticated javascript slideshows load quickly and do things that CSS and XHTML cannot do. With javascript, the designer can build gallery viewers that swap slides automatically every few seconds or at the push of a button. A skilled designer can use javascript to preload images complete with a progress bar. A well-planned, well-programmed JavaScript slideshow provides fast loading, a good experience for the viewer and ease of maintenance. Mediocre slideshow galleries may fall short in one or more areas.

Flash presentations replace the XHTML, CSS, and JavaScript with a self-contained Flash .swf file. Consequently, the load time is frequently noticeable. Depending how the file is written, the artist may or may not be able to maintain the gallery. Visitor experience is usually fine once the file loads, but an .swf file is a compiled product. To edit the thing, one must have a working copy of Flash, the source files used to make the presentation, and sufficient knowledge of Actionscript to modify the gallery code. Furthermore, an .swf file requires a Flash plug-in and a computer powerful enough to run the presentation. In the absence of a Flash capability, designers are supposed to provide an HTML alternative for users who do not have the Flash plug-in, but this means twice as much development and maintenance. From what I've seen, people who incorporate Flash into their web designs don't bother with the HTML alternative, and they may have the right idea.

At the present time, I mostly offer HTML scrolling galleries and CSS Hoverboxes. I understand how they work, and I can implement them efficiently. They also work well for artists on a budget and with the desire to maintain a gallery themselves. Scrolling galleries may be the best choice as they are structurally transparent. Most anyone can understand how they work. CSS hoverboxes add technical sophistication without much extra complexity. Linked galleries are always possible, but require careful planning and add serious bulk to a site's file structure. I do not especially recommend them, though I frequently link scrolling galleries. Other options will become available as my skills increase.