raphael.longbournprods.com

There’s popular and then there’s popular.

If you have a peek at the Technorati top popular blogs super-100 ego-thon (here) you’ll find things like Seth Godin’s blog, the Huffington blog, even A List Apart, but you won’t find some other very famous bloggers who are nevertheless, uh, famous bloggers. For example, Wil Wheaton or John Scalzi (both of whom I read on a regular basis).

These two guys have high rankings in the Tehcnorati ego-thon, and they get lots of visitors and also a certain amount of fame for their blogs. And I suppose that the Technorati ego-thon is a widely-regarded way of identifying just how “popular” a blog really is.

But.

You want to know something which might not show up in Technorati’s rankings but is without question the most foolproof way in this quadrant to really prove a blog’s popularity? I’ll tell you.

I read a number of post-modern enlightened web design CSS/XHTML wizard blogs on a regular basis. I consider these my professional (as opposed to recreational) blogs. Of these professional blogs, far and away my most favorite — and by sheer usefulness the most instructive — is Roger Johansson’s 456 Berea Street blog. Roger is well-known among the CSS design community, and he’s a favorite destination for lots of web designers and programmers, because he’s just so damned good at what he does.

But exactly how famous?

Well. Sometime yesterday (Sweden time) he posted an innocuous little entry asking his readers to answer three simple questions: do they browse the internet with their browser windows maximized, at what screen resolution do they operate, and what operating system do they use. Simple, straightforward, and requiring one-word answers. He asked his readers to answer in the comments for the post, and after two weeks he intends to close comments and compile the results.

So about fifteen minutes ago I posted my own comment. And what number was my comment?

814.

Eight Hundred and Fucking Fourteen.

Now, you, my gentle reader, may have very different attitudes, philosophies, tastes, and opinions, than me. Many people who know me personally might actually say that’s a good thing if you have different attitudes, philosophies, tastes, and opinions, than me. But let’s be clear on one point: if you don’t think that receiving eight hundred and fourteen comments to a post at your blog in less than twenty-four hours isn’t an astonishing statement on the popularity of your blog, then I’d really like to know what you take that is slowly disintegrating your mind.

Technorati and its ego-thon ranking is all well and good. Me? I don’t care if Roger Johansson’s 456 Berea Street is in the top one hundred or not — anybody who pulls 814 comments in less than twenty four hours is one of the top bloggers in the world.

Technorati tags: Roger Johansson

One of the catchphrases bandied about in the Web 2.0 internet world is “semantic markup”. Even for those who are familiar with the word “semantics”, though, when I bring up the term to many laypeople I’m met with a blank and slightly frightened stare. Semantic Markup is a really important cornerstone of modern web design and methodology, so it’s really worth getting people to understand what it is, and why it matters. The problem is that most of the time those who don’t understand the term are too intimidated or embarrassed to pipe up and ask for a clear definition, so the concept can often become just another one of those techy terms that no-one gets, and no-one therefore really values.

One example I’ve seen lots of times in web design books to illustrate semantic markup is the difference between using i and em to produce italicized text (well, basically — see below). Most modern web dudes argue that em should be used because rather than describing the appearance of the words in question it describes the meaning, or put another way, em defines why the enclosed text is differentiated from the other text around it while i simply differentiates it without indicating why.

To which lots of laypeople will reply with the argument, “if they’re both making the text italicized what’s the difference?”

The fact that they’ve answered this way means that they’re not thinking about the real scope and purpose of either markup language or the web, and if you’re not thinking about the big picture, you’ll never be able to figure out what place semantic markup has in that big picture. So let’s take a second to explore a bit of background before we consider the issue of semantic markup.

First though, a hypothetical dictionary definition: “Semantic markup is a methodology which dictates that all content of a document should be enclosed with tags that most define that content’s meaning and function within the document.” That makes sense … unless you don’t understand what markup really is.

So let’s back up a bit and succinctly describe what our modern perceptions of markup languages and their role in communicating content across the internet and beyond really is in this post Web 2.0 world of ours. XHTML (which is really just a version of XML for web pages) is supposed to be a device-independent language which uses tags to provide semantic structure to a web document — and by semantic structure I mean tags which define the meaning and structural purpose of the enclosed text.

