Because I work much faster than the speed of bureaucracy (particularly definition #3) and can’t seem to slow down at that pace, I find myself challenging myself to do new things that I’ve never done before—one, because I have the time to, and two, because I might as well learn something new, right?

So one of my most recent projects I decided that I was going to format the entire page with style sheets without the usage of tables, blank .gifs to act as spacers, etc. Now keep in mind that I’m from the old school of HTML (a raw coder to the core) and know all the tricks of creating complex layouts with nested tables, transparent images, etc—in the very least, moving to a stylesheet-driven layout will have a bit of a learning curve for me. And it has been.

Stylesheets, I’ve found, is not that different from any other language—er, rather, spoken language. Sure you’ve got the established, official language as deemed standard by the folks at the W3C. Whatever they determine as official, its pretty well recognized within the responsible web designers/developers that W3C means standard. Stick to it.

Now if we could just get the browsers to follow-suit.

Consider the browsers to be those rogue people groups that have branched off from the original language; and while they do recognize the bulk of what makes up the language of CSS, they’ve taken a few liberties and have created their own dialect. Even worse, some have taken that dialect furthur and have discarded some words (styles) from their vocabulary altogether. *cough* Macro$uck *cough*.

But Macro$uck isn’t the only guilty party. While it’s not a widespread problem, the developer community behind Mozilla/Firefox have taken a few liberties with styles. One attribute that I know of specifically is the height attribute. As stated in an earlier blogging, the W3C only recognizes a specific pixel value for the height tag and does NOT support a percentage value. Firefox/Mozilla has taken some liberties and actually does support a percentage value for the height tag.

Now that’s not a gross offense by any means and doesn’t tarnish my perspective (much) of the browser that I’ve come to love and adore. But it does raise an eyebrow as to why they’d take such a liberty, even as small as it may be. Again, I don’t mind them taking that particular liberty—makes my job a bit easier. Sort of.

And then finally I’ve got a few questions for the W3C committee—those who determine what the standards are. Why have you voted against the usage of a percentage value for the height tag. I know its such a petty thing to be concerned about, but by having a percentage value, it increases the developmental possibilities for us designers who often times have more complex layouts to work with.

While I’m on this discussion of the height tag—Macro$uck has me really ticked off. What they deem as height is determined differently in other browsers. They determine the height value as being the actual height of the content area, not the actual height of the browser inner window. So if I specify height: 100%, Microsoft interprets that as 100% of the content that exists—in other words, it doesn’t do anything.

I would love for Mozilla to take back the web and become the standard browser of choice on all platforms (*cough* wishful thinking *cough*), but until then we’re back to where we were in 1998-2000, designing and developing for two browsers—the reinstatement of the browser war.

That’s one reason why I’m not so inclined to get all gun-ho about laying everything out solely with stylesheets. While many attributes are supported by both browsers, there are some things that you just cannot count on when it comes to stylizing your content, namely content positioning, varying height values, and other more advanced formatting. What invariably happens is that you end up developing two stylesheets for two primary browsers—even three to four stylesheets if you’re really wanting to format for the Mac community as well.

Which brings me back to formatting with the <table> tag and its attributes. Some more complex layouts are more easily dealt with using tables than trying to duct tape (the Red Green school of web development) your layout together using some JavaScript and varying stylesheets to make things work. It’s just too much Mickey Mouse work when tables can do it right in both browsers and without all the hassle.

I understand the fundamentals—that tables are meant for displaying content or values in a tabular format (e.g., a spreadsheet) and that stylesheets are meant for controlling the visual appearance and formatting of that content. Dreamworld. The reality is that as long as we’ve got two, varying browsers at work, we have two very different standards to accommodate. (How backwards is that???)

The browser should accommodate the standards set by the W3C and the designers/developers who utilize those standards as set forth—not the other way around. Likewise, the W3C ought to consider some more flexible options in their standards, which would give designers and developers more freedom and power to accommodate more complex designs and layouts.

The North has spoken. ;^)

July 25, 2005, 9:38 am

Filed under: CSS, HTML, Uncategorized

Leave a Comment

You must be logged in to post a comment.