Who sets the standards?

Originally posted at: http://homepage.mac.com/faucon/Design/who_standards.html

After trying to re-design 3 websites using CSS-only layouts, I have had to re-think a few things about CSS, standards & web design.

Not so standard

Cascading Style Sheets (CSS) sound great on paper, a screen, or screen reader. That's the theory, anyway. I recently got excited again about web design when I started learning about the potential benefits of using CSS to format web pages. It all sounded great to me, until I tried my hand at fashioning a layout using CSS, and no tables.

I very quickly realized the limitations; CSS is supported differently by each and every different browser out there. So, I can design a layout that makes perfect sense according to the standards set down by the W3C, but some wonder-brat code-monkey at Microsoft decided to use a different box model, so the page will look completely different in Internet Explorer (IE) than intended. Or, a bug in Opera causes floated elements to behave strangely. Older browsers don't fully support even the complete set of CSS1 rules, so things get left out. I've seen Netscape 4 (NS4) garble a page that looks perfectly normal on Safari, and even older versions of IE crash when faced with perfectly standards-compliant CSS code.

Web designers have known about this issue for a long time, and have developed a few strategies to cope:

CSS hacks & workarounds

creatively spicing up the CSS code, exploiting one browser's bugs to solve another bug, resulting in the same layout in each browser. This approach requires a lot of testing - in each and every version of each and every browser - and targetting specific commands to each such browser to achieve the proper effect. I'm an amateur web designer, who also happens to be a graduate student! I don't have the time or resources for this!

Convincing people to actually follow the standards

lobbying the software developers to make standards-compliant browsers, and convincing users to upgrade to these standards-compliant browsers. The folks at the W3C and especially the Web Standards Project (WaSP) have done a great job of this.

The New Face of the Web

Many of the older browsers with poor CSS support are now used so infrequently that it has become relatively practical to simply shield these older browsers from CSS altogether; these browsers only ever get to see the raw HTML. Sure, the page looks boring, but at least you can read it. Any computer still running these older browsers most likely will never be able to upgrade anyway, and will eventually fall into disuse.

There are now some really great, standards-compliant browsers out now, such as any gecko-based browser (Mozilla, Netscape), and Apple's Safari (Apple always tries to do things better). Even IE has come a long way to being more standards-compliant. Although IE (Mac) was the first browser with 100% support for CSS 1, it fallen behind, and has not been updated in years. For instance, IE 6 still does not support:

• position: fixed
• width: auto
• child selectors (i.e. html>body)
• and it often requires widths to be specified explicitly, in order to draw border & backgrounds properly.

So, I usually end up designing a page that looks the way I want in Safari & Mozilla, and then testing in IE and adding IE-specific corrections just for that cursed browser. Microsoft (& Bill Gates) has become a plague upon sensible & intelligent computing design.

Normally, I have adopted the following strategy: I code to standards, and if a browser can't handle it without making a page illegible, it doesn't get to see the code (more on this later). I can quite easily prevent IE from ever seeing the CSS, even using valid statements, but I realized I couldn't afford to do that wholesale to all my CSS code.

The scourge that is Evil Internet Explorer (IE)

This is because IE is the single most popular browser on the internet. Last I checked (for 2003), IE 6 was used by at least 60% of people on the internet, with older versions totalling about the same. Over 95% of all browsers are some version of IE. About 5% of users are on Netscape or Mozilla, leaving a few miniscule slices for all other browsers. Many believe that having IE bundled with MS Windows is responsible for IE's domination. Netscape used to dominate, until IE came on the scene. Microsoft has been taken to court with allegations that this is an unfair business practice.

Mozilla (or Netscape), and Safari (for Mac OS X) are the most common alternatives, but there are other free ones out there - have a look for yourself. It certainly seems to me that most users out there are simply not aware that there are, often better, alternatives to what has been handed to them in a free package. Designers the world over seem to be catering to this lowest common denominator, because they feel they have to accomodate the hordes of ignorant IE users. I have tried to convince people to switch to a more-standards-compliant browser that uses less memory, runs faster, and isn't full of security bugs, and the response I typically get is "well, IE works fine, why should I bother to replace it?" The dramatic shortcomings and dangers of using IE are not apparent to most users, in part because designers work so hard to accomodate them (even if it means having to bend the standards that IE doesn't support.

In fact, I find that many "Internet-based Applications", including the Student information System at my University, does not support browsers other than IE. The older system didn't support any Mac browsers at all (despite being a relatively mac-friendly campus). The new one freezes, or doesn't work properly, unless it's running under IE (Mac/Win). I would have deleted IE on my mac, except for the fact that I may need it to access and use sites that require it.