However, note the term “device-independent”. In other words, these documents are documents which are supposed to be written without any foreknowledge of the device in which they may ultimately be digested. For many of us, XHTML is going to be read on a browser agent, a web browser like Safari or Firefox, using our eyes. But device-independent documents may very well be read on portable devices, or not even read at all, but spoken, like with screen readers which speak the text aloud.

In other words, the real purpose of semantic markup is to provide meaningful structure to a document not just for people who read it, but for anyone at all who might need to digest the document in any kind of way at all — even if that “person” isn’t a human being at all, but a machine (like a Googlebot or the API of a program — semantic markup is particularly important to bots visiting a site for search engine ranking).

That is why the meaning of a document’s structure is important, and not its appearance, and why the two terms should be treated as mutually exclusive.

To return to the classic em versus i example, making text appear italicized has no meaning to someone who can’t see the italics. But ascribing emphasis to a segment of text communicates its meaning regardless of how the user is digesting the information. Communicating the meaning of the emphasis is what makes it semantic. How it is dealt with by the so-called user agent (i.e. browser or screen reader or whatever) is an entirely different matter.

All web browsers have prebuilt styles for displaying all HTML markup, from em to code. I’m pretty sure that all of the current crop use italicized text by default to render content enclosed in an em tag. This makes perfect sense because the de facto method for communicating emphasis in writing (in Western languages at least) is through italicized text. Whereas as a matter of fact using the em tag to make things like corporate names italicized is probably breaking the rule of semantic markup, unless the author of the document specifically wants emphasis placed on those corporate names. I’m guilty of using the em tag for any and all needs of italicized text, and I know a lot of other people are too. Perhaps I should consider revising this to use the em tag only for words and phrases that are designed to have emphasis placed on them, and save the visual needs of italicizing corporate names and the like for the i tag, since that’s purely a visual construction.

Anyway, to make a long story short, selling people on the notion of semantic markup is diffcult unless they know that web sites are supposed to be device-independent. If they can learn to think of the content of the web sites as independent from the style of web sites (a cornerstone of enlightened web design), they can begin to grasp the concept of why choosing the most appropriate tag to define the meaning of the structured content is a really valuable thing, and why the difference between em and i is a lot greater than appearances might suggest!

Technorati tags: semantic markup, web design.

A couple weeks ago, knowing I would be out of town on voting day, I followed the instructions on my sample ballot and logged into lavote.net to apply for an absentee ballot.

I found the page on the site, entered all my info into the form, punched submit, and was presented with a confirmation page, complete with confirmation code of my submission (which I promptly wrote down).

Earlier this week, after really getting worried that my absentee ballot had never arrived, I called the absentee ballot number for Los Angeles County. The following exchange occurred:

Me: Hi, I filled out a form on your website for an absentee ballot and it hasn’t arrived yet, so I’m kinda worried. I have a confirmation code for that.

Ballot person: What’s your name?

Me: [I give her my name and soc and all that] … but wouldn’t you rather have my confirmation code?

Ballot person: [typing and a pause] You’re not registered in our computer.

Me: But I filled out the form at your website and it was confirmed. I have a confirmation code.

Ballot person: Well you’re not in the computer.

Me: Can I give you my confirmation code and you can check that way?

Ballot person: No. Um, I can’t do anything with that code.

Me: Can I apply for that absentee ballot now, then?

Ballot person: No, it’s too late.

Me: Oh, wonderful. So what am I supposed to do?

Ballot person: You can vote on Tuesday, or go to one of our early voting locations.

Me: I’m not going to be here on Tuesday. The whole point of applying for an absentee ballot is because I’m not going to be here Tuesday. Look, can I talk to one of your web engineers and give them my confirmation code to figure out what happened?

Ballot person: No you can’t talk to one of our web engineers.

Me: So basically this whole confirmation code I got is completely useless and doesn’t confirm anything.

Ballot person: Well.

