In any event, my main site should look like this (as it renders in modern browsers and IE7):

But in IE8 Beta ‘Standards mode’ it looks like this:

As I said, I completely didn’t expect this. My site was written with my obsessive attention to standards detail, and I figured on having an easy ride through the new version.

It took me a bit to figure out exactly what had caused the problem, but I finally figured it out and once I did… I was shocked.

Apparently the ability to declare backgrounds (or anything else) using rgb color isn’t there in IE8 beta.

As soon as I started changing the rgb values to hex values, the site backgrounds started showing up. It is fixable without much hassle, and without technically hacking anything (simply converting my RGB background values into hex) … but why? This functionality was there in IE7, and it’s really ridiculous to have to expect to lose functionality in a new version.

Hopefully it’s just a bug to be fixed before it goes out in full version.

After I figured out what the problem was, I did a google search on the correct search string (having had no luck searching for ‘IE8 background problems’ and much better luck with ‘IE8 rgb’) and came up with a good article that shows live examples of several things missing from IE8 that were there in IE7.

Take a look at the article from HowToCreate, and there are some live examples as well that you can view in the IE8 beta.

~Nicole

I have heard many people say that their site looks twitchy in different browsers … particularly in IE6 and below.

There are many many reasons that could happen, but when it is something as simple as color or font that is rendering differently (where most people seem to use !important), the first thing I check is whether or not there are any !important notes in the CSS.

I’ll tell you my suggestion right now is to avoid using !important altogether. It is so easy to end up making things more complicated with the use of it.

But, let’s assume that you have a site with this problem.

The first thing to check is WHERE you put the !important declaration.

Here is an example using color (not that I think you will actually do this, but it makes it easier to see):

ul#menu li a:link {background-color:olive !important; background-color:pink}
ul#menu li a:visited { background-color:green;}
ul#menu li a:hover {background-color:red}

Don’t laugh! If you don’t do this, count yourself lucky because I have seen many people create CSS rules with duplicate properties with different values. It’s crazy, but it’s also easy to get caught up in the fixing.

Okay, back to the code. Theoretically, it should do a few things:

• Unvisited links should have an olive background.
• Visited links should have a green background.
• And both should have a red background on hover.

Does it work? Of course not.

On Firefox, Opera, Safari, and IE7:

On IE6 and Lower:

Fascinating isn’t it? Of course, the quirky part is that IE6 and lower do the hover affect on both links (as it should), but all the others only do the red hover background on the visited link. Of course, a bigger problem at the moment is that <= IE6 are showing the unvisited link as pink. Well, now, let’s try to see what you could start doing to fix it.

You could try the first technique most people try which is that you should always put your properties with an !important declaration at the end of the rule line to make them work with IE6 and lower.

So, we change the code and put the !important at the end:

ul#menu li a:link { background-color:pink; background-color:olive !important;}
ul#menu li a:visited { background-color:green;}
ul#menu li a:hover {background-color:red}

Now it’s a little better.

On All:

But that hover still doesn’t work correctly. There is a hover affect to red ONLY on the visited link still, and now IE6 isn’t doing the hover on the unvisited link (like it was earlier) – it’s only on the visited just like everyone else.

So, obviously this is a problem, and the first thing that people tend to do when they see this is try making the hover important too!

Change the code to:

ul#menu li a:link { background-color:pink; background-color:olive !important;}
ul#menu li a:visited { background-color:green;}
ul#menu li a:hover {background-color:red !important;}

Did this fix it? Yep. Now all of them render the hover also and show as they should.

Was it worth it?

In my opinion, this is much easier and works perfectly:

ul#menu li a:link { background-color:olive;}
ul#menu li a:visited { background-color:green;}
ul#menu li a:hover {background-color:red;}

But in order for that to work you need to avoid !important. You would have to clear out any duplicate property/value pairs that might be causing you to set something as !important.

Suggestions in Summary:

• If you are going to use !important in your CSS – make it a last resort.
• If you end up using !important – remember to put it last in the rule for <= IE6.
• Try cleaning your code instead.

~Nicole

I enjoyed being a judge for this competition, though it was definitely not easy to pick which my favorites were out of 46 submitted designs. Huge congratulations to the winners!

The top design for the contest was SandPress by Arpit Jacob:

The 2nd place design was Moo-Point by Will Wilkins.

3rd Place was taken by the design called Prima done by Sunaryo Hadi.

There were also 3 runners up who will receive smaller prizes, but prizes nonetheless!