We are still caught in a vicious cycle. We try to convince people to make better products. We try to convince people to use better alternatives, but after all that, the most common browser is now the least standards-compliant. So, we feel we have to support it. This only encourages users to remain complacent, and continue to use an inferior product.

Conclusion

So, who sets the standards? The W3C has done an amazing job of defining systems & methods for interoperability. The guys at the Web Standards Project are out there lobbying people to adopt these standards. But, if the single most-popular browser on the web doesn't support them, where are we? In "the real world", we are slaves to the popular user; it seems that the public masses define what is "standard" and used most often.

Ultimately, I suppose each web site needs to know it's own clients, and what they use. But, for us amateurs, we're stuck having to support a crappy, yet popular browser. Here's my plea to the internet community: stop using Internet Explorer! Microsoft has already announced there will be no new (free) versions for any platform. Please, let it die. Get a better browser. For the sake of a better internet.

Coping with poor CSS support and buggy browsers

Originally posted at: http://homepage.mac.com/faucon/Design/css_cope.html

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

@import url("stylesheet.css");

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):

• 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

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:

• Win IE 5 and lower
• Mac IE 4.01
• Mac IE 5

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:

• position: fixed
• width: auto (IE needs explicit width specified to draw many things properly)
• max-width: and min-width:
• child selectors; IE 6 Win does not support this CSS 2 rule.

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...

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.

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.

Related Links

• My New Favourite CSS Hack
• Hide CSS from Browsers
• CSS Hacks (quirksmode.org)
• Browsers, and how to deal with them

Layout: Tables or CSS?

Originally posted at: http://homepage.mac.com/faucon/Design/layout_choice.html

HTML purists (& the W3C) frown upon using html tables to achieve page layout & design. However, the layout power of a table has been exploited since the 1990's to create visually interesting page designs. CSS was supposed to free us from the inappropriate use of html for layout. But, CSS has it's limitations.

Comparison

This section added 2004-05-23 (May 23, 2004).

Tables and CSS are different. They are different tools, suited for different tasks. Learn to use them appropriately.