That was that. I managed to find time to drive to the early voting polling place — the only one in the entire San Gabriel Valley — and do my voting there. But that doesn’t lessen the distaste of my experience.

The Internet will never be a valid and acceptable place to conduct important business like voting if pathetic worms who can’t program a fucking submission form are hired to run government websites.

I should have known not to trust lavote.net the moment I was confronted by a homepage using the most embarrassingly outdated table-based, clunky nonsense for a design. Gotta love that garish primary blue table cell background color for a sidebar, though.

Look, if I receive a confirmation code of any kind as the result of completing a process at any kind of website, I expect to be able to use that code as proof of my submission and as a reference number to enquire about the submission in the future. Am I to now assume that confirmation codes in the future can and very likely will be just so much useless numbers, and not a valid record of my submission at all?

PC World Canada recently put up a list of the 25 worst computer products ever made. It’s quite a fun read, and can be found here.

What tops the list? What else: American Online.

But one entrant that is of particular interest to web designers, clocking in at number 8: Microsoft Internet Explorer 6.x.

With its neverending list of security vulnerabilities, ghastly support of CSS, and Microsoft’s obnoxious insistence on forcing any Windows user to have it crammed down their throat, why shouldn’t it be on the top list of worst computer programs?

I hear other web designers, when dealing with IE’s shortcomings, hasten to say they’re not “browser snobs”. It doesn’t require snobbery to hate Internet Explorer 6. It just takes common sense.

We shall see if IE 7 makes the hideous shortcomings of 6 a dim and particularly unpleasant memory from the past. I have some doubts (like the fact that CSS support is still lagging behind the other browsers, for no reason), but if for nothing else, I will welcome IE 7 as the means to put IE 6 at last to rest. Hopefully forever.

So I ended up giving the site a facelift after all. I call it version 1.5, since it still essentially uses the same color scheme, typefaces, and image source material.

There’s still lots to be done under the surface: the contact page is ghastly, there’s some PHP auto thumbnail stuff I haven’t finished, the sidebar is atrocious; the list goes on.

Since I see that none of you are interested in those changes which I have done, I thought I’d spend a moment discussing them.

First and foremost, the site is fluid-width. I’m amazed by how many of the blog sites I visit are fixed-width, and since my metrics are telling me that I get visits from people with monitor widths as great as 1920 pixels, it seems rather unfair on them to have to view a web page that’s just 720 pixels wide or something (can you imagine the side margins they must have?!). I have however slapped both a min- and max-width on my wrapper div, at 768 and 1500 pixels respectively. Hopefully this will keep the side margins on you 1920-pixel guys at more respectable levels, while at the same preventing the lines of text from stretching clear across the Atlantic (although, actually, I personally think they’re getting a tad long even by 1500-pixels, though you can always increase the text size to compensate — more on that in a sec).

The main portion of the blog is about as simple as things get. div#content, where the actual posts are displayed (aka the main column), is set at 65% width, while the sidebar column div is set at 30%. You math geniuses might notice 5% has gone missing — this is a very easy way to create a gutter between the two columns, since using fixed padding on percentage-width columns will break the layout. Block elements within each column are then given their own pixel-based padding. div#content and div#sidebar are floated left and right, respectively, using the so-called Opposing Floats method. This method is very well-suited to fluid width layouts, and is the most bulletproof to browser hiccups and the most efficient in terms of CSS of any approach that I know. If you know an even simpler method, I’d love to hear it. If it breaks in your browser, I’d really, really like to hear from you.

Other tried-and-true CSS methods are in use elsewhere. h1 is knocked off the page using text-indent, and replaced with a background image (my logo) set at an explicit pixel height. If memory serves, this technique was pioneered by Doug Bowman and is one of the cornerstones of CSS design. Unlike last time, the logo is a part of the background image rather than floating on top as a separate PNG with transparency, as I did last time, which was then served only to contemporary browsers that understood the direct descendant selector in CSS; the rest just got plain browser text (because they weren’t going to be able to understand the transparency in the PNG). Since there’s not really any reason to have an independent floating logo over my banner now that the logo is anchored to the left, I’ve gone equal-opportunity by using simple technology that most modern browsers understand: one jpeg image comprising logo and banner that replaces the h1. Of course, in keeping with blog traditions, it’s also an anchor with a display: block rule that will send you to the homepage if you click on it.