1. Essay ( by Ian Stewart)
2. Tiffany Blue (by Ia Lucero)
3. Shades of Gray (by Leslie Franke)

(You can see all of the designs that were entered here.)

I am glad to see that 2 out of my 3 top design picks were in the top 3 for the results. They were excellent designs deserving of some acknowledgment.

Every one who entered deserves recognition for their efforts, and I hope that all the entrants understand that the decisions were very difficult. It was, however, as untainted as I think is possible, as we were also asked to refrain from reading the forums or posts regarding the contest until we submitted our results.

Thanks go out to Scott for running this contest, Andy for impartial reviewing of the results, and the people who sponsored the contest so that winners could receive some cash.

If people have comments on the results, Scott has made a nice little forum post for after-contest discussion.

~Nicole

Life is really simple, but we insist on making it complicated. ~Confucius

The email detailed the difficult journey a new-to-DOM person was having learning how to walk the DOM tree. He simply wanted to go down to the second level of an element after finding the right element. In this case of the email, it was about how to find blockquotes within blockquotes.

The DOM trekker was simultaneously trying to figure out how to add CSS on the fly, and asking whether it would matter if it was added inline at the element in question, or in the head section.

This got me curious, so I asked what the goal was:

Very simply he wanted to display the top level blockquotes with a border on the left only, but blockquotes within blockquotes with borders on top and bottom only.

The plan was to hunt down those blockquotes using DOM, then on the fly insert CSS to change their style according to where they were in the ‘tree.’

Schrödinger anyone?

My response to this frazzled developer was simply to ‘step back, have a cup of coffee, watch a movie, then check his email.’

In his email he would find 2 lines of CSS as follows:

