Troidus > Archives

This post from Khaled made me think about the way I write my CSS, have always written my CSS code. I follow the regular one element, one line approach for attributes with more than 2 elements, and a single line for 2 or lesser. I’ve found that the spacing helps me easily sort through files, and find some rogue piece of code.

However, structuring doesn’t end there. There is also positioning elements, comments, and such.

I usually start the file with a little comment, and don’t usually comment, unless some bugs are encountered, and obviously for the Holly Hack.
As for positioning, I’ve noticed people mostly alphabetize their CSS attributes, but I never found it comfortable finding a letter and placing codes…
I go from top to bottom. I mean, I follow the XHTML coding. I go from the first id or class encountered, to the last. I don’t even differentiate between ids or classes. I find having relative CSS codes next to each other a big help when it comes to debugging.

So, am I doing something anti-productive? What do you follow? I wanna know…

Many of you may think that no one uses tables anymore, but you’ll be nicely surprised at the percentage of people that do. With that in mind, I have jotted down 5 random points of why people should switch to CSS.

1. Separation of content and design
   While using tables, quick fixes are never quick. You loathe editing that glaring spelling mistake, because for the love of life, you can’t find it amidst all the table, tr, and td tags! And God forbid you accidentally delete one of these!! All the design, painstakingly gotten together through Dreamweaver, is dud.
   With CSS, however, your content is cleanly separated from the content, and finding a mistake is as easy as reading the passages.
2. Semantics
   If you care one bit about semantics, you’ll stop using tables. Tables are meant to be used for tabular data. Period. blocks of text should be enclosed with the p tag.
   Ok, so the div tag isn’t the king of semantics, but it’s at least better than a table. div represents a block, be it text, images, dynamic content, or all three. Tables represents tabular data, not design.
3. All the cool kids use CSS
   You’re cool, right? You jive with the times, don’t you? Or, better yet, you’re ahead of your times! Let me assure you. All the cool kids use CSS now, and tables won’t return in the future too. We’re going to bury table based designs for good.
4. Power to the stylesheet!
   If you’ve ever used colored links, you’ve already harnessed the power of CSS. CSS is built from ground up to design beautiful sites. Tables aren’t. Once you realize the full potential of CSS, you’ll be shocked at why you didn’t use it from the beginning.
5. Help when you need it
   If you get in trouble trying to design a table laden site, chances are, you’ll become bald faster than you solve the problem. The case is shockingly different in CSS.
   People all around the globe are so happy with the capabilities of CSS that almost everyone chips in to help make newcomers’ time better. You’ll always get help with your problem. There are excellent forums for CSS such as Web Design-L and CSS-Discuss, which cater to newcomers and experts alike.

I will hopefully have more posts about these in the future. Meanwhile, practice CSS!

Ok, so we all know that * html won’t work in IE 7 anymore.
So, I was digging around, and came across this site. Apparently using *+html will have the same effect on IE 7 as * html does on IE 6.
Good to know.

While using the Phark method for background image replacement, you’ll notice that while the link is being clicked, an outline appears that stretches out of the screen towards the left. This makes it look as if something is broken when you click a link.
If this irritates you, don’t worry, there’s a very simple fix for this.
Just adding a simple outline: none to the anchor element of the tag to which phark is applied easily rectifies the outline by not displaying it.
This may come in handy to someone someday.

While reading the wonderful CSS Mastery book by Andy Budd, I came across the Gilder/Levin method for background image replacement.

What this method does is introduce an empty span before the text, and then adds the background to the span. Since the span is before the text, the background will be placed above the text, thus hiding the text and displaying a background image instead. I won’t go into the details of this method, which you can easily peruse elsewhere.

I’ve started using this method for several reasons. Recently, I used this method at a site, and added text-align: center attribute tothe enclosing h2 tag, and proceeded to code the span tag as usual. As I use Safari for first testing, I found no problems with the output. But when I fired up Firefox to test the site, I found, to my surprise that the background image started from the center of the enclosing h2. It was the same in Internet Explorer.
However, on setting the text-align attribute to left, all three browsers displayed the image from where it should have been.
You can view a simple test case I’ve cooked up in here.

I don’t have a conclusive theory for this, but what I think happens is that when an inline element is contained within a block element, and the block element has the text-align: center attribute to it, Firefox and IE center the inline element too. Safari, on the other hand, centers only the text within the element. I believe Safari has the right implementation on this one, but, I can’t be sure.