As for the ul list comprising my highly-rudimentary navigation bar, I’ve simply given it a position: absolute, and stuck it a few pixels away from the top right of the browser window. Each li element then is rendered with display: inline, some padding to separate, and finally a 1-pixel thick left border to make a simple divider. It’s probably not the most attractive or elegant nav bar you’ve ever seen, but then, it’s probably not going to get much use, either. Given its relative lack of importance in the functionality of the site, I didn’t feel compelled to build an elaborate nav bar into the whole graphical scheme, complete with rollover buttons and the like; I figured simple was better and probably more appropriate.

The header and footer graphic are both 1600 pixels wide, to accomodate the fluid layout when viewed at different screen widths, and they were designed very much to “work” no matter how much of their width was visible.

Another important factor for me when designing a dynamic-layout site like this is ensuring that 1) the layout doesn’t break if the user increases or decreases the text size in his/her browser, and 2) it looks good at any size. I’m really of the opinion that most sites should be designed to be as flexible and adaptable to the end user’s needs as possible. The portability of HTML was one of its original design concepts, and I think flexibility in web design is a good thing. If I’ve done my work properly, hopefully you should be able to increase or decrease the text quite a lot before the layout begins to collapse, if indeed it ever does. (The navigation bar does start to look a little strange at huge text display sizes as it begins to dwarf the logo, though …)

Oh, and if you ever find yourself designing a fluid-width blog one day, do yourself a huge favor and slap an overflow: hidden rule on whatever container your site has for the actual blog posts. Doing so prevents large images and other fixed-size elements included in your posts from potentially wreaking havoc on your layout when visitors with narrow screen resolutions visit (especially when they’re using IE6.0, which does not understand the min-width rule). Browsers need guidance in being told how to contend with wide images that won’t fit in the column width containing them, and my preferred method is the overflow: hidden rule, which simply cuts off any of the image which would push beyond its container’s width.
For this go-round, the CSS is tremendously lean, almost frighteningly so. To choose sturdy simplicity requires lots of confidence, and I’m not very confident. We tend to feel that whipping up complexity around our projects is like safeguarding them against failure, against ridicule, but the best CSS is the CSS that uses as little as possible.

I’m much happier — at the moment — with this design than the last, which I thought was dreadful, and didn’t degrade very gracefully in IE6.0. Also, aesthetically I think this design is a bit better, a bit clearer, a bit roomier, and all that fantasy hoo-hah has been toned down, abstracted, zoomed in, giving the texture and nuance and feel without being as distracting as before.

And a month, two months, from now? I could despise it.

Photographic credits used in this design (same as before): castle elements culled from photos by Mayang Murni Adnin. Knights on horseback (detail) photo by Jeff Gynane. Both of whom own the copyright on their respective photography. Used with permission in both cases.

I’m going to be tinkering under the hood on this blog today and possibly into tomorrow. I don’t know if I’ll be emerging on the other side with a new look and layout, or if the alterations will be confined to behind-the-scenes type stuff, but please be advised that there may be oddities and strangeness when viewing the site over the next day or so. Water and electricity may be unavailable for certain periods of time.

Okay, so maybe when you launch a weblog and you do the template yourself and then you say you’re a “web designer”, you might want to take a little more care and effort with your blog so that it doesn’t look like a total piece of shit.

Sorry. I was in a hurry. If visiting this site has in any way caused you any sort of adverse physical effects, such as nausea, I apologize from the bottom of my heart.

And, just out of curiosity, what are those knights on horseback supposed to mean exactly? I thought I’d ask — ’cause I don’t know myself.

And if you’re an Internet Explorer user: sorry. I don’t mean that in a snippy, snobbish sort of way (though I do think life will be better on the Net for you if you visit this), but because, if you’ve visited the site using IE as your browser, and if your browser window is quite narrow, like less than 800 pixels wide, chances are very good that the sidebar which is supposed to be, erm, on the side, was actually underneath the left column. That’s right. Underneath. Great place for a sidebar if you ask me.

