Steven Engelhardt

Proposed Guideline 1: Any HTML or CSS construct which breaks arbitrary nesting is dangerous.
Proposed Guideline 2: Any HTML or CSS construct which can be broken by arbitrary nesting is dangerous and should be avoided in an HTML template. (This guideline is basically impossible to completely satisfy, but some constructs are easier to break than others.)

Observation 1: The CSS clear attribute breaks arbitrary nesting.
Observation 2: The CSS float attribute can be broken by arbitrary nesting.

Conclusion 1: The CSS clear attribute is dangerous.
Conclusion 2: The CSS float attribute is dangerous and should be avoided in an HTML template.

Discussion: When developing a complicated web site, one often resorts to the use of an HTML template. Templates usually work by defining of one or more “insertion points” for HTML content for a particular page. An ideal template is designed defensively: no matter what content is put into an insertion point the template layout remains intact. (Alternatively, and this is what happens in practice, one must control what content is allowed to be put into an insertion point—but by avoiding certain constructs in your template you can be more liberal with your allowed content.)

Consider a template for a blog which uses a two-column layout where the sidebar column is positioned to the right using the CSS float:right attribute. Now consider a blog item which wants to contain a picture aligned to the right side of the content column using the float:right attribute. If the picture is the vertically largest item in the blog entry, the ubiqutous comment link must be marked with the clear:right attribute in order to appear below the picture. However, this clear attribute will also put the comment link below the bottom of the sidebar column.

Therefore, for this (and other, aesthetic reasons) I eschew the use of CSS float-based multi-column layouts in HTML templates. In fact, although it is possible to use the CSS position attribute to create multiple column layouts, I find a table (*gasp!*) to be the easiest, most sensible solution right now. (In the future, perhaps I will look to the W3C’s Multi-column layout in CSS proposal.) The use of a table-based HTML template allows one to use float and clear in insertion points with abandon.

This wouldn’t be a problem if the clear attribute applied only to the most recent float, as opposed to all floats. (This change would effectively require all floats to contain a subsequent clear, visually required or not, but this is a good habit to get into anyway).

Modal dialogs in Internet Explorer are a somewhat curious creature. Here are some of the problems that I have encountered and their workarounds:

function getExternalOM()
{
    // For IE windows, window.external will exist but will not have any
    // methods.  <starwars>This isn't the window.external we are looking
    // for.</starwars>
    if ("foo" in window.external) {
        return window.external;
    }

    if (window.dialogArguments != null &&
        window.dialogArguments.externalOM != null) {
        return window.dialogArguments.externalOM;
    }

    return null;
}

The problem:

1. Debian has configured Apache such that it will add a Content-Type: … charset=iso-8859-1 to the HTTP request headers of all files with unknown types. This overrides my <meta http-equiv…charset=utf-8> line in my website which sets the character set to UTF-8, and thus breaks the handling of extended ASCII characters (making résumé appear incorrectly). I would consider disabling it, but it does exist for a reason. It is also the default for Apache 2.0.
2. My XSLTs are configured NOT to include the <?xml version=”1.0″ charset=”…”?> stanza at the beginning of my webpages (more below). When I make my XSLTs produce ISO-8859-1 output without this stanza, my output validation stage fails because the document is not UTF-8. It suggests to use the <?xml…?> stanza to specify the character set.
3. When I output the <?xml…?> stanza, Opera and IE do not display the page correctly. IE also has a bug where it won’t turn on strict conformance mode (to eliminate CSS bugs) if the <?xml…?> stanza exists.

The solutions seem to be:

1. Eliminate all extended ASCII from output, and replace it with character references (such as &eacute;). This is obviously evil.
2. Disable Apache’s Content-Type HTTP header crap. This is evil: see above.
3. Forget about the output validation stage. Evil.
4. Generate ISO-8859-1 with the XML stanza and add an extra stage after output validation that strips off the <?xml…?> stanza. Evil.
5. Try to find a way to set the content-type of files so Apache sends the proper content-type in the HTTP headers. If done with .htaccess files, it will be a big PITA.
6. Eliminate non-7bit ASCII altogether. Ugh.

What a mess.

I keep seeing XDocs (a.k.a. InfoPath) popping up in peoples’ blogs, such as here and here. Maybe, just maybe, the tiniest bit of code that I wrote for XDocs way-back-when will make it through to the shipped version. *sigh* It sure would have been nice to get a ship award.

In other news, I would like to start a jihad against exposing the extension of (most) files on websites. That’s what MIME types and directories with default files are for! For example, DON’T link to http://www.deez.info/sengelha/index.html, link to http://www.deez.info/sengelha/. That way if I suddenly decide to rewrite my website using PHP everyone’s links still work. It will even work if I change everything to client-side XML/XSLT transformations, which will result in a change in the MIME type of the document.

If you don’t want to make one directory per file, then create an extensionless filename and use the following snippet in your .htaccess file to force the MIME type of the file to a particular value (for Apache):

<Files rss091>
ForceType application/rss+xml
</Files>

<Files rss1>
ForceType application/rss+xml
</Files>

The main downside to the above is that some URLs end with slashes and some do not. I’ll think about this one and get back to you.