2004-08-12 (Thursday, August 12, 2004)
Another Update
I've had a slight change of heart, and I'm still experimenting. I now have a new approach to coping with CSS bugs. Same strategy, different methods.
2004-08-11 (Wednesday, August 11, 2004)
Update
I have become rather fond of my new favourite CSS Hack, which I have gotten into the habit of using instead of the second method described in this article.
2004-05-18 (Tuesday, May 18, 2004)
CSS is supposed to be very elegant tool for achieving flexible layouts of sensibly-marked HTML pages. But, not all browsers support CSS to the same degree, or even in the same way. And then there are the various bugs, etc. What's an amateur web designer to do?
The power of CSS, and it's limitations
I have had an interest in web design re-awakened. To be honest, the main reason for this was the re-discovery of Cascading Style Sheets CSS. I decided to learn more about this tool from the World Wide Web Consortium (W3C), and discovered the real power of CSS:
- using a single file to describe the layout for many pages on a single site.
- this makes entire site re-designs much simpler & efficient.
- allows pages to be less cluttered with spacer graphics & extra table code, nested tables, etc.
- can also decrease download time because of this!
The idea is to separate content from format. You have a page with the content, marked up to apply semantic structure, and the CSS makes it look the way you want. I find this makes editing in the HTML file much easier, because I don't have to wade through nested tables, etc. If you use XHTML (Extensible Hypertext Markup Language), the same document (content) can be used and displayed completely differently on the screen, on paper, or through another XML-based reader. The possibilities for document publishing are seemingly limitless.
This model makes a lot of sense for formatting a lot of content. However, internet-pages have become more and more visually-based. The content & format have become merged in many cases, or dependent on each other. This makes sense to me from a marketing perspective; form & content are inseparable. But, if you want to publish documents, the W3C model of XHTML & CSS is a powerful combination.
I found some problems when I tried to apply this model. The most important is the fact that seemingly every browser out there supports CSS to different degrees, and even in different ways. IE's infamous incorrect box model, and other browser bugs and quirks, have spawned the need for several hacks & workarounds. As an amateur web designer, I don't have time to test for every single possible browser and how it's going to butcher my valid, standards-compliant code.
Fortunately, the good people at the Web Standards Project (WaSP) work tirelessly with software developers and users, to encourage everyone to adopt and support the standards. This has led to some important changes toward the end of the last century, including much better support for standards, including CSS, XHTML, and many others, I am sure. Plus, users have been convinced to upgrade to these improved standards-compliant browsers, whenever possible, so designers can start designing to standards.
Unfortunately, browser bugs, and older versions have not been completely eliminated. Older computers may never be able to upgrade to the newer browsers. And then there's Microsoft Internet Explorer - the bane of all web designers. This is currently (2003-2004) the single most popular browser in use. But Microsoft has even admitted to no longer developing it as a stand-alone product. It has fallen behind in support of standards. It is also full of security problems, so I would highly recommend finding an alternative if you are still using IE. I suggest a few on my links page.
Coping with the bugs
In order to cope with the perilous sea of buggy browsers, I have adopted the following strategy: I code to standards, and I only show it to browsers that can handle it properly.
There are an overwhelming number of CSS hacks & worksrounds out there. I only use two (2), although the first is really a combination of 2 other hacks I've seen out there.
- 1. modified @import statement.
- I use a basic stylesheet for textual formatting - hopefully nothing that it not almost universally supported. This is
linked to the html document in the header. All the layout, etc. goes into a separate style sheet that is imported into the
basic style sheet. This hides the layout from many older browsers, including the notable Netscape 4. The following statement
is perfectly valid, according to CSS level 1, but the following browsers can't understand it, and ignore it, thus never loading the imported stylesheet (according to w3development.de):
@import url("stylesheet.css"); - Netscape 4.x
- Win IE 3
- Win IE 4 (not 4.72)
- Mac IE 4.01
- Mac IE 4.5
- Konqueror 2.1.2
- Win Amaya 5.1
- Win IE 5 and lower
- Mac IE 4.01
- Mac IE 5
position: fixedwidth: auto(IE needs explicit width specified to draw many things properly)max-width:andmin-width:- child selectors; IE 6 Win does not support this CSS 2 rule.
- 2. Child selector (for IE 6 Win)
- I first design a layout that works on Safari & Mozilla. I then test in IE 6 Win, and fix the problems. For example, where I had width: auto, I replace with a specified width. I then add a duplicate selector statement that starts with html>body, and feed the correct (intended) values to CSS2-compliant browsers.
However, this won't hide the Style Sheet from IE 4.72 - which I've seen crash when fed perfectly valid CSS level 2, or other code it doesn't understand. So, I add a comment immediately after the @import declaration, but before the url statement:
@import/* */ url("stylesheet.css");
This comment hack was originally intended to go immediately after a selector (see w3development.de), but I've found that it also works here. This also confuses and thus hides the import statement for the following browsers:
The idea is that all these older & buggy browsers will not load the layout CSS code. They will still display the document. And it may look plain, but at least it's readable, and the browser doesn't crash! Theoretically, only version 6 browsers or higher will be able to see the layout CSS code. All of the these that I know of are very standards-compiant and don't garble the page. I have tested this for Safari & Mozilla (Mac OS X) and IE 6 Win, but I presume it works for others (let me know if you know otherwise). This is also validated by the W3C.
The one major drawback is that IE 6 Win still sees the code, and it is still not terribly standards compliant. It has some problems with the following:
I could exclude IE 6 Win from seeing the imported sheet, by adding a media rule.
@import/* */ url("stylesheet.css") screen;
/* This also hides the style sheet from other browsers
that do not support this CSS level 2 statement */
However, I felt I needed to support some version of Internet Explorer because it is sadly the single most popular browser in use (over 60% in 2003).
By the way, if you are still using Internet Explorer, please consider an alternative.
When necessary, I employ a workaround that exploits a parsing bug in IE 6 Win to help me write code that it understands...
For example:
p { width: auto; }
would become:
p { width: 640px; } /* IE6w */
html> body p { width: auto } /* correct values, hidden from IE 6 Win by the child selector */
The body tag is always a child (immediate descendent) of the html tag, so this always applies.
Anything else is contained within the body (descendants of body), so this is always valid.
The Tantek Hack, refined in the Simplified Box Model Hack (or Tan Hack) is often used as a similar work around to target code specific for IE 5.x/Win, but I find that it is irritatingly complex, and I don't have time to figure out the 3 different values you need to feed to 3 different types of browsers. Plus, I've already excluded IE 5 from even seeing the CSS code with the first @import statement, so who cares?
All this trouble, to achieve complex layouts that are stable across different browsers. Actually, I end up with 2 distinct layouts: one that use the standards, and is flexible, according to what I envisioned. And then an inferior one for IE 6 Win that works, but is not as elegant. There are other approaches described on the internet, such as nesting div's & such in the html to achieve a visual layout separate from the "content" (text), but in my mind this is counter-productive, since it goes against the whole point of using CSS! The layout becomes dependent on a bunch of extra div tags that are there solely for layout purposes. Granted, they are much more flexible and take up less space than the table mark-up, but it still bugs me. I admit that I sometimes wrap things in a few div's to allow for more complex layout schemes, but they always make semantic sense; to contain content separately from an index, footer, or title banner, and so forth.
Conclusion
So, this approach allows a well-structured HTML, or XHTML document to be displayed in a potentially graphically and visually interesting way. But, only on newer browsers, because I don't have the time to craft special code to accommodate every browser bug in existence. I have chosen to fight the few battles worth fighting.
No comments:
Post a Comment