Since I was in such a hurry when I threw this sucker together, and since I didn’t really do the amount of browser testing that you really, really should do, all the time, I forgot to think that if I started putting pictures in my posts, and if they were wider than a pinhead, visitors with IE6.0 and narrow screen sizes were going to have their browser jettison the right column in order to have enough room to fit the images.

I is a profetchonal.

(Other browsers don’t suffer from this problem because they understand the CSS min-width rule, which won’t allow liquid designs to shrink beyond a specified minimum width.)

There are some things I did intentionally to IE for this design; what is sometimes called “graceful degradation”. This basically means that, because IE lacks support for a lot of CSS commands, it’s fed a different, more basic type of style for some elements on the page than the more compliant browsers. This is all cosmetic stuff. It’s not like IE users can’t leave comments, or navigate the site (unless the idiot designer has created a situation where IE jettisons the fucking sidebar to the bottom of the page!) — rather, Firefox and Safari and Opera (and so on) users get a bit more eye candy.

As witness the following two shots:

(my homepage in Internet Explorer 6.0 for Windows)

(my homepage in Firefox 1.5 for Windows)

If you look closely at the second picture, you can see that the title of the newest post has a little graphical backdrop, and the logo next to the knight guy is completely different in each picture. Both of the images appearing in the Firefox screenshot are PNGs which use transparency. Since IE6.0 does not support PNGs with transparency, rather than sacrifice the look I wished to achieve in all browsers, I fed IE6.0 a different set of rules, so IE6.0 gets just plain old text in the logo, instead of the glowy text.

These are very subtle differences, of course. Unless and until most Internet Explorer users jump to IE7.0 (which will support PNG transparency, by the way) and its somewhat better CSS support, I’m not going to be doing major structural designs using CSS that IE6.0 does not support, potentially feeding a sizable number of visitors a site which does not work in their browser. My clients might become cross.
By the way, for those of you who didn’t realize, this is why CSS designers are resentful of IE6.0 — it’s still the most-used browser in the world, and as such designers are forced to greatly limit their choice of CSS rules simply because IE6.0 does not understand them. Firefox, Opera, Konqueror, Safari — they’re on more or less equal footing in supporting CSS elements correctly. IE6.0 is not only much more limited in its support, but it also has more bugs implementing the rules it does support than the 405 Freeway has lanes.

Of course, none of this has anything to do with the fact that I whipped this site together too fast, not observing very important design rules, and failing to rigorously test test test. As soon as I find the time, I think a bit of a re-design is in order, one that has a bit less knights in shining armor and a bit more useful layout and structure.

However, because I do know that a few of you have dropped on by using IE6, I thought you might be interested in a tiny peek at what more contemporary browsers might do for you, here or elsewhere.

Now, what should be my theme next? Something intergalactic, with spacemen floating against the inky blackness? A desert landscape teeming with strange wild creatures? A fetish scene with lots of hot babes in rubber catstuits … ? I wonder …

Okay. Jason Santa Maria commented on it here, Jeffrey Zeldman commented on it here, and probably a lot of other people commented on it as well. It’s the now age-old assertion that “ugly is good” when it comes to internet design. The other two guys — leaders in the field — have offered measured, balanced, and compelling reasons why ugly design on the web is not a good aesthetic consideration (duh), but I thought I’d step in using a slightly different tone:

What kind of fucking moron swaggers around like a complete fool making sweeping proclamations about an approach as fallacious as “ugly design” is “good design”? That has got to be the most absurd oxymoron I’ve ever heard.

Let me be just a bit more measured: presenting information on the web has the exact same needs as presenting information via any other media. Designing the framework in which that information is presented, and through which it’s navigated, communicates that information more effectively.

The argument for Ugly is that the web is more effective when aesthetics, careful color palettes, and the other tools of traditional design, are chucked out the window in favor of extremely plain, even unattractive presentations of information.