For the first level blockquote:
blockquote { margin: .5em; border-left: 5px solid #eee; padding-left:.5em; }
For the second level blockquote:
blockquote blockquote {margin: .5em; border-top:5px solid #eee; border-bottom:5px solid #eee; border-left: none; padding: .5em 0 .5em .5em; }

Which yields this:

Now, don’t get me wrong – I don’t mind emails like this in the least. In fact, I have people who I email or IM when I’m frantically worked up and complicating an issue beyond measure. Having a support network helps sometimes when you’re losing your mind.

Everyone does this at some point or other.

It’s why we have phrases like K.I.S.S. or ‘Missing the forest for the trees‘ and even the ever popular ‘Doh!‘

I won’t say that there is always an easy solution to every problem, but often times, the more time we spend thinking about an issue, the more complex it gets in our head. Suddenly our minds are working overtime, thinking far beyond the issue at hand – and definitely no longer keeping it simple.

I do this. Most people do this. You probably do also. It’s fine. It’s okay. Thankfully, it’s only a temporary insanity that we suffer in our stress.

With this little reminder… I’ll leave you with a couple of parting words from the masters:

Simplicity, simplicity, simplicity! I say, let your affairs be as two or three, and not a hundred or a thousand instead of a million count half a dozen, and keep your accounts on your thumb-nail. ~Henry David Thoreau

Simplicity is the ultimate sophistication. ~Leonardo DaVinci

~Nicole

I would add a few small things, such as in the ‘Starting with a Clean Slate’ section:

• Wipe all margins on block elements by setting margin:0
• Don’t specify font family if you don’t have to.
• Use font percentages instead of x-small
• etc…

Small changes, and overall the list is something that could be of significant help to someone.

~Nicole

Now, you may be wondering why that extra space is there at the bottom. Why we didn’t simply crop all the bottom off. The answer is that we want to see where the sub-menu comes in. This could be positioned differently if we were using a repeatable background on the menu bar, but since we aren’t, and in this fixed width design the text is influenced by the menu and the background, we have to work with what we have and be precise.

Open up your HorizMenu.psd (if you don’t have this file, click here to get it).

Using your slice tool, create three box slices dividing up that menu, and a fourth that is the bottom area. If you simply create boxes around the menu items, the fourth area will create itself. Make sure you are precise, and as you can see I’ve tried to center the submenu in the ‘About’ area.

Now that you have the menu sliced, you can crop out that bottom area.

After you’ve cropped the HorizMenu.psd to consist of only the menu items, then go ahead and save the PSD.

From this point, we’re going to save the slices as individual files.
File -> Save For Web...

I suggest looking at the 2-Up or 4-Up tabs to really compare what you want to save your images as without sacrificing quality. I’ve chosen to save these as JPEG with 60 quality, as shown here:

Simply click on the area showing the one you like the most, then click the ‘Save’ button.

Another box will pop up as shown:

Make sure that your selections in the drop down boxes are saving the images only, and as slices.

When you have saved them, check in the area you saved them to. You should see a folder with three new image files, each numbered and prefaced by what ever you put in the File Name box (in my case, HorizMenu).

If you don’t have these three files, or think you might have messed up somewhere, you can download them here to follow along on the next step.

That’s enough for now, and thankfully we won’t be touching Photoshop for a little while at least. I know, I know, most people don’t think that people who code websites deal with the graphic art software – but they end up quickly disabused of that notion. Even if you aren’t a graphic artist, if you put sites together, you need to learn how to work with the kinds of files that a graphic artist provides to you. After who knows, after a while… you might find yourself creating mockups in Photoshop just to do random tutorials

The next step is coming soon!

~Nicole

That is a great blank canvas theme to start from, so it could turn out to be an interesting competition. They are releasing more info sometime today on the PlainText site, but I’m leaving to go out of town today, and won’t be back to write on it for a couple of days. Make sure you check out PlainText.org today if you’re interested. They mentioned cash prizes, and of course the free advertising that comes with having your design do well.

~Nicole

• Depending on what is involved, they can be a real pain to make accessible at times.
• They tend to require a strong foundation in CSS or a significant learning curve.
• By their image based nature alone they are going to bloat the page size and drop loading speed.
• They most often are found attached to a design concept that is already heavily graphical and already has a huge loading time.
• I dislike dealing with designs whereby a client is so set on having a specific font that they are willing to sacrifice an extreme amount of loading time to have it.

These kind of things fall into my category of – ‘the prettiest websites no one ever saw’ (meaning that they are beautiful works of art, but they take so long to load that no one sticks around to see it).

All that aside – you might some day decide to make one for a client, and it is in your best interest to know how.

Herein, you’ll find Step 1 of a tutorial on exactly how I create graphical horizontal menus. People vary in methods, and hopefully you’ll find your own way to do it.

In fact, this tutorial is going to show you one of the worst kind of graphical horizontal menus. A ‘worst case scenario’ sort of tutorial. The menu we are dealing with will be:

• Used in a fixed width design.
• On a heavily graphical site.
• Mildly transparent to the background of the page.
• Include separate ‘on’ and ‘off’ rollover images on the main menu.
• Include a sub-menu that is also somewhat transparent.
• Include a sub-menu that is entirely graphical and has separate ‘on’ and ‘off’ rollover images.
• All custom fonts used.
• Important Note: The menus must be accessible. The images need to be background images. No Javascript for drop-downs.
• We’ll have to do a unique solution for IE6 and lower.

Sound like fun? Well, either way, let’s get going.

I created a little mockup in Photoshop of a menu design we’re going to use. I’m not going to teach you how to do the rest of the layout. Only the menu. You will need to have access to Photoshop or Gimp for this sort of project, or you will need to have all the individual images given to you by your client ahead of time. You can download the PSD of the mockup if you want to follow along.

Stop here and take a good look at the menu, then try to anticipate what elements might be problematic. It’s always a good idea when starting a new project to look for potential pitfalls so you can work out solutions ahead of time.

If you’re lucky, the graphic designer (or yourself) has labeled all the image layers in your graphics program really well. If you are making this yourself, you probably know how easy it is to get lost in your own design layers. If you get a poorly labeled one, go in and fix the labels so that it can be easily understood. You’ll save yourself time in the long run because good labeling is essential.

Okay, first things first – we have to get this menu ready to be used.

Go through your layers in Photoshop, and toggle the visibility (the eye graphic on/off) until all of your top level menu links are in the ‘off’ position.

Let’s select the menu portion of this design, like so:

Don’t worry about selecting the menu perfectly yet. With this section selected, in Photoshop do:
Edit -> Copy Merged
Then:
File -> New -> OK -> Paste
You should now have a new untitled window popped up that just shows the menu area.

Now, grabbing your new Untitled window by the title bar, move it off to a corner for now, and bring the full design to the front by clicking on its title bar. We’re now going to go back to our layers and switch all of the menu names to ‘on’ instead of ‘off.’

With this section selected, in Photoshop do:
Edit -> Copy Merged
Then:
File -> New -> OK -> Paste
You should now have a Second untitled window popped up that just shows the menu area.

At this point, you can close your large image PSD (for the time being at least) and work just on your pieces of the menu for a bit.

Stack your untitled images so that you can see them well. Then go to your first Untitled image (should be currently named Untitled-1), and try to carefully select only the green menu area rectangle. Then go to:
Image -> Crop

There is a crop tool, but I feel this method is a bit more forgiving. Work with whichever you are most comfortable. You may have to do a couple of passes at this to get it cropped perfectly. You want only the green leafy rectangle and the links on it for this one. We’ll do the second one a bit different, so don’t jump ahead

Go to Untitled-2, and select all but the bottom portion below the green horizontal bar. You want to still be able to see where the sub-menu needs to come in from.

Then crop the image just as you did the previous one, until your images look like this:

Right click on the title bar of the second image, and click on Image Size. Jot down the height in pixels for this image. In this example, the height is 58 pixels.

Then click on the first untitled window to select it, and do:
Image -> Canvas Size

This will bring up a pop-up window. Toggle the height and width to show the values in pixels, and in the box with arrows you want to click the middle arrow in the top row. That will pin the canvas up by the middle top. Now you want to add some canvas space, just enough for our second image. That means we need 58 extra pixels in height.

My Untitled-1 original is 46 pixels in height, so I want to change that number to 104 pixels. Then click OK.

Your canvas should be expanded now by that additional 58 pixels, and they should be only on the bottom portion. Now you can go ahead and select the entire of Untitled-2, then:
Edit -> Copy
Click on Untitled-1, and:
Edit -> Paste
Move your new section around in there until it’s just perfectly below the top one.

You can now close (don’t need to save) the Untitled-2. All we need now is the joined menu. Then go save that menu (as a PSD) with a name you can recognize. I’m very simply calling mine, HorizMenu.psd.

Alternately, you can download my HorizMenu.psd file.

If you’ve ever worked with combined graphics, you might have an idea where we’re going with this. Either way… that’s enough for one sitting.

Keep Going – Step 2 is HERE.

~Nicole

There are alot of people out there who tout the power of all these point-and-click, drag-and-drop, bait-and-switch? type of visual editors out there. I’ve yet to find one that I really liked. Beyond that – one that didn’t require me to go back and spend alot of time editing out incorrect code inserted by the visual editor. I’m open to suggestions, and I do try out new software on a regular basis – I’m just incredibly picky. When I create a design for a client, or for an open source release, I want the code to be flawless. The fact that there are ‘popular’ web development software programs out there that still create the font tag bothers me. Even more dumbfounding to me is the fact that some new web development software is being created that does the same thing.

In any event, I’m beginning to feel old in the world of technology. When I talk to some other ‘new’ techs, I realize they are probably seeing me as some sort of relic because I prefer my Linux computer and I code by hand. A teeny part of me wants to laugh and say ‘No no, I just started using Linux a year or two ago and I didn’t always code solely by hand.’ But the rest of me wins and I tend to just ignore the ‘looks’ and keep on with the subject. I think it’s amusing that to some people ‘hand coding’ makes you a relic, and to others it makes you a ‘god’, while to me … it just tells me that you probably have good attention to detail.

But before I close out this brief discussion about coding by hand, I have to mention one of those inevitable questions I get asked when people find out that I code by hand:

What software do you use for that?

You know… I’m never sure whether to laugh or cry when I hear that. Sometimes I just find myself staring in dumbfounded amusement for a moment. When my mind has stopped reeling, I slowly say “Erm… a text editor.”

The subsequent question is typically: “Which one?”

So here’s my answer, for one and all:

When Slumming in Windows: I use PSPad.
When in Linux: I use gedit mostly, and occasionally Bluefish.

Now, don’t get me wrong – I do use content management systems to make my life easier. In fact, I’m a big proponent of them so long as they generate good code (ex: WordPress) . But everything that goes into those systems – that’s coded by hand.

~Nicole

Before I continue ranting about how Microsoft seems to get a thrill out of coming up with one developer-frustrating bit of news each month, I’m going to backtrack a bit and explain what I’m talking about…

In the SitePoint newsletter released on January 10th, there was a rather major article posted. The title of the article was “Microsoft Breaks HTML Email Rendering in Outlook 2007″ and can be viewed online in the archive. The article was republished on the main SitePoint site and incited a slew of comments, as expected. After that, we saw the topic covered over at Campaign Monitor, and Pixel Acres.

Why all the fuss? If you haven’t read the article, let me summarize the general issue from the standpoint of a very irritated web designer (one of many in this case).

Once upon a time…

…Web developers/designers were finally relieved to see IE7 in some sort of standards compliant form (even if it isn’t up to specs yet, it’s better than it was – even though they completely ignored the usability experts who were warning in beta that the interface was awful, but that’s another story entirely).

… This has a secondary benefit which made developers happy, because IE is used for rendering/display of emails in MS Outlook. With IE7 running with more standards compliance, that would mean that HTML emails would hopefully offer a bit more functionality based on that IE7 rendering. (Note: To any not familiar with HTML emails, it’s tricky business to make them display well on different email programs.)

… IE7 is released and downloaded by many people across the world.

… Whoops. Somehow we missed this article on the Microsoft site in all the excitement.

… So now we’ve found out that, for some unexplained reason, Microsoft has decided to not use IE7 for rendering in the new Outlook 2007.

… "But wait", you ask hesitantly. "What -will- be used for rendering?"

… Microsoft Word.

… No, I’m not joking.

Truly, I have no idea why this took place. Both the products belong to Microsoft, yet the chose to toss out the recently improved and expected solution to replace it with one of the most junk filled word processors ever created.

To cut to the heart of it, let me explain what is making people so upset. Choosing to use MS Word for rendering instead of IE will result in the loss of several options. This list has been repeated in several places online since developers have noticed this, so I’m just going to quote the list used in the SitePoint article rather than reword it minimally to say the same thing:

* no support for background images (HTML or CSS)
* no support for forms
* no support for Flash, or other plugins
* no support for CSS floats
* no support for replacing bullets with images in unordered lists
* no support for CSS positioning
* no support for animated GIFs

I am, honestly, quite annoyed. I publish an email newsletter each week that goes out to several thousands of readers. It is an HTML newsletter with significant CSS use. Now I’m thinking… okay, so, not only do I have to rework the newsletter, but if people upgrade to Outlook 2007, and try to read their old emails, I imagine now they aren’t going to display properly.

I am not the only one who’s annoyed. Annoyed doesn’t fully encompass it though. I’m also simply dumbfounded.

Now, before any plain-text only advocates jump on the bandwagon and start talking about how they don’t care, let me give you a quote from an anonymous poster on the SitePoint post:

HTML vs. plain-text in email:

1) This typical debate comprises progressive people debating the stagnant. “HTML has no place in email.” I’ve heard my grandfather make similar statements like “computers have no place in a library.”

2) Just because email started in plain-text doesn’t mean it has no room for evolution.

