constellex

August 12, 2007 at 12:00AM, we launched our new website. It’s much better than the plain Constellex logo.

Everything went smoothly during the launch except for some much needed and unwanted testing in Internet Explorer 7. We went to test the site in IE7 and found it wouldn’t render at all, but no errors were being thrown. After further investigation, the problem was with this line:

<script src="javascripts/main.js" type="text/javascript"/>

So what’s wrong with that? Turns out, not surprisingly, nothing. Here’s what IE7 wanted:

<script src="javascripts/main.js" type="text/javascript"></script>

That seems perfectly valid right? There is no difference, technically speaking, with those XHTML lines. Since XHTML is based on XML, and the script tag contains no body, you should be able to use the shortened version of the tag, and it should be recommended, as it reduces bytes to transfer over the wire. Safari and Firefox had no problem parsing the XHTML though.

In any case, we hope you enjoy the new site and welcome any feedback.

AJAX is all the rage over the Internet now, with various advantages and disadvantages. I won’t discuss those here, you’ve most likely read about them, and if not, there’s plenty of resources available. I want to talk about a problem that comes up often with people trying to develop applications using AJAX.

A lot of applications benefit from AJAX, but some are suffering as well. Some applications want to exist on the web, but break the rules. The HTTP 1.1 protocol spec states that “A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.” This is typically fine with AJAX, since you make a request and let the connection go. The same goes for a typical web request. As we’ll see later on with COMET, this is not the case.

HTTP requests and AJAX requests are both pull technologies. What I mean by that is the client makes the request and server simply responds. No connection is kept alive and the server is unable to contact the client at any point other than as a response to a request. But what if we want push technology through our browser? Well, HTTP wasn’t designed to do that. So most developers would stop there, which is probably a smart idea. It is impossible to create true push technology applications on the web without using third-party browser plugins. But you can fake it.

COMET is this elusive idea of being able to provide push technology through the browser. Most people would seem skeptical at first, but if you look further into the implementation, it’s almost a form of synchronous AJAX. That sounds strange… Synchronous Asynchronous JavaScript And XML (I understand AJAX, or Ajax, no longer has to stand for that acronym, but work with me here ). How can that be? Well let’s look at the strategy used to accomplish the COMET concept:

In essence, COMET acts a lot like typical threading, the client (browser) is the thread which blocks for a certain timeout period, until the server notifies it or the timeout occurs, and then repeat. This allows the end user to see instantaneous changes from the server, which is pretty awesome, because with AJAX, this can only be accomplished by using a polling technique, where the browser makes a call to the server checking for updates in very short intervals. That technique is a perfectly fine solution if you don’t mind scaling and performance issues as well as a large bandwidth bill. COMET will help reduce that.

Sound too good to be true? Well it is. Remember how I mentioned the HTTP 1.1 spec states we should only maintain a maximum of 2 connections at a time? Surprisingly almost all browsers follow this specification, which means while your COMET application is holding open those AJAX requests for that specified timeout period, the browser is now one less connection until you close the COMET application.

So there’s of course some advantages and disadvantages, just like any technology. COMET is useful for certain circumstances, most notably AJAX-y chat rooms. But tread lightly, you may be causing your end users headaches, which we all know is the last thing a company wants to do.

Web development is hard. No, it’s not server side applications, web services, HTML, or even *gasp* AJAX. It’s dealing with browser inconsistencies. For any novice web developer you know the drill, you create your web page and test it in your browser of choice. Then about half-way through completion you decide you should probably test it in those other browsers. Doh. Doesn’t work. But you followed all of the web standards and you even pass the W3C Validation test.

So what’s the problem? Well, there could be a number of issues, but one of the biggest contributors is the often forgotten about browser default styles. Yes, even when you build a site without any styles each browser applies its own style sheet at the most base level and unless you override those styles, they may be slightly different from browser to browser.

Solving that problem is actually rather simple and there are some clever solutions available. You need to essentially override all styles that are defined by the major modern browsers in your web page’s stylesheet. One solution that works particularly well available from the site linked above and originally from Left Justified:

* {
     padding:0;
     margin:0;
}
body {
     padding:5px;
}
h1, h2, h3, h4, h5, h6, p, pre, blockquote, form, label, ul, ol, dl,
fieldset, address {
     margin:20px 0;
}
li, dd, blockquote {
     margin-left: 40px;
}
fieldset {
     padding:10px;
}

Essentially you are overriding the margins and padding of all elements and then redefining them for individual elements. This starts you with a nice clean slate across all browsers and hopefully less headaches down the road.