Mega-success Craigslist is often cited as an example of why Ugly works. The claim is that because Craigslist looks like a link aggregator from 1996 (when, likely, there really weren’t aggregators as such), it’s successful. Jason Santa Maria says it best when he replies:

Craigslist is often cited as a prime example for the ugly/undesigned site success story. Guess what, that’s because you can’t see past the visuals. Does that mean it fails or is poorly designed? Well, no, just one piece of the puzzle is missing. Fortunately for Craiglist, the other pieces are so strong that they are able to overcome it. Craigslist succeeds despite its graphic design.

(my emphasis)

Jason is quite right — just because Craigslist is ugly as sin and a success doesn’t mean that it’s a success because it’s ugly. As Jason goes on to say, there are gallons of ugly/non-design sites cluttering up the interwebs, which are anything but successful. Craigslist succeeds despite its graphic design, not because of it.

Any effective design is one which delivers its contents to the reader most effectively. At its very heart, this is what any design should do. These guys on the Ugly bandwagon understand this just as well as the opposition — they just argue that the path to effectiveness lies in reducing the web to generic, stock HTML. I’m not going to claim that there isn’t a site in the world which isn’t most effectively designed by going Ugly, but I am going to claim that blindly making every site conform to this standard is to completely miss the point of what design should be. A design should use layout, color, and graphics to deliver its contents most effectively, on a site to site basis. Those who claim that all sites would benefit from one approach are the same types of people who think that you can set your Unsharp Mask filter to one group of settings and then apply it to every photo you correct. The world is simply not that narrow.

And calling this Ugly thing “nondesign” is absurd. Everything is design. Designing a site to be “nondesigned” is still a design choice. Choosing, for example, to let the browser present all the H2s and ps using the generic font and size is still a design choice: the designer has designed the site in this manner (duh). Everything is design. If you truly took design away from a site, it would disappear. The appearance of content necessitates design.

This does not necessarily mean that whipping up some kind of goopy, over-saturated site is going to make the content better. Poor design is poor design, whether it’s got two megabytes worth of background images or whether it has zero. Design is a set of aesthetic decisions intended to deliver content better — it should not be a platform for a designer to drown the content beneath his or her palette of egotistical meanderings.

Take a look at A List Apart. Redesigned some months ago, the designers chose a very subtle, very clear, very “print” style design approach. While beauty is in the eye of the beholder, I would contend that most visitors think it’s a “good design” for its subject matter. I certainly think it is. The choice of typography, white space, and layout with its magazine-style approach, enhances the content, rather than distracting from it.

Would A List Apart be a more effective website if all this print-inspired layout were stripped away, and it was made Ugly? Emphatically, no. Because the design was very carefully chosen to present the content in an environment which emphasizes its tone, removing this design would require the visitor to work harder to draw the meaning and context out of the content. The design here — as it should everywhere — focuses the reader’s attention and creates an atmosphere in which the content can convey the strongest meaning in relation to its subject matter.

That’s what I mean when I say that good design is design which enhances and delivers its content most strongly. If, by some chance, using an unformatted, Ugly approach is the best environment for a site’s content to be delivered most powerfully, great. Go for it. Fabulous. To claim that all web sites should go that way because a variety of designs somehow cloud the internet? Give me a fucking break.

I find this whole sabre-rattling thing enormously distasteful. Time to move on. I think, for my next post, I’ll do something enormously innocuous, like talking about some 1980s TV show.

Technorati Tags: web design, ugly, Jason Santa Maria

Like many CSS-based web designers, I don’t have tons of whiz-bang gadgetry in my arsenal of tools.In fact, after finishing the graphical elements in Photoshop, really all that I use is my trusty text editor (*) and FTP upload software. Any of that kind of WYSIWYG stuff — like Dreamweaver — doesn’t really work for CSS, so it’s useless to me. I just keep Firefox open as I’m uploading and keep refreshing the design in the browser as I tweak my CSS into shape (of course, I’ll avoid really long parentheticals about the “and next” with IE6, and the horrors of then mangling your design until it at least kinda works in the Browser of Great Evil).
But there is one additional tool in my kit which bears mention, without which I would be stranded, helpless, sobbing like a babe as the unkind waves of the web world buffetted me on the ocean of the internet.