3) Anyone with a subscription list that offers a choice between HTML and plain-text can attest to the fact that HTML is preferred infinitely over plain-text. So anyone who says it has no place in email is an elitist who is ignorant of the preferences of the majority.

This article isn’t about HTML vs. plain-text.

This article is about the fact that Microsoft is catering to their own monopolistic goals and placing devastating hurdles in place for the web-design community. They’re taking 200 steps backward while everyone else takes a few steps forward. And they bank on knowing that they have lassos, enabling them to keep us all at bay.

Can anyone lay out a good reason why Microsoft would have made this decision? If your answer is that “they want people to use plain-text formats because HTML emails are stupid,” you’re in the wrong forum.

Now, there is supposedly a way around this. A comment by Oscar Gensmann (on the SitePoint article) had this to say about the options in Outlook 2007:

Outlook 2007 does have a way to render an e-mail using the built in browser (security-zone).

The method is:

1) Open the E-mail in it’s own window (double click)

2) Click the toolbar button called “Other actions” in the ribbon

3) Choose “View in browser”

This doesn’t help the problem with the preview pane and the fact that the user has to do a considerable amount of work to view the e-mail in it’s correct form. It does however change the situation where it’s totally impossible to view an advanced HTML e-mail in using Outlook 2007 as the primary e-mail client, to a situation where people choosing to use 2007 can be taught how to view advanced HTML e-mails with a simple couple of clicks method.

While that may be possible, how many of your average users are going to know to do that? As most developers/designers know, the average user cannot be expected to know how to alter settings. It should be assumed that many of them will leave their software in it’s default form. Besides, while it is a partial fix, it doesn’t solve the issue of the email preview (which tons of people use).

Obviously the user doesn’t care what is rendering their emails. They won’t know if it’s IE7, MS Word, or ‘that Google thing’. All they need is for it to work the way they expect it. Which is why this is a developer problem.

If developers didn’t scramble to find work-arounds every time Microsoft threw another curveball, it would become as obvious to customers (as it is to many developers) exactly how little they care about inconveniencing people.

~Nicole