March 2006 Archives

As Dave Shea from mezzoblue points out, IE7 Beta 2 is available and while there still may be some minor tweaks and bug fixes before the final release, the new rendering engine is finalized. The good news is that Microsoft has put a lot of work into properly implementing CSS and adhering to web standards. The bad news is that the hacks and tricks you used to make your site work in IE6 may now break it in IE7. Code Scene itself has a few quirks that I'll need to iron out in order to make the site look pretty in IE7.

One of the most noticeable differences is in the way CSS floats are rendered. The "easy clearing method" I've grown so fond of is no longer a viable option for clearing floated elements. Anne van Kesteren's method of "super simple clearing floats" seems to do the trick though.

Do yourself a favor and download the beta now and test all your sites. Make whatever adjustments you need to make now, before the final version is released and you get the angry phone calls from the client.

Download Internet Explorer 7: Beta 2 Preview

I setup my first SSL secure site yesterday and found something interesting. There doesn't appear to be a built in IIS function for redirecting from http:// to https://
Why is that? That seems like something that would come in handy.

Anyways, after a little Google searching and experimenting, I came up with a method that I think works relatively well. If anyone has a better method of doing this, by all means let me know.

Start by creating a new ASP file and insert the following.

<%
Response.Buffer = True
If (Request.ServerVariables("HTTPS") = "off") Then
            sQ = Request.ServerVariables("QUERY_STRING")
            sURL = "https" & Right(sQ, (Len(sQ)-8))
            Response.redirect(sURL)
End if
%>

Save this file as sslredirect.asp and place it in a folder named SSL inside your website.

1. Open the IIS console
2. Select your website
3. Right click on this new SSL folder and click Properties.
4. Under the Application settings section, click Create.
5. Click the Directory Security tab, and then click Edit under Authentication and access control.
6. Make sure Enable anonymous access is checked, and then click OK.
7. Under Secure communications, click Edit.
8. Make sure the Require secure channel (SSL) check box is NOT checked, and then click OK two times to close the window.

You've just ensured that SSL is removed from this folder so it'll run the script using anonymous access and plain old http.
Now you need to enable SSL for the rest of the site and setup the redirect.

1. Right click on the root website folder and click Properties.
2. Click the Directory Security tab.
3. Under Secure Communications, click Edit.
4. Click to select the Require secure channel (SSL) check box, and then click OK.
5. Click the Custom Errors tab, and then double-click 403.4
6. In the Message Type list, click URL.
7. In the URL box, type /SSL/sslredirect.asp, and then click OK two times to close the window.

Now... here's what happens. With SSL enabled, anytime you attempt to access a page via http, the server generates a 403.4 error. IIS is now configured to run your sslredirect.asp page every time this error occurs. The error page will include a querystring which contains the error number and the page causing the error, I.e. "403;http://www.whatever.com". Our ASP file uses a simple script to just trim off the beginning part (430;http), add the necessary "https", and redirect to whatever page the user requested using SSL. Voila!

Apologies in advance to my friends in the industry who work for, with, or otherwise love content management systems (CMS). Feel free to refute this in the comments section.

Anyone that knows me knows that I'm not a fan of content management systems. Clients always seem to want them and I always want to ask... why? The majority of the time it's people who'd never dream of doing something like changing the oil in their car, but for some reason they have no problem editing the primary communications vehicle for a multi-million dollar corporation. Not to be cocky, but you hired me for a reason. If you don't know anything about the web, what makes you think you can manage your website?

Whenever I implement a CMS for a client, one of two things invariably happens:

1. The client ends up destroying the site. - Broken links abound. Formatting and styles change radically from page to page. A 6-megabyte image on the homepage. I've seen it all.
2. The client ends up calling me. - The CMS proves to be too much of a challenge for them (or doesn't offer the features they want) and they end up asking for help. Obviously I have no problem providing help to my clients but when a CMS is involved it ends up taking 5 times as long because I have to make all changes through a 12-step CMS wizard instead of just quickly editing the code.

From custom built database systems to enterprise solutions like Vignette, content management systems are usually expensive, difficult to setup, or both. For that reason I often advocate that clients simply setup a monthly retainer with their development team to perform maintenance and routine updates. More often than not this is much easier and more cost effective for the client.

This isn't about whether or not you should use popup windows. Everyone hates popups these days but sometimes they're necessary so you should code them properly. I'm always surprised because 90% of sites still do them wrong so here's a quick tip.

Here's how the majority of sites I see have their popup windows coded...

The Not So Good Way

The problem with this approach is that the link is entirely embedded in the javascript onClick event so the link will only work via javascript. Why do we care? Two reasons:

1. Accessibility - Screen readers generally do not have javascript enabled so these links won't work for those users with visual impairments. There are also a small percentage of users who have simply disabled javascript, possibly out of security concerns.
2. It annoys people like me - As a Firefox user I have a tendency to scan the page and middle-click on any link that looks interesting. This opens each link in a new tab (IE users often right-click and select 'open in a new window'). This lets me read multiple pages without having to click the back button a bunch of times. All hail tabbed-browsing. Popups coded this way prevent me from doing this.

So how should you be coding popup links? Here's the way I like to do it...

The Better Way

This embeds the link in the href attribute where it belongs and uses the javascript 'this' method to reference it. This way the popup works for regular users via the javascript but the link will still work the old fashioned way for screen readers and firefox tabbing. Obviously I'm using inline javascript here but you could easily break this out in a function if you plan on having multiple popup windows on the same page.

One of the most difficult parts of our job as web developers is keeping up on the latest technologies and trends in the field. Microsoft, to their credit, plays an active role in helping developers learn to use their new products and services. This week I've been watching several different webcasts on ASP.NET 2.0, Visual Studio 2005, and Atlas. They're very informative and best of all free.

For developers who can find the time to watch 3 of these webcasts, Microsoft is offering a "Visual Studio 2005 Discovery Pack" which includes:

• Microsoft® Visual Studio® 2005 Professional Edition 90-day DVD trial
• Microsoft Visual Basic® 2005 Jumpstart book from O'Reilly
• Discount voucher for Visual Studio 2005 Professional Edition with MSDN® Professional Subscription
• Microsoft Developer Security Resource Kit
• Discount voucher for Microsoft Certified Professional Exam
• Free 30-day hosting account

It's definitley worth the time and free stuff is always a bonus so check out the Visual Studio 2005 - The Difference is Obvious webcast series.

It seems like about everyone I know has asked me questions this week related to best practices for building HTML emails and newsletters. It can be a tricky business so I've decided to assemble a few basic rules to follow that should help. In no particular order:

Avoid CSS
It hurts me to say that since I preach CSS as gospel in any other situation but support for it just isn't all that stellar in email clients right now. Write your code in HTML 4.0 and try to minimize or eliminate the use of CSS.
A good idea is to use inline styles such as:

Newer clients will read the style property to set the font size while older ones will fall back on the HTML size attribute of the font tag. Everybody wins!

Hand-coding is also a good idea since WYSIWYG editors sometimes don't do the best job of writing clean code.

JavaScript
None. Ever. Forget it. I don't even know why people still ask about this.

Base Tag
While this works for most email clients, certain ones have trouble processing it so don't rely on it. Store all your images on a server and make absolute links to them.
I.e. <img src="http://www.mysite.com/images/whatever.jpg">

Background Images
For newsletters that require a background image or color, the 'background' and 'bgcolor' attributes of the BODY tag must NOT be used since most web-base email clients will not properly display them. Same goes for adding CSS to the body tag. What did I tell you about CSS anyways? The solution is to encapsulate everything in a container table or div tag and apply your background colors and images there.

Validated HTML
Malformed HTML code, non-standard characters, such as missing end tags or non-quoted attributes can cause display problems, especially with web-based email clients like Hotmail. To ensure that your code is valid, use the W3C Markup Validation Service at http://validator.w3.org/ to check your code for errors before sending it.

Testing
Whenever possible, test your HTML email in as many different clients as possible before sending it out. It's easy and free to sign up for all of the major web-mail clients so you have no excuse.

Use Image ALT tags
This should go without saying. If images are slow to download or turned off, the ALT tag will give a description of what the image was meant to convey.

No rich media
Many email clients still have problems with flash, video, or form components. It's much better to host those elements on your website and use the email to direct users to them.