first last

Learn Something New Every Day

Cascading Style Sheets are both a godsend and a pain in the membrane. I have used CSS since I began my "web design skills attainment quest" because this endeavor started not long ago. When designing in CSS, I virtually always put all style declarations in a linked file. Externally linked CSS files are in my opinion the greatest strength of the entire method. Being able to update thousands of pages template-style without doing a site-wide text replacement is astoundingly simple. Such simplicity not only sends chills down your spine, but I actually find formatting in CSS far easier than trying to screw around with various font tags and other ridiculous archaic methodologies.

I do not, however, find that CSS for positioning is always the best way to achieve perfect, unbreakable page layouts. I used to try to design everything using CSS and avoid putting a single table in my code. Sure, that is a nice ideal to attain and makes you sound smart, but some layouts prove nearly impossible to achieve using CSS alone.

W3C, World Wide Web Consortium

W3C's recommendations for how CSS is supposed to be implemented don't line up with how every single browser renders CSS. It is nice to sound smart and produce future-minded code, and I feel that I am fully capable of this. On the other hand, trying to uphold an ideal that simply does not work is no fun at all. I know nearly every CSS attribute out there and how they are supposed to function, but I still don't see any way to create certain column-based or "stretchy" layouts. For example, the layout you see on this blog as of today is using tables. That is because tables always work how I want them to! Creating absolutely positioned pages of a fixed width is extremely simple, but creating a layout with several stretching columns doesn't always work. Virtually every 2 or 3 column layout that doesn't use tables does some pretty weird stuff when you start resizing the browser window to a small width, or if you override the font size in your browser. Things jump all over the place, over and under each other, etc. I find this behavior totally unacceptable, and therefore I choose to continue to use tables whenever I want an unbreakable interface that is always 100% the width of the browser window. When all the major browsers successfully render CSS-P with perfect results, I'll go back to using CSS exclusively for all my layouts. Right now I use tables and CSS with synergy to produce pages that do exactly as I intend, and I'm not ashamed of it.

As the title of this blog entry suggests, I learned something about CSS today. I am hardly foolish enough to think I know everything there is to know. I am pretty confident that I know virtually every current CSS property and attribute, when to effectively use each, and when not to. But like I said, there are certain layouts I simply cannot create without losing a tiny bit of what I consider a perfect layout that cannot be ripped apart by standard use (mainly, resizing the window or changing font sizes). Because of this nonexclusive use of CSS I have started wondering if I really know enough about modern CSS (though all my knowledge is modern, since I started my web design quest less than a year ago).

Whenever I have these doubts about my CSS knowledge or ability, I usually do a Google search to see if others have found a solution to the problem or question I am encountering. Almost invariably, I see everyone expressing the same complaints that I have. In almost every case it is a browser rendering flaw, and there is no currently known solution without severe, dumb workaround.

Well, anyway, I decided to read the official CSS1 recommendation today and found a couple minor points I had either known before and since neglected or I simply didn't know.

  1. You can follow any CSS property declaration with ! important to increase the weight of the preceding declaration. I was not aware of this, but I don't think I have encountered an instance where it was necessary because I rarely need to have duplicate declarations where their weights would come into effect. I like to be very specific and structured in my declarations.
  2. P:first-line and p:first-letter properties: These pseudo-elements effect the first line of a wrapping block element and the first letter. I have known of these properties for a long time but had intentionally forgotten them. Someone told me they were one of those things that not all browsers support properly, so they are not worth trying. While such might be the case, I tested them in IE6 and Firefox with success. So you will notice their use in my blog entries. You might be thinking I used them "because I could". Nope, I try to never implement something unless it is value-adding. I like the new look.
  3. Line-height as padding: One of my frustrations with CSS has been the task of creating a perfect horizontal menu. Here's the problems: If you use the float:left approach, you need a container for them to fit in, otherwise they break apart when you resize the browser window (and you can't center something that is floating left). If you are trying to work with elements that have display:inline specified, you have a hard time forcing a specific height for the menu because vertical padding does not effect inline elements. Ah, but with with line-height, you can specify an exact height, and by definition (leading and half-leading), the text is centered in this newly created box. Woo hoo! The menus on the top of this site use this technique, and I am rid of one less table.

I actually felt pretty good after reading the CSS1 recommendation because these were the only three things I wasn't taking advantage of. Next I'll read the full W3C CSS2 recommendation and see if I learn anything new. That should be a little bit more exciting, and I expect to learn a thing or two.

Visit W3C, authors and maintainers of all those fun recommendations

first last