Neatly Sliced

I have discovered an ideal CSS Editor, and it is available only for Mac OS X: CSSEdit 2.

I’m currently enthralled with the simplest of features: code highlighting, the “intelligent CodeSense” (intellisense) of my dreams, and a little IDE sidebar so I can select that property that I rarely use, or order my background properties properly without googling. In addition, it will combine multiple properties into one (for example, combine background-color and background-image to the background shorthand equivalent). This cuts down on the size of your CSS file, and saves your fingers from typing excessively.

I just completed my July CSS Off! competition entry (article to follow) and I kid you not, I easily wrote three times faster thanks to CSSEdit. I started tonight with the shareware 2500 character limited edition, but once my file grew over 2500 characters, I could not stand to lose the productivity in switching to Smultron (my other free editor of choice, sadly lacking codesense). I thus shelled out the $30 to support this fabulous application.

CSSEdit offers a milestones feature which allows you to “bookmark” a section of your stylesheet. I think we’ve all been in that place where, in trying to solve one problem, we have mangled our stylesheet beyond recognition. Nevermore! Milestones are your solution. CSSEdit also offers selector organization, preview, and validation.

Most importantly, CSSEdit adds a layer of WebKit/Safari debugging that I have long sought after in the “X-ray” feature. X-ray equates to a DOM inspector/”View Style Information” from the Firefox dev bar. This is fantastic as Safari lacks any decent debugging tool as of this writing.

I rarely purchase shareware unless it proves itself indispensable. CSSEdit has proven itself an invaluable asset in my web dev arsenal.

Behold! The time is nearly upon us! On Saturday the 14th, beginning at 12midnight CST (the midnight between Friday and Saturday), the second CSS Off! competition begins!

Let this be a reminder of the competition, so participate like me and we will learn new and exciting things about CSS and design. Last time was fun, and this time will be better.

Update: View my article on my July entry.

Congratulations to Dawid Lizak for winning the CSS Off competition of June. View his winning entry.

Gripes

Note: A lot of these gripes are directed to my own misunderstanding of the rules of this fairly new competition. If you disagree with any of my gripes, please, leave a comment.

Non-Semantic HTML

There are divs named “top”, “topleft”, etc. About half of the classes/ids are named semantically, and the others are describing style. The naming convention implemented is far from CSS best practices.

Copy Alterations

In the “Upcoming Events” section, Dawid has changed “August”, “June”, et cetera, to their three character abbreviation. The copy that we received in the Jabroni packet (included with the PSDs were text files of the copy) distinctly bore the month name fully spelled. Changing the month in the HTML is a cop-out. If the system feeds the page “August”, and the design calls for “AUG”, some sort of server-side or client-side processing must be taken. This ought to be clarified in future contests. If I can assume that “January” has been handled on the server-side, I would love to hard-code “JAN” into my page rather than write JavaScript to handle the text transform.

In like manner, there are various places where the HTML has uppercase lettering hard-coded rather than handled with CSS. The text document bore sentence capitalization. It’s not fair to change this in the HTML unless we have specified that certain server-side text manipulation may be assumed. Conversely, it’s simple to perform an uppercase text-transform with CSS, and I’m upset to see the lack of such a simple CSS implementation on the winning entry.

Missing Headings

Some of the heading tags are in improper order. An h5 tag is used underneath an h2 tag - tsk, tsk. This is a bear on the document outline and generally poor HTML practice. Some can be chalked up to semantics, but you should never jump multiple heading levels like that. You can find errors in your document outline by using the Web Developer’s toolbar in Firefox: Miscellaneous > View Document Outline. If you are missing heading elements (as Lizak’s entry is), this tool will reveal them to you.

Usage of b, small tags

I know they are technically valid, but really, are we ignoring best practices? And the “small” tag? Could we be any less semantic? Why don’t we just write < font size="-1"> while we’re at it?

Diversion from Original Design

I understand that some diversion is good if it improves upon the original design. This gripe is just a personal “Arg” because I was going to force my header to span the width of the browser window, like Dawid, but I looked again at the design and said, “No, that is not in the design,” and refrained. Now I am wiser for future competitions.

Self-Critique

My entry did not validate. Why? Because I forgot to close my img tags a couple of times, and I forgot an alt attribute on one or two images. Arg! My CSS was valid, but not my HTML. I remember thinking immediately after I submitted the entry, “Doh! I forgot to validate my HTML!”; it must have been an oversight/tiredness from the short amount of time (only a few hours) that I had to build this.

I had not noticed my massive file size: 111kb. I wholly attribute this to my lack of proper image editing software.

Had my code validated, I am confident that I would have been one of the 6 semi-finalists. I should have abstracted my JavaScript. I’m relatively new to proper implementations of JavaScript and I see now the flaws in my JavaScript for cross-browser compatibility - namely, using getAttribute(”class”) rather than the .className property for IE compatibility. I also wonder if my lack of attention to fonts played a part in the disqualification. That’s part of the frustration: when I’m coding a design in the workplace, I can ask the designer what typeface, what font size, what exact hex color.

