After several searches, I discovered IE doesn’t allow the name attribute to be changed after the element is created—and it can’t be set in a DOM compatible way during creation.

Bennett McElwee suggested a solution in his blog that is nicely cross-browser; anything other than IE throws an exception and gets created properly. (I suspect modifying the parent node’s innerHTML would work as well.)

function createElement(type, name) {
   var element = null;

   try {
      // First try the IE way; if this fails then use the standard way
      element = document.createElement('<'+type+' name="'+name+'">');
   } catch (e) {
      // Probably failed because we're not running on IE
   }
   if (!element) {
      element = document.createElement(type);
      element.name = name;
   }
   return element;
}

And your type attribute too

Another part of the project requires we transform checkboxes to radio buttons and hidden fields. This could be accomplished through a page reload, but it’s overkill for such a small change. Once again, in truly DOM-compliant browsers, this requires only a couple of lines of code:

element.setAttribute("type", "radio");

The MSDN reference for the type attribute says:

As of Microsoft Internet Explorer 5, the type property is read/write-once, but only when an input element is created with the createElement method and before it is added to the document.

QuirksMode has a bug report for this, complete with test page and workaround submitted by Stijn Peeters. Stijn admits the workaround needs a little bit of cleanup.

Essentially, his solution is to always remove the element, and recreate a modified one. (See the bug above!) Here’s my solution:

try {
   element.setAttribute("type", "radio");
} catch (e) {
   var newElement = null;
   var tempStr = element.getAttribute("name");
   try {
      newElement = document.createElement("<input type=\"" +typeStr+ "\" name=\"" +tempStr+ "\">");
   } catch (e) {}
   if (!newElement) {
      newElement = document.createElement("input");
      newElement.setAttribute("type", "radio");
      newElement.setAttribute("name", tempStr);
   }
   if (tempStr = element.getAttribute("value")) {
      newElement.setAttribute("value", tempStr);
   }
   element.parentNode.replaceChild(newElement, element);
}

The application has a “skin” feature allowing non-technical users to customize colors, font, and a handful of other things easily accomplished with CSS. Rather than edit more than twenty other pages to add an extra <link /> tag, we chose to add the following line to the top of our primary CSS file:

@import("custom.css") screen;

Notice how we defined the media type for the imported CSS file as part of the import rule, as suggested by the CSS2 specification.

A little more background: using a little bit of Apache magic courtesy of mod_rewrite in the httpd.conf, requests for the file custom.css are redirected to custom.php, in the same folder.

<Directory "/www/css">
   RewriteEngine on
   RewriteRule ^custom\.css$ custom.php [nc]
</Directory>

It didn’t work. Firefox’s Javascript Console was pointed directly to the problem: “The stylesheet http://localhost/css/custom.css was not loaded because its MIME type, ‘text/html’, is not ‘text/css’.” (Also, custom.css did not show up in Firefox’s built-in DOM Inspector.) The error was easily fixed, by adding the following line to custom.php:

header("Content-type: text/css");

The styles then loaded properly in Firefox (and Safari), but not in Internet Explorer. Browsing directly to custom.css worked fine in Firefox, but IE behaved oddly. It first acted as if it was about to download the file (oddly, the default action for the working CSS file), but then popped up a dialog saying the URL could not be found.

I then examined the HTTP headers, and compared them with a working file. (It’s off-topic for this post, but I stumbled across this while Googling for solutions. If you’re a geek and want to see some fun headers in the wild, visit Fun With HTTP Headers.)

Headers unique to main.css (working):

Last-Modified: Mon, 09 Jan 2006 22:28:54 GMT
ETag: "ce134-ed8-43c2e3a6"
Accept-Ranges: bytes
Content-Length: 3800
X-Pad: avoid browser bug

Headers unique to custom.css (not working):

X-Powered-By: PHP/5.0.4
Set-Cookie: PHPSESSID=uah38ktr3mgq3td5j6qmcdgjf3; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache

The cookie is generated automatically by PHP because of the need to use session information as part of the customization process. But, this is a CSS file, so I want it to be cached by default. Adding the following line before session_start() is called hid the no-cache headers, and things began to work in IE almost as they should.

session_cache_limiter("none");

I said, “Almost.” After tweaking the headers, I could now visit the file directly in IE without the “URL not found” error. (Meaning, it attempted to download it, rather than display it, but it was a step in the right direction.) However, it would still not apply the styles from the imported CSS file. It was difficult to debug as there were no error messages, and IE’s DOM tree is not consistent with W3C standards. The final piece—and I could find no documentation anywhere for this—was to strip the media type from the import statement (at the top of this post), making it:

@import("custom.css");

It sounds easy now that I write it, but this series of bugs cost several hours of work. I hope this post will save someone else similar trouble. (If you see something I missed, or know of a faster course we could have taken to solve this problem, feel free to add your comments!)

Being able to easily replicate presentational effects across multiple browsers, from IE or Firefox, to a PDA or cell phone is a web developer’s Utopia. The ability to use semantic markup to not only accommodate users with disabilities and effect clean design, but also to reduce the weight of code and improve response times is a wonderful thing.

Molly Holzschlag has posted a scathing open letter to Disney Store UK, taking them to task for their new design, which is, from an HTML standpoint, a step backward, making some rookie mistakes like bad alt text for images. (I don’t know how it compares visually—I didn’t see the original site.) Like standards advocates frequently do, she cites total cost of ownership, server performance, and search engine rankings.

