May 2004 Archives

PTG Interview

Over at The Web Standards Group, you'll find 10 Questions for Patrick Griffiths.

If you want to take me up on anything, you can go for it here (although the hr thing's already an argument going on elsewhere).

Tuesday 25 May, 2004 ( 9:53 AM GMT) | Comments (15) / Permanent Link

Sons of Suckerfish

Seven new articles have been added to HTML Dog.

Not only is there a brand spanking new version of Suckerfish Dropdowns with improved Suckerfish :hover JavaScript, there are a few siblings that have popped out too.

The articles explain how the effects of the :hover, :active, :focus and even the CSS3 :target dynamic pseudo-classes can be mimicked in Internet Explorer for Windows (versions 5.0 and up) with the tiniest piece of JavaScript, making them a real, viable practical option.

Sons of Suckerfish - An introduction to The Suckerfish, how it works, how it can be implemented and why it is better than other methods.
Suckerfish :hover - The original lightweight, standards-compliant, accessible, cross-browser :hover mimic.
Son of Suckerfish Dropdowns - Now multi-level, even lighter in weight, more accessible and more compatible (now works in Opera and Safari 1.2) than the original version, this has to be the best way of implementing dropdown menus and is probably the best example of The Suckerfish in action.
Suckerfish :focus - Mimicking the :focus pseudo-class, you can apply CSS rules to page elements that have focus, such as a text box that the user is typing into.
Suckerfish :active - Ever wanted to style something a user is clicking on? Well, if you have or you haven't, here's a way to do it.
Suckerfish :target - The CSS3 :target pseudo class allows you to style a targeted page anchor. Now not only will it work in Mozilla, you can now achieve the same results in IE too.
The Suckerfish Shoal - If you want to use more than one of these pseudo-class mimics, here's a way to do it. The code's modular so you can cut out the pieces you don't need, leaving a slimline slice of JavaScript.

This collection just kind of 'sprang up' when Dan and myself were putting together the improved Suckerfish Dropdowns ("Hey... what if we do this? Oo, and we could do this as well."). I think we might have got a little carried away, but I think it's been worth it.

Friday 21 May, 2004 (10:59 AM GMT) | Comments (128) / Permanent Link

Son of Suckerfish Dropdowns

A dropdown menu Son of Suckerfish Dropdowns is a new article from myself and Dan Webb, explaining how to apply Suckerfish Dropdowns in a vastly improved way over the original article published in A List Apart.

Essentially, a Suckerfish Dropdown is a dropdown menu built with CSS with a little bit of JavaScript bolted on to accommodate Internet Explorer, which doesn't support the :hover pseudo-class on anything other than links.

The original method was already lightweight, accessible and cross-compatible, but this method is even more so. It now works with multiple-level dropdowns, the JavaScript that mimics the :hover pseudo-class is just 12 lines long, to improve accessibility display: none is no longer used (alternatives may seem easy enough to find, but trust me, this was a real pain to sort out) and problems that were encountered with Opera and Safari browsers have been overcome.

If you can't be bothered with the article, just take a quick peek at the baby at work.

There have been a LOT of headaches trying to figure out the best way of doing this (mostly caused by Opera surprisingly enough), but we're quite confident that it's a damned good way of applying dropdown menus if you ever have the desire or need to do so and we can't think of a better way of doing it.

This article is part of a collection of seven Suckerfish articles, the rest of which will all be published in one go quite soon. So stay tuned.

Tuesday 18 May, 2004 ( 8:47 PM GMT) | Comments (534) / Permanent Link

Tables My Ass

High profile CSS advocates have been abducted and replaced by beings extolling the virtues of table layouts. Much like talking to Donald Sutherland at the end of Invasion of the Body Snatchers, we find ourselves whimpering "Andy...? Andy...? You still love CSS... right?".

Partly in response to David Emberton's ridiculous anti-web standards drivel, these "devil's advocate" objective critiques of tables for layout (kicked off by Andy Budd and then Dave Shea) unfortunately fall short of the mark and don't convince me in the slightest. So here's my response to their response and my turn at objectivity, which looks a little different. Objectivity doesn't mean sitting on the fence and I objectively conclude with pride and confidence that there is little or no room for tables in layout.

One myth is that CSS is 'hard'. It isn't hard. Well, not any more difficult than any other approach. The problem is that experienced web designers started out by using tables for layout and then had to completely change their approach to do things the CSS way.
I worked with tables based layout for years and when I first started playing with CSS layout I got stumped. "It was so much easier with tables" I thought. But that just came from the fact that I was comfortable with tables. I knew how to manipulate them. Any change, especially such a radical one, is inevitably going to prove difficult. But I even remember when I first taught myself how to use tables for layout. That confused the hell out of me too. Looking back on it, I would even have to say that table layouts were the more difficult of the two approaches to learn, what with all of those rowspans, colspans and spacer gifs.

Another odd point that Andy Budd raises is that a CSS designed page can be just as heavy, if not heavier than a page with tables. His reasoning is that because you have all of the site styles in one file and that needs to be downloaded first (which will usually be when the user visits the home page), this CSS file could actually be quite big (containing much more than the styles needed for the homepage) and so the design is top-heavy. But if it were the case that the CSS file became so large that it impeded download time in this manner, why are all of those styles in one file? You aren't limited to one CSS file and you shouldn't use one CSS file if there are substantial parts of it suitable only for particular sections. In my experience, from developing pages for small brochure type sites through to vast database driven, multi-section systems I have never come across a single case where the entire homepage (that's including the necessary CSS file) is heavier than a table-based equivalent. Those table, tr, td tags take up a LOT of space and in practice a CSS layout slashes file sizes.

Forgetting semantics (because that's essentially what you are doing when you're laying out a page with tables), web standards layout still has the massive benefit of separating content and presentation. A table will lock you into a design. If you need to change it, you need to go into a page and fiddle with the table structure ("right... so... that cell spans three rows and this cell spans five, which is next to another cell that... oh damn it! What the hell is going on?!"). No simple global changes through a CSS file (which also have the added bonus of increasing the likelihood of visual consistency across the site). And you can forget about device independence. And forget about those who choose to use their own stylesheets.

I see few benefits for tables. Laying out forms. But then forms can be seen as tabular anyway, so it's sound. Netscape 4? I'm not even convinced that supporting such old browsers is a reason. The benefits to the vast majority who have more capable browsers will far outweigh the disadvantages to the tiny minority who will see unstyled yet fully functional content. These pro-table (yes, I know they're only "devil's advocate") arguments seem to boil down to "it's easier", which is tosh. If you want to stay with the comfort of an inefficient hack methodology, that's up to you. But if you want to push things to their limits and make the most versatile, accessible, lightweight pages possible, make the effort to switch. If you had used it from the outset then you wouldn't have this problem. I've had plenty of positive feedback from HTML Dog readers who have managed to layout pages without even considering tables.

"If it aint broke, don't fix it", "it's a tool in the web designers toolbox" are some of the comments that have come up. Table layouts are a battered old soft-metal screwdriver with a rough wooden handle. You can still screw screws into a wall with it, it's just that I prefer to use my badass sturdy electric screwdriver instead. The screws are straighter and my hands are blister-free.

Friday 14 May, 2004 (10:47 AM GMT) | Comments (100) / Permanent Link

The Truth About Columns

Table columns are crazy.

You've got your col and colgroup HTML elements that are used to collect together cells in a column.

THEN, you can apply CSS to a column, rather than being forced to work with rows. Great! That opens up the possibilities of styling tables a bit without having loads of classes all over the place.

But there's a catch. You can only use the background, border, visibility and width properties.

Well, at least that's something.

But the catch has a catch.

After some brief testing, it seems that Mozilla only supports width, Opera doesn't support visibility and border isn't supported by either of them or IE (which in it's peculiar manner supports more properties than even the spec suggests).

My cross-browser tests are limited (no Mac lovin' going on in this house), but it would seem that the only safe property you can apply to a column is width.

See? Crazy.

Wednesday 12 May, 2004 ( 4:34 PM GMT) | Comments (12) / Permanent Link

WE04 Sydney

The Australian web standards brigade (it's kind of like the X-Men comics - different super powered teams in different countries) have put together what looks to be an extremely worthwhile conference - Web Essentials 2004 in Sydney on September 30/October 1.

Web standard HTML, CSS and accessibility are the key topics up for discussion with speakers including Dave Shea, Doug Bowman and Joe Clark, not to mention a whole bunch of Aussies, including Russ Weakley and John Allsopp.

It's a damned shame it's on the other side of the planet (time for a rather expensive holiday maybe??). It looks great.

I've been thinking that it's about time there was an event like this in the UK. Who's up for it? I figure London or Birmingham, maybe Manchester would be good places. All that's needed is a big wad of cash and a great deal of spare time. Plenty of people have got that, right?

Thursday 6 May, 2004 ( 4:35 PM GMT) | Comments (5) / Permanent Link

Zeldman's Transitional Redesign

I feel compelled to draw attention to the fact that Zeldman has redesigned his site. Again.

Apart from the near invisible links in the navigation bar I think it looks pretty damned good. I really like it. Much better than the previous incarnation.

[ Hmmm... Zeldman should do a Zen Garden design. That would be good. ]

What I don't understand however is the insistence on using the XHTML Transitional doctype. I mean, the new design's not far off XHTML Strict (all that is needed is to put those input elements in containing blocks) and for such a renowned standards evangelist isn't Transitional a bit of a cop out? Go the whole hog man! Embrace XHTML!

Tuesday 4 May, 2004 (11:26 AM GMT) | Comments (9) / Permanent Link