So it goes.

Fortunately, I was one of 15 finalists (out of the 48 timely entries). View the finalists (I’m #10 in the list of chronologically ordered entries). Regardless of my place, I learned quite a few lessons in speed-coding.

Final Thoughts

I shouldn’t gripe so much, as I neglected to close a few “img” tags, and had a minor cross-browser JavaScript quirk to learn about. I have also learned to spend more time in optimizing images for the web.

Sadly, I didn’t really learn much from the winning entry except the interesting method of employing a two-toned header spanning the width of the browser window. It utilizes non-semantic divs, but we live in the real world, not an ideal one, which makes sparing use of non-semantic divs “acceptable”.

It is a fabulous competition. With my learned lessons (from my stupid mistakes), perhaps I have a better chance of winning the next competition. Thanks to Tony and JD for their long hours judging despite loads of entrants’ griping.

CSS Off kicked off yesterday and finished today at noon. It was fun to build and pretty straightforward.

I could have made an elastic layout and so on and so forth, but I opted for sleep over perfection. I don’t expect to win by any means, but it was an interesting exercise in my front end dev. There’s always room to improve, but one must draw the line at some point.

View my CSS Off entry. Please note that I am not accustomed to slicing my own images, and I lack PhotoShop on my machine, so colors were approximations derived from the combined efforts of Colorzilla and the supplied JPG image as viewed in Firefox.

Leave thoughts/comments/improvements in the comments, if you wish.

In order to avoid confusion in typing your class/id names from memory, it is best to follow some sort of naming convention. With a proper naming convention, there will be no question on how you have structured your names.

What does CSS allow?

CSS is a case sensitive language. Using camel case class or id names (.className) leaves your naming convention open to future typo errors. Since XHTML elements are all in lower-case, and we are already using these elements in our stylesheets, it would be logical to follow that course with CSS names.

CSS allows for hyphens in the names of classes and ids. Since it is one of the only languages that allows for hyphens in names, we ought we not to exploit this? This also allows for greater readability to anyone who must go reading our stylesheet, since we are now using lower-case names.

Find more suggestions on naming conventions at PHPied’s article CSS Coding Conventions. I linked to this article before, but it’s just so applicable and sensible that I must link again.

The Symptoms

Ignoring HTML elements such as h1, h2, ul, li, and instead styling all text with classes applied to divs and spans. e.g.:

Which displays as this:

The Diagnosis

A case of divitus and/or spanitus.

The Antidote

Use HTML elements and then use CSS to style them.

Why Cure This?

There are many reasons:

1. Accessibility.

   Using HTML elements for headings, lists, and everything else increases the accessibility of your site to users who may not interact with the World Wide Web in the same way that you do. Faulkner at Fadtastic notes that disabled users account for £50 million (USD$98,780,000 at time of writing) of the 2005 market share in the UK alone. Include those people!

2. Code Readability.

   If anyone, and I mean anyone from developer to casual web nut, looks at your source, they will get a basic idea of the structure of your site. This is especially important if you are passing off your work to another developer.

3. SEO.

   Search engines place heavy weight on sites that have pertinent keywords within h1 and h2 tags. The 15 minute SEO checklist (thanks, Daniel) also shows negative points are given to poorly coded sites - yes, that means those suffering from divitus and spanitus, you know who you are.

4. Cross-Media Support.

   With the advent of pocket devices, mobile phones, and gaming systems with browsers, not everyone may support CSS or be able to view your site in the same way as you intended for the screen. Using proper HTML elements, you allow the devices to override the stylesheet if necessary and interpret your document more accurately. Opera's site offers a checklist of additional quick tips to make sites look great on small devices.

I'm sure there are myriads of other reasons to use HTML elements rather than spans and divs. Do you have any to add? Leave a comment and let me know.

When writing stylesheets, it is common for a developer new to CSS to name classes for text as .redBold, .smallText, or .bigBlueBoldItalics. These classes will wrap pieces of text to give fancy schmancy styles.

With CSS, it is best to avoid these literal names. In the case of a site redesign, text that was once .bigBlueBoldItalics may become red, normal weight, without italics, 8px in size - your styles may change and lose their meaning. This may be old news, but I still see "redText" oh-too-often.

Avoid catastrophies as red text labled ".blueItalics" by naming selectors semantically - by what they are and what the content means. Should all employee names be large, blue, and bold? Name the class .employee-name, and style it as such. Naming semantically not only improves readability to those who may have to work on your code in the future, but it also allows a site redesign to proceed with far greater ease.

The same applies to #ids. Do not name your ids #left-column or #middle-column. Instead, analyze what content the div contains. Is it the primary content of the page, the navigation? The name it as such: #primary-content, #navigation. The positioning and styling is arbitrary and should not be a permanent aspect of your naming convention.

Naming your selectors semantically future-proofs your code, allowing stylistic changes to the CSS to vastly change the look and feel of the site without ever having to touch the HTML. This is in accord with the suggestions of the W3C for good class names.