That tool is the Web Developer toolbar extension for Firefox, written by designer Chris Pederick. As the name implies, it is a toolbar extension in the Firefox browser which essentially allows you to strip, expose, debug, investigate, explore, test, and otherwise disassemble the page you are viewing. When that page is a page you’re in the process of designing / revising, it is an invaluable tool for tracking down errors and experimenting with solutions to layout issues. If you’re doing CSS-based designs, I would say that it’s nearly invaluable in solving design issues with your pages.

There’s fifty trillion commands and options, so I won’t go into all of them here. But I will highlight some of the commands I use the most, which include:

• View Style Information: the ability to click on any element in the page and view the CSS statements which Firefox have applied to just that element in a new tab. I find this really helpful in determining why, for example, some statements are not being applied to an element that I’ve defined in the CSS (like text not going bold, or an anchor not being displayed as a block). If the statement you expected does not appear in the new tab, it means that for some reason Firefox does not realize that the CSS definition applies to that element — probably because of a typo or oversight (like accidentally defining a class as an id in your stylesheet). I’ve solved countless boo-boos this way.
• Display Line Guides: much like guides in Illustrator or Photoshop, a horizontal and vertical guide appear laid over the page, which you can move anywhere in the viewing window. I sometimes use these to verify whether the tops of floated columns really do line up to the pixel, or if something I’ve overlooked is throwing them off (like forgetting to zero out standard margins).
• Outline Block Elements: perhaps the most powerful tool in the toolbar, you’ll see this used in countless web design books. Every block level element in the page gets outlined in a variety of color-coded boxes, and labelled. Structurally, turning this function on can be the most elucidating of all effects, as you suddenly realize, say, that those dls are overlapping across that div, or whatever. Because the colored outlines show the true dimensions of the block elements in your page’s design, you can really see what the underlying structure of the page is, and where these block level elements are meeting (or colliding).

There’s tons more, like a really handy set of what amounts to bookmarks so you can jump to various validators with nothing more than a single click, or all the commands which help you disable functionality on your site (like seeing how your page looks with images disabled). But the best way to see if it works for you is to load it in to your Firefox and start to play with it.

It’s become one of my most cherished and important web design tools, because it greatly facilitates the debugging / revision process, a process which can be extremely frustrating and time-consuming. It even helps me when I load up my design in IE6.0 (which I always do after nailing it in a more compliant browser), because I bounce back and forth from IE6.0 to Firefox, using the Web Developer toolbar to assess those elements (and the underlying CSS governing them) which are causing IE to choke. So, while it’s not actually designed for use with IE, it greatly speeds that part of the process which we can all agree is the least rewarding part of CSS-based design.

Think of it as a kind of Swiss Army knife with a first-aid kit built in. I’d probably be drowning in that unkind internet ocean by now if I didn’t have it.

* Most designers use BBEdit as the text editor of choice, but since I don’t have a Mac I use the “source code editor” functions in Adobe GoLive CS, which I got bundled with my copy of the Creative Suite Pro CS upgrade. Although GoLive can be a major pain in the ass, and I wouldn’t touch the WYSIWYG stuff with a ten meter pole, the source code editor is very good, color-coding HTML, CSS, and PHP, and pretty helpfully pointing out code errors — it’s particularly helpful when your HTML is wrapped up in layers of nested if or while PHP statements, because you can quickly ascertain to which statement a given closing bracket belongs, and so forth. It’s also a so-so FTP uploader, containing trees that form a particular site, and it saves some time that would be consumed constantly jumping over to SmartFTP to upload my revised files.

So I’m browsing over my site and something strikes me. Where are the comments boxes? And who is guilty of neglecting to make sure they’re there?

Oh. That would be me.

Getting to grips with WordPress is an ongoing process. At least for me. Or maybe it’s just because I’m both lazy and stupid.

But the ability to post and read comments is now in. Like it should have been from the start.

Hah. Web designer, indeed.