Tables	CSS
Intended to display tabular data. This could be data (experimental, computer, etc.), rigid forms, and any other information where the layout is part of the information, crucial to it's content and meaning.	Intended to apply style to (any) all elements in an HTML document. Style is independent of content.
Coded directly with other content of a document.	Many ways to attach & apply style sheets (separate file) to one, or several documents. Potentially allows users to choose from several alternate style sheets for the same page (the Mozilla browser already has this option). Makes it simpler to change the look / style / layout design of many documents on a site, just by changing the style sheets.
Design is distributed (redundantly) throughout all pages in the site. All the layout code from the table must be downloaded with each page, but only as much as is present within the document.	Site design could be potentially "front-loaded", where all the style sheets must be downloaded with the first page. However, once downloaded, style sheets are then cached, and don't need to be downloaded again for the rest of the pages on the site. Designers may wish to limit the style sheets required and downloaded for the first page of a site, thus allowing this important front page to load faster. If the user chooses to visit more pages in the site, the required style sheets can be downloaded when they are needed. Or, keep the style sheets short & simple, thus reducing overall file sizes needed to download.
Rigid layouts (relatively).	Fluid layout (much more fluid than tables).
User has no control over layout.	CSS negotiates with the user to decide how to apply a style sheet. The user always has the last say about how to display elements. An extreme case is a user's custom style sheet, ignoring any style sheet specified within the document. Designers may not like this, but it allows users with special needs to control how they access the content. e.g. larger fonts, or certain color combinations to enhance readability (custom line-lengths, etc.). This can ultimately allow the content to be more accessible.
Widely supported by almost any browser (even the older ones).	In practice, CSS is only supported by newer browsers, sometimes not fully, and each has its own bugs.
Many Techniques widely used and time-tested for over a decade.	Many creative techniques described, and tested, though usually complex. Continually developing. Forward-compatibility may be uncertain.
A practice started in the early days of graphical web design, tables are often exploited to create the layout of entire documents by placing content within the table structure. Complex layouts often require nesting tables within tables, or combinations of colspan and rowspan attributes.	Complex layouts sometimes require extra tags within the document, but these can have semantic value (e.g. dividing obvious sections of a document), but hot nearly as many tags as tables require.
Easy to understand the concepts (if you're used to working with tables). Nested tables & tags can be confusing and difficult to figure out.	Must learn syntax, box-model, etc. - but it's all explained in the standards, freely available from the W3C. Can be confusing, if you're used to working with tables, but some find it makes a lot of sense (once you get used to it). The most frustrating and time-consuming aspect is coping with all the browser bugs and varrying levels of support. The best advice I can give is that you can't design with CSS the same way you would using tables. You have to think more fluidly, and you can't expect your pages to have the exact same, pixel-perfect layout in all browsers.

From Tables to CSS; standard problems

Since the 1990's, web designers (professional, and amateur alike) have been using html tables & nesting tables inside tables to position graphical and content elements on a web page. How else could you have a 3-column text layout, and position bits of graphics around text?

Cascading Style Sheets (CSS) are supposed to allow us to do what html was intended for: separate content (html) from format (style). The standards intelligently designed by the W3C are elegant and powerful. Unfortunately, they were not truly standard when first written, as many browsers did not support the full CSS specification. For more info, see the WaSP for a slightly longer description of the problem with web "standards".

So, where does that leave the amateur web designer? I still need to make a page, and I have creative energy to channel into my page design. What should I use, tables or CSS? Well, I recognize the benefits of using CSS and have decided to switch over. I really like the power of the standard, and the benefits, so I have decided to use it. After many hours of frustration, I have developed an approach to limit the browser bugs I need to address. Older browsers may see my pages as boring, without any CSS layout, but at least they are readable. Such pages are also more accessible to screen readers and people using other special software to help overcome visual impairements, faster to download (without extra code & spacer graphics), and easier to maintain and manage content. For other benefits, see the W3C.

I think it's absurd (but understandable) that html elements like tables are more stable & widely supported than CSS layout tools. CSS may simply be too new to become well established in browsers, but a standard is necessary to make web design practical. Standards mean I don't have to test or write special workarounds for separate browsers that read the same code in different ways.

The W3C and html purists frown on using tables to achieve layout for an entire page. They were intended to display tabular data. I've read many articles online re-enforcing this notion, so I decided to abandon the table for page layout. Unfortunately, this has meant that it takes me significantly longer to design a page, because I have to test CSS code and sift through lots of code to fix bugs, and test on a few platforms. But, I end up with a very flexible design, and pages that are sematically and structurally sound (and valid!). However, I have often wondered if having a "valid" document & CSS is worth all the extra time, when it ultimately results in pages that are less exciting on older browsers, and all the extra time & frustration it takes.

I have committed to an approach of separate content from style, because I believe it makes more sense from the perspective of publishing documents for others to view. HTML (or XHTML, see the W3C for more info) and CSS are a powerful combination allowing the same content to be displayed in a dynamic fashion, in different media types. CSS negotiates between the designer's intent, and the needs of the user. For example, some users need larger text to read - CSS allows the user to override the designer's format to allow one that is more accessible to the user's needs. This is why the <font> tag is so dangerous in html; not only is it not a real html tag (it's an extension supported by many browsers), but it does not allow the user a say as to what the browser will do with it, unlike CSS. There is really no good reason to use the<font> tag, since CSS is a much better way to format text and is generally much better supported in this respect. On the other hand, layout is another story altogether!

The right tool for the job

The internet (specifically, the World Wide Web) has evolved to be quite different than what was originally envisioned. It has become a powerhouse of marketing and business enterprise. At least, in developed countries. Anyway, the point is that the internet is no longer simply a tool to post documents to read. It is used by companies to sell things, manage information, and run "internet applications". In this setting, it seems to me that content can not be easily separated from format. In many respects, the two are very much inter-dependent, such as from a marketing perspective, or when designing an internet application. In this case, it does make sense to me to use a table, or other html markup to rigidly structure the layout of a page. The layout and style of these pages need to be stable across many different platforms, or the content will be lost. In this setting, pages are no longer simply documents to be posted for others to read - they are locations where users can interact with the content. And the content includes the graphics, layout, and formatting of every pixel in the browser window.

Conclusion

My conclusion is that if you want to use the internet to sell things, or to create a visual environment that is stable across multiple platforms & user agents, using tables for layout makes a lot of sense. It just means people with visual problems may have problems getting your message. But, this is a relatively small sector of the market for most businesses, and there are other alternatives for accessibility. If you want interactivity, that's what flash is for (or other technologies). But, if you want to publish documents, the W3C standards model of XHTML & CSS is a powerful combination. Perhaps what this eludes to is a need for the world wide web technology itself to change into a structure that is more suitable to interaction among users, and between users and their content. But the task of designing the future of the internet I leave to the professionals, and the needs of the users. I pray that it is not dictated to us by Microsoft.

Related Links

• Tables My Ass
• An Objective Look at Table Based vs. CSS Based Design