She’s right on some points: table-based layout and in-page scripts will result in slower downloads and slower renders. Even sub-second delays, while not consciously identifiable, contribute to a reduced level of trust. But Molly, and most of the comments, miss the point from the company’s point of view: does the new site make more money? It’s not until well over 100 comments that Adam brings this up. (Gee, it’d be nice to have that many people react to my blog.) Revenue, not web standards, is the primary driver for corporations.

As for the accessibility issues she brings up, she’s spot on. I think if she had made accessibility the main thrust of her letter rather than just another item in a over-long list of talking points it would have had more impact. But the fault isn’t really with Disney, but with the designer. As I’ve mentioned before, few managers have the skill set to evaluate the work of web programmers on anything other than a visual level. Who is training the managers?

The blogosphere has been accused of being an echo chamber, or as David Weinberger puts it, “Those Internet spaces where like-minded people listen only to those people who already agree with them.” The Web Standards community is no exception. The sole voice who suggested that an open letter criticizing the new Disney site may not have been the most effective course of action was attacked by multiple readers. There is merit in his position, and I was frustrated so many dismissed him out of hand.

Web standards are good. Designers who employ web standards are good. Evangelism does not need to include condescension or criticism. Until corporations with a major internet presence discover for themselves the benefits of web standards on the bottom line, they will not willingly change. Trying to push it on them won’t speed the process. Molly gets it right in her follow-up post (before burying the thought with more indignation): “Professionalism means taking responsibility for educating ourselves and each other.” And education happens best when the learner is excited about learning.

I’ve struggled with the site layout. I wanted something different from what WordPress offered. In no particular order, I wanted:

• Table-less design
• Three-column layout, with fixed sides and a variable width
• Browser-independent (X)HTML, free of hacks
• A source order that placed my content first, and my side columns second, yet still maintaining left and right columns

I didn’t get everything I wanted, but I came pretty close. This layout is based loosely on The Jello Mold Piefecta. I’m still moving things around a bit, so you may find an occasional validation error or glitch.

I also still need to add some usability pieces, including "jump to navigation" links, and a stylesheet for smaller screens. I also intent to experiment with ways to allow users to apply a large print style sheet easily. I’ve seen several sites do it, but it’s generally through a prefs link that isn’t easily accessible.

Google’s search results page has been retooled using semantic markup and CSS by at least two dozen people as it is, but they just don’t care. It’s annoying, it’s sad, and it’s also pointless.

There have been some retooling jobs that saved an awful lot of markup and would thus, as a result, save Google ridiculous amounts of bandwidth, but did they show any interest? Nope.

From Searching for Standards (Comments)
Referenced Thu, 08 Sep 2005 11:45 (MDT)

This flies in the face of what I’ve heard about Google: namely that they make every effort to optimize their output—not for file size, but for speed. Changes which increase their output time are rolled back. (I imagine gzipping their output is an exception to that, but given their traffic volume, the savings are likely significant.) Take a look at their source code, there are several things worth noting. First, it’s quite compact; there is little extraneous white space, and shortened versions of tags are frequently used. Second, style information is embedded in each page rather than linked separately. Why? I suspect they found it’s faster to simply output their (brief) style sheet than to embed the link and have to process and additional web request, causing load on their servers (TCP is not exactly a light protocol), and delaying the browser’s ability to display content.

I made a similar standards argument during my recent work with a major internet retailer. Not only did they use table-based layout (frequently wrapping single-cell tables around block level elements), they unabashedly used spacer gifs. I jus about screamed when I saw it, but I wasn’t there as a web programmer, so their wasn’t much I could do about it. I did, however, write a brief paper outlining the performance and bandwidth savings. While processor performance likely wouldn’t be terribly affected (the limiting factor being the network connection), I estimated bandwidth savings to be at least 15%, just for tweaking the worst 20% of the page! The idea was tossed around, and gained some interest by a handful of middle managers, but was never implemented. Strategic projects—those focused on making money, not saving it (and bandwidth is sort of a sunk cost anyway)—were given priority, and developer resources were limited. Additionally, all changes to the web code were costly, as the entire site was handled by a monolithic CGI (which should be apparent to any technical user who bothered to study the URLs).

Web standards is a great ideal, and can be a great cost savings, but can also get in the way of performance. It requires web developers trained in implementing them properly—which nearly always costs more than college students who learned on their own. Few companies are willing to pay a premium for an end result that looks the same to 80%+ of their customers.

While I firmly believe standards should have broader adherence, I think standards advocates sometimes forget about the bottom line.

• Dive Into Accessibility by Mark Pilgrim
• Accessible HTML/XHTML Forms found at The Web Standards Project

In it he walks through the benefits of redesigning the presentation layer of a corporate web site (in this case, Microsoft.com), and not only successfully argues the time savings for developers who code to W3C standards, but also gives a quantitative analysis of bandwidth savings from the redesign: an estimated 924 GB in bandwidth savings per day. In Microsoft’s case, the design-time savings would be even more significant, as the site serves different versions of pages depending on whether you are using IE with Windows or not.

Pay attention to what he is saying. I have had a similar experience (though not nearly on that scale) with a local non-profit organization. After using their web site, I volunteered to make some improvements, as I found the HTML to be convoluted, and usability and consistency were nearly non-existent. By removing most of the font tags, applying a more correct document structure with header tags, and creating a simple style sheet, I was able to reduce the file size of most of the site pages by as much as 80%. (I would estimate an average 60% savings in file size across the site.)

These are extreme examples, but bloated code is prevalent across the internet. If we can write our code properly up front, we can optimize download and render times, and make our code more maintainable.