Birnam Designs Blog -- sharing tips, resources, ideas, and more on web development and design

Yes, their search results still use tables and font tags. BUT I noticed today that Google’s results have switched from being listed with <p> tags to using <div> tags! It’s definitely progress.

If you’re interested, I noticed this when one of my Greasemonkey scripts stopped working. My script will number the Google results, which I use to test SEO rankings. If you have Greasemonkey, and you’re interested, you can install Number Google Results here. It’s already updated to work with Google’s new format.

One good trick using CSS is making wrapping blocks of elements. Grouping elements together used to be something developers used table cells for, but when CSS started to be used more regularly, alternate methods were invented. A common use is converting <ul> lists (which are typically vertical structures) into horizontal menus. The really good thing about the CSS-based solution is its flexibility when wrapping is involved.

For table-based designs, the number of rows and columns had to be preset. With a CSS-based wrapping solution the size of the container can dictate the wrapping. For instance:

• block
  caption
• block
  caption
• block
  caption
• block
  caption
• block
  caption

Can be produced like this:

ul.wrapping_blocks li { list-style: none; float: left; padding: 10px; border: solid 1px #aaa; } ul.wrapping_blocks li .block { width: 120px; height: 20px; background-color: #1B2B3A; color: #fff; }

<ul class="wrapping_blocks"> <li><div class="block">block</div><div class="caption">caption</div></li> <li><div class="block">block</div><div class="caption">caption</div></li> <li><div class="block">block</div><div class="caption">caption</div></li> <li><div class="block">block</div><div class="caption">caption</div></li> <li><div class="block">block</div><div class="caption">caption</div></li> </ul> <div style="clear: both; "> </div> <!-- necessary to cancel float ... -->

The “block” and “caption” groups are kept together, and sequentially listed in the HTML. They are all floated, and therefore ’stacked’ horizontally, wrapping at the edge of the container. An arbitrary number of these groups can be placed using the same code, and the wrapping is taken care of by the rendering. Here is the same code with ten blocks:

• block
  caption
• block
  caption
• block
  caption
• block
  caption
• block
  caption
• block
  caption
• block
  caption
• block
  caption
• block
  caption
• block
  caption

To get an even better demonstration, this link will open a new window that you can resize and watch how the wrapping takes place.

At first one of the drawbacks of doing this with CSS as opposed to table is the lack of a border-collapse style! As you can see from the examples above, the bordering edges are doubled. Uh-oh! Border-Collapse only applies to tables!

No problem, just reduce the right and bottom margins by -1. If you want thicker borders, just change these margins to the negative border thickness.

• block
  caption
• block
  caption
• block
  caption
• block
  caption
• block
  caption
• block
  caption
• block
  caption
• block
  caption
• block
  caption
• block
  caption

.collapsedborders li { margin: 0 -1px -1px 0; }
<ul class="wrapping_blocks collapsedborders"> ... </ul>

I really had a lot of hope for IE7. I was eager for the Big Day when IE7 would be pushed out to millions of computers around the world, changing the landscape of the internet overnight. Suddenly the support for PNG transparency would be in the majority of internet users! Suddenly CSS bugs would be vanquished, and multi-headed hydra designs would be a thing of the past as IE7 would bring better standards support to the majority of the population!

Oh well. It was a noble thought.

As developers all over the internet are discovering, IE7 simply replaces old bugs with new bugs. Most of what I’m seeing now seem to be pure rendering issues, such as the inability to redraw backgrounds in negatively-margined div elements after the users scrolls out and scrolls back in. I’m seeing some positioning bugs. And big problems with opacity support.

So now I’m stuck importing yet another stylesheet declaration into my html.

I shouldn’t have been surprised. Web Development is just another skill, after all, and as far as I’m concerned all skills have exactly one thing in common: you start out bad, and you get better. So what was so surprising? Why, taking a look back at some of my earliest projects, of course.

They stunk.

But it wasn’t just my designs that were bad. My code was bad. My tools were bad. My fundamental strategies were bad. I can’t receive all the blame for this – after all, the web has been evolving, too. Popular stratagies, browser capabilities, and available tools have all gone through their own changes. But in the last eight years, I have made lots of advances on my own. I am always learning new methods, new tools, and new strategies on the path to intelligent web development. These are tips I’ve learned from my progress so far.

(Inspired by the Graphic Push article “The Path to Intelligent HTML“)

Coding and Design

Frames - NO

My first websites used frames everywhere. But I know enough now to realize that frames are Bad News in most cases. Frames complicate bookmark behavior. They require a fundamental fragmentation of a page, which reduces search engine optimization and can cause other problems. For instance, users coming to a site through a search engine link might only see a partial page. It’s not pretty, and frames are safely out of my life now.

There was some good to come out of frames, though - or at least the IFrame variant. Several years ago (early 2001) I was experimenting with IFrames as a method of transferring data between the page and the server and updating the existing content without having to reload the page. I knew that was pretty neat at the time, but now I realize I was, in fact, experimenting with an early version of AJAX. Fortunately, there are better tools for AJAX now, but using IFrames was a start.

Tables - NO

One of the worst aspects of my old code were the enormous nested tables. Four, five, six layers deep? Maybe more. Updating old code was like scraping off wallpaper and discovering that you had to peel off five or six more layers before you could paint the wall.

There will always be a place for tables in web design, but there are better ways to layout a page. CSS allows you to arrange your page into simple, logical blocks of content. It’s much simpler and cleaner than the old table-based layout, which improves code readability and makes a page easier to update. Not only is the code cleaner, but I believe that the entire philosophy behind CSS-based pages helps promote cleaner, more user-friendly pages on the user end. Better code and better pages? It’s a win-win. While we’re on the topic of CSS:

CSS - YES

For years my web projects were all very simple. Five or six pages, minimal fuss. Site-wide changes like updating font size or link color were merely a little annoying. But when you’re working on large websites, even simple changes can take a long time. With CSS you just edit one file and that’s it. That’s efficiency. Markup was also improved, by eliminating the need for tags like <font>.

CSS also opens up a lot of possibilities that weren’t available before. Web developers now have access to better typography, more sophisticated use of background images, easier printer-friendly and text-friendly designs, better search engine optimization results, better accessibility support, and lots, lots more. Moving to CSS was one of the biggest steps in my evolution as a web developer.

Javascript, AJAX, and DOM - YES

My old experiments using IFrames to communicate behind-the-scenes turned out to be a sign of times to come, but I had no idea how far it would go! Now, tools like XmlHttpRequest are available on the most popular browsers, and I am more comfortable with DOM scripting - both of which get used in AJAX, the hottest thing on the web right now. I’ve incorporated it into a few projects so far, and I love it!

The most interesting thing I’ve found about AJAX is that instead of adding a layer of difficulty to the programming, it actually makes a lot of my tasks on the backend even easier! More user-friendly and easier to develop? There’s a reason why it’s the hottest thing on the web!

No, I’m not talking about Quirksmode.org, the fantastic resource on browser compatibility. (Although if you don’t know about that site already, do yourself a favor and go ahead and bookmark it. Go on.) I’m talking directly about the quirks mode in browsers. More specifically — and you can skip to the end if this is all you’re interested in — I’m talking about how to determine if a browser is running in standards mode or quirks mode.

Both Internet Explorer and Firefox (and assumedly other modern browsers) have two different rendering modes, standards and quirks.

But first, what is rendering? It is the process of interpreting the markup of a web page and determining how to draw the page. As difficult as that sounds, believe me, it’s probably even more difficult than you realize. It’s not just HTML. It’s also javascript, XHTML, CSS, DHTML, DOM, VML, embedded plugins, SVG, Canvas, XML, XSLT, MathML, SGML, etc. And even within these types of markup there are different version numbers. HTML 1, HTML 2, HTML 3, HTML 4, XHTML 1.0, XHTML 1.1, CSS 1, CSS 2, CSS 3, etc. And then, within those levels of markup, are even more levels. Transitional XHTML 1.0, Strict XHTML 1.0, etc.

Obviously, trying to interpret all of these is no easy task, even if you could rely on every developer in the world to be a markup expert. Of course they’re not, so you also have to account for errors. How do you handle markup mistakes as gracefully as possible so that the resulting webpage isn’t rendered in an incoherent mess of text and images?

Enter Standards Mode (aka Standards Compliance Mode) and Quirks Mode. Just from their names, you can probably guess which one is used to render pages with flaws and which one is used to render pages that observe all markup rules. For me, Standards Mode is a goal. If I have created a webpage that is rendered with standards mode on both browsers, then I’m in good shape. (when I say ‘both browsers’ I am of course referring to Internet Explorer and Firefox) If my page falls into quirks mode, I need to figure out what’s wrong. It’s more than just observing good markup rules — it is also more reliable to have a page that is rendered in Standards Mode. When I say reliable, I mean that it is easier to get Internet Explorer and Firefox (and other standards-observing browsers) to render your page in the same way. This saves enormous headaches, because otherwise you have to sometimes create multiple style definitions, or even multiple pages, in order to get things to look right for all browsers.

Now that we know which is better, here’s the question: how do you tell if the browser is rending in standards mode or quirks mode?

In Firefox, it’s simple. Right click on the page, select View Page Info, and look for the “Render Mode:” detail. Tada! If you’re a serious web developer, though, you should also ensure that you have the Web Developer extension for Firefox. If you have this extension, then there is always a nice friendly icon in the corner of your screen that will show you the render mode. For instance, at this moment, I can look up and see that there is a blue circle with a checkmark in it, so I know that this Wordpress admin page is running in standards mode. When I roll over the icon, a tip pops up and confirms this. Or I can click on the icon to jump to the View Page Info dialog which will tell me the same information. If this blue circle is greyed out, then I know I’m viewing a page that is relying on quirks mode.

In Internet Explorer, it’s not so straight-forward. To the best of my knowledge, there is no built-in functionality that will show what render mode the browser is using. It’s not in the page info. Instead, I defer you to the Render Mode Bookmarklet. It’s easy to use: follow the link I gave you and you will find a page that contains a link at the very bottom. Clicking this link runs javascript code that will determine the render mode of the page and give it to you via alert box.

All you have to do is save this link as a bookmark, and you have a bookmarklet that will do the same thing to whatever page you happen to be visiting! Enjoy, and good luck always finding your pages in standards mode!

I finally found a resource that describes the differences between list rendering in IE and Firefox. If you’ve worked much with CSS you’ve probably found the same frustrations, where your lists are not rendered with the same indent between browsers, especially if you have reset the margins and padding at some point.

The secret, it turns out, is that IE renders the indent based on ul’s margin-left, while the rest of the browser world uses the padding-left style of the ul tag. Set them both to the same value, et viola!

See a more detailed description here.