July 26th, 2010
In a post I wrote back in November 2008, I taught you how jQuery can be used to make links open in a new window in a standards compliant way, using the “rel” attribute in your link tag. In my efforts to build and run a photography news website recently, it quickly became clear that I didn’t want to mark all my external links with “rel=external” , because every single post has an external link. Being thusly motivated, I started looking for wordpress plugins that would scan the link, determine if it was external, and do something to it in a standards compliant way that would make it open in a new window. Coming up with diddly-squat on the search, I realized I was being dense. Again. I could let jQuery do that for me, and not have to install a plugin to do it. Here’s the relevant code:
<script type="text/javascript">
$(function() {
$("a:not([href^='http://www.phototimes.net'])").attr("target", "_blank").addClass("external-link");
});
</script>
This little snippet does several things all at once. The first thing it does is find all links whose href attribute does not begin with http://www.phototimes.net. This selects links that are off-domain, which we want to open in a new window. The next part sets the target attribute of the link to _blank, so that it will open in a new window, and the third part adds the external-link class to the tag. The external-link class allows us to style the link differently that other links on the site, like adding one of those nifty little arrows that visually indicate that the link is offsite, and was popularized by Wikipedia. jQuery, I think I love you.
Posted in Web Design, Web Standards, jQuery | No Comments »
October 14th, 2009
A lot of web developers tend to overlook or ignore the file sizes of the files that compose their websites. I’ve seen many websites that are well over a megabyte for just the home page with all its components. I’ve even seen a few that were over 3 megabytes. While most americans have broadband of some fashion, there are still a significant portion (~20%) that do not have broadband, and even those that do will get impatient waiting for a page to load, and may click off before you have a chance to wow them with your content.
I tend to use several techniques to keep my overall document size reasonable:
- Compressed Images – JPEG (for complex images) between 40 and 65 percent quality, depending on where compression artifacts become too noticeable; GIF (for simple images) color palette restrictions between 8 and 128 colors, depending on where the artifacts become too noticeable. Of course I also use PNG images where a really good alpha channel is needed, but I use them sparingly, as full alpha transparencies dont compress well.
- Minified Javascript and CSS files. I like the YUI Compressor for this.
- Server-side compression. Even minified files can be squeezed even smaller with the use of server-side compression.
Server-side compression is super-simple to implement, as long as you have access to an .htaccess file or a friendly server administrator. Here’s a syntax that works for me on a couple of servers I run (This is Apache specific, for other servers find a mod_deflate equivalent):
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
AddOutputFilterByType DEFLATE text/x-js application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
The two AddOutputFilterByType lines can be combined into one or split up however you choose if you’re a stickler for keeping your text in configuration files readable. This can be inserted in the virtualhost definition or in your .htaccess file. Using this alone, I consistently shave off between 60 and 100 kilobytes off my download size. Enjoy!
Posted in Cogitatio, Web Design, Web Standards | No Comments »
February 23rd, 2009
Back in my first Designing For Email post, I discussed workable dimensions and some common-sense techniques when you’re approaching designing for email. Most of that still holds true, but I’ve discovered an unpleasant lack of support in a few email clients for an important bit of CSS: floating, clearing, and margins. The lack of this one bit makes good design wholly in CSS nearly impossible. I’m officially peeved. What’s really weird is MS Outlook. Outlook 2003 supports floating just fine. Outlook 2007 does not. So what does this leave me with? Table-based design.
Yeah, I know. Seriously. After all this time when CSS has (finally!) become a standard method of layout. When people are finally getting the whole point of separation of concerns when it comes to content versus layout, and browsers are getting good support, and for the most part I can get my designs to be pretty consistent across browsers without much effort as long as I closely follow the rules… I’m having to retrofit my CSS-based layout into a table-based design.
As I was coming to grips with this I did a sanity check by looking through the last few months of my inbox and looking at the adverts (non-spam) I’d recieved. A quick look at the source confirmed that they were ALL table-based. Dang. And now the fellow across the hall is making fun of me. He knows how dirty I feel for having to violate standards to make something layout correctly. Oh well. For what it’s worth, I did stumble across the Email Standards Project, which is what confirmed that Outlook 2007 and Gmail (!) both lack support for floating/clearing. So, have fun dusting off the table-based design knowledge you’d accumulated and then happily buried when CSS finally became a viable alternative.
Posted in Cogitatio, Web Standards | No Comments »
December 9th, 2008
My company is about to launch an email newsletter and I began to wonder about what layout dimensions I should shoot for. I’ve not given it a lot of thought in the past, but as I’m building a template for repeated reuse, I’m now giving it a few neuron cycles. There are a couple of major issues with designing for email that are reminiscent of the especially difficult browser-compatibility problems that have caused multitudes of web designers to rage and wail and burble incoherently. These issues are essentially this: 1) email clients don’t give you a lot of room to work in; and 2) email clients are not full-featured browsers.
Let’s talk about physical dimensions first. An email client is designed and navigated differently from a browser. The “chrome” on most modern email clients include not only the toolbars and menus, but an entire left-hand column used to navigate mail boxes and other features. This column alone consumes a couple hundred pixels of horizontal real estate. Vertically, the space is usually split in half so that the user can see a list of messages in the upper half and then view them in the lower. When all this is taken into account while still designing for a small common screen resolution on the order of 1024×768, you wind up with a usable viewport more in the neighborhood of 650×300.
Now take into consideration that the (X)HTML rendering capabilities of email clients are not necessarily on par with fully-featured browsers. For security and speed, most email clients have a very limited set of supported browser features. Most won’t display flash, few support animated gifs, and JavaScript support is typically limited. Thanks to spam, you’re not even guaranteed any images will display at all, but fortunately, most of the time plain-jane images will load just fine.
So here are a few guidelines for (X)HTML-formatted documents delivered via email:
- Keep your overall width between 600 and 650 px. This should be old-hat to those of us that were designing around the turn of the century, and will be an interesting excercise to the neophytes.
- Remember that the “fold” on an email client is likely going to be around 250-300 pixels down the page, so make sure you have something above the fold that will make your user want to scroll.
- Keep it simple. Avoid JavaScript. Use well-supported (X)HTML and (inline or on-page) CSS only to aid your presentation.
- Keep it standards compliant. The same “failing gracefully” principals apply to email that apply to browsers. However, there’s the additional “standard” of making sure you have a text-only version of your email ready to fly along with the HTML-formatted version.
Finally, a note about content. A rule that used to apply to physical newsletters is also applicable to email newsletters. A friend of mine used to tell me that “A good newsletter can be read between the mailbox and the trashcan”. Be brief in your email content and link frequently to expanded content on your website. Enjoy!
UPDATE! I’ve discovered that Outlook 2007 and Google’s Gmail don’t support floating and clearing. This makes design using pure XHTML and CSS very painful. I’ve got new post about this issue and my dismay here.
Posted in Cogitatio, Web Standards | No Comments »
November 15th, 2008
I could just say “Use trailing slashes!” and be done with it. But that would leave you, dear reader, underwhelmed and grumbly. You may have already read this article on A List Apart regarding using trailing slashes. In that article the author mentions three reasons for using trailing slashes when linking to directories (and I quote):
- We’re doing ourselves a favor, as this is the correct way to do things.
- We’re doing our server a favor, as this means less disk access.
- And most importantly, we’re doing our visitors a favor, because they’re no longer losing a few seconds while our server tries to find first a file and then a directory. And in this industry, you and I both know that a few seconds is a long, long time.
Now this article was written in 2002 when most everyone was still on dialup and servers were much slower in general. So number 3 doesn’t really apply anymore. In this article, I’m going to give you a new reason number 3, and go into more detail on number 1, to help you understand why this is the correct way to do things.
Read the rest of this entry »
Posted in SEO, Web Standards | No Comments »
November 14th, 2008
As you may or may not be aware, XHTML 1.0 Strict does not include the old “target” attribute of a link. In other words, you can no longer code thusly in order to tell the client browser that you’d like the clicked link to open in a new window:
<a href="http://some.domain" target="_blank">Clicky!</a>
So what does one do if you still want to open a link in a new window while still maintaining the integrity of your XHTML document? There have been many proposed solutions to this, but they basically devolve to two basic theories: 1) Use javascript to make it work; and 2) Extend the DTD to reinclude the old target attribute. I tend to agree more with using javascript to make it work. Please don’t misunderstand. In an ideal world, extending the DTD would be awesome. Afterall, extensibility is part and partial to the whole XHTML idea. But in practice, I fear this would introduce too many interoperability issues between browsers.
Read the rest of this entry »
Posted in CSS, Web Standards, jQuery | No Comments »