jonathan stegall

I want to continue with my thoughts on creating and maintaining CSS on very large websites. In my last post on the subject, I mentioned that there are at least ten different layout conventions that I deal with on a regular basis.

For what it’s worth, I want to add a little context and say that those layout conventions (and ten is a rough estimate) power somewhere around four hundred pages, give or take a few. Certainly, the website is much larger than that number, but again those are the ones with which I have significant interaction.

Again, none of this is new to someone who works on a very large website, but all of it was new to me. In light of this, I want to shed a little more light on some of the techniques I use or have used.

Structured Sections of Styles

I began to practice this technique when most of my days were spent working with relatively small sites, that typically had a total page number of less than fifty. However, many stylesheets don’t do this, so I think it’s worth mentioning.

Structuring sections of styles allows the designer to keep things in logical places within the stylesheet: such as layout styles, link styles, typography, browser fixes, and so on. An example goes like this:

HTML:

<div id="wrapper" class="layout-a">
   <div id="subContent">
      <p>content</p>
   </div>
   <div id="mainContent">
      <p>content</p>
   </div>
</div>

<div id="wrapper" class="layout-b">
   <div id="subContent">
      <p>content</p>
   </div>
   <div id="mainContent">
      <p>content</p>
   </div>
</div>

CSS:

body {
   background: #fff;
   font-size: 76%;
   text-align: center;
}
/* Layout Styles
_____________________________________________________ */
/* constants */
#wrapper {
   width: 760px;
   margin: 0 auto;
   text-align: left;
   font: 1em normal Verdana, Arial, Helvetica, sans-serif;
}
/* end constants */
/* layout-a */
.layout-a #subContent {
   width: 260px;
   float: left;
}
.layout-a #mainContent {
   width: 400px;
   float: right;
}
/* end layout-a */
/* layout-b */
.layout-b #mainContent {
   width: 400px;
   float: left;
}
.layout-b #subContent {
   width: 260px;
   float: right;
}
/* end layout-b */

/* Link Styles
_____________________________________________________ */
/* constants */
a:link, a:visited {
   color: #f00;
   text-decoration: underline;
}
a:hover, a:focus, a:active {
   color: f00;
   text-decoration: none;
}
...

Thus, styles become very nicely organized and can easily be found by another designer, or a developer, or someone learning from your source code.

Multiple stylesheets

Most large websites already do this, but it is important to mention that multiple stylesheets are an amazing organizational tool, beyond (but not replacing) the need to structure the stylesheets themselves.

Example:

<link rel="stylesheet" href="reset.css" type="text/css"
media="screen, projection" />
<link rel="stylesheet" href="site.css"> type="text/css"
media="screen, projection" />
<link rel="stylesheet" href="businessUnit.css"
type="text/css" media="screen, projection" />

For myself, I use Eric Meyer’s great reset stylesheet to remove default browser styles (as well as, in my case, default styles from the CMS that conflict with my needs). There are several others around the internet. Use whatever fits.

In my situation, several different business units have very different styles for their respective sections of the website. So, its beneficial to add these in separately when they do not overlap. Often, each business unit has several different layout conventions, hence the use of layout-a and layout-b, and so on.

Calm down

Unfortunately, most large websites do not validate, neither in their HTML or their CSS. This can be a constant source of frustration for standards-aware designers and developers. Multiple people may maintain the code. Some of them may be serious back-end programmers who don’t care about what the browser actually receives at all. Others may be non-technology people who barely know what a browser is, but have the responsibility of maintaining code for one reason or another.

And that has to become okay, at least to an extent. Otherwise, jobs become depressing. Certainly, work for better support of web standards. Push the fact that even the IE team wants to support standards. Push for accessibility, and the fact that major websites are being sued for accessibility violations. These things are important.

But every once in a while, take a flight for a few hours. Rejoice in the fact that, at least for now, people can’t call your cell phone and tell you that the world is ending, and expect you to do something about it. They’ll have to wait till you land.

I could see this becoming a series of posts, but for now I’ll start with one. I spend my days, to a large extent, dealing with HTML and CSS on a very large website.

I used to spend the majority of my days dealing with XHTML and CSS in relatively small websites. Rather than having, say, four or five different layout conventions, I now deal with at least ten different layout conventions. There are sections of the site that are of varying ages, and sections that were designed at different times and by different people in the company’s history. Any very large website is likely to have these kind of issues.

One of the results of this shift in my work situation is that I now have very large stylesheets. While there is a large amount of re-used code, re-used styles, and so on, there is so much going on that it is difficult to have efficiency.

There are a number of CSS frameworks that have come out in recent years, from YUI to Blueprint to others. This trend is similar to the trend of JavaScript libraries, of course, and it is seen as both a good thing and a bad thing, depending on how it is used.

One of the things that I have lately begun to make use of, though, is the YUI convention of creating several different layouts based on one selector. Thus, we might have the following:

<div id="wrapper" class="layout-a">
   <div id="subContent">
      <p>content</p>
   </div>
   <div id="mainContent">
      <p>content</p>
   </div>
</div>

<div id="wrapper" class="layout-b">
   <div id="subContent">
      <p>content</p>
   </div>
   <div id="mainContent">
      <p>content</p>
   </div>
</div>

The benefit of this is that layout-a and layout-b can share an identical structure in their HTML, and be styled to match almost any layout convention with less code and more efficiency than, for example, creating different divs for all of the sections.

Any styles that are shared between the layouts are, of course, shared. They don’t have to target layout-a or layout-b. As I begin to implement this, I find code becoming more efficient and I feel that it would be much easier for someone else to come along and have to deal with it.

When I first began working on this type of site, I was very good at HTML and CSS, but apparently I was not very efficient. This degree of efficiency simply wasn’t necessary, although it certainly could have been beneficial. I post all this because I have a feeling that I’m not the only one who could benefit from this kind of thought shift.

As I’ve been thinking about the new default behavior that Microsoft announced for IE8, it occurs to me that there are a lot of reasons for Microsoft’s decision. In light of these thoughts, I want to look at the reasons that I think are likely possibilities.

Standards as a whole

Microsoft, especially in the last year or two, has made a lot of moves toward standards, web and otherwise. They announced the Interoperability Principles. They announced the ASP.NET MVC Framework, which finally allows programmers to control the HTML generated by ASP.NET. IE8 will pass Acid2, and any number of other things.

While I’m not optimistic that any of this will cause Microsoft to act in any unexpected ways with respect to its attempts to acquire Yahoo, it is clear that a shift is occurring, to whatever extent.

Noise from the web standards community

Advocates of web standards have made a lot of noise about the original decision, and it is clear that Microsoft listened. Many people made logical arguments for why IE8, especially from a long-term perspective, should not default to IE7 behavior, while understanding that the option for IE7 behavior was a good thing.

Legal issues

It’s entirely possible that this is partly related to Microsoft’s various legal troubles, and that they are trying to appear as a better business citizen to help their case.

Future versions of IE

I think one of the most significant benefits, both from the perspective of future versions of IE, as well as future versions of Firefox, Opera, Safari, etc., is that the need for version targeting will probably become much less because IE8 is the default behavior. People who create sites that break in IE8 will, certainly, have the option of targeting IE7, but in order to do that they’ll have to learn that they can.

Most people who will run into the issue will probably not have the interest (or the time, possibly) to find out this kind of solution. The ones who do find out about the solution will find out that Microsoft doesn’t see it as the ideal solution, and will probably feel at least some pressure to learn proper ways of doing things. Thus, in a few years, it is entirely possible that versions of Internet Explorer that follow version 8 will be met with a majority of sites that do not break.

That’s not to say that the majority of sites will follow web standards. I’ve seen innumerable websites that didn’t break when IE7 came out, because they had such disregard for web standards that none of the changes affected them. I suspect we’ll have to deal with this for a long time. But that’s fine with me, as the future of web browsers can continue to look forward.

See this press release:

“IE8 has been significantly enhanced, and was designed with great support for current Internet standards. This is evidenced by the fact that even in its first beta, IE8 correctly renders the popular test known as ‘Acid2,’ which was created by the Web community to promote real-world interoperability,” said Ray Ozzie, Microsoft chief software architect. “Our initial plan had been to use IE7-compatible behavior as the default setting for IE8, to minimize potential impact on the world’s existing Web sites. We have now decided to make our most current standards-based mode the default in IE8.”

The web standards world has been abuzz for the last few weeks, following the announcement that Internet Explorer 8 (and, presumably, any number of future releases) would have the default behavior of rendering websites in the same way that Internet Explorer 7 does. Causing the browser’s behavior to advance would have required that designers and developers direct it to do so with a meta tag.

Many standards-aware designers and developers were very understanding of the decision to allow websites to target IE7, avoiding issues with badly-programmed websites that break when browsers move forward. However, many of these designers and developers made a lot of noise wishing that Microsoft would allow the default behavior of websites to advance as the browser does, and require those who want to target IE7 to read a little bit and find out about the meta tag.

Apparently, Microsoft listened to the noise. I’m amazed and pleased by this change in strategy. I hope they will be able to spread the word enough, so that websites that will break with IE8’s improved standards support will learn about their options (1. learn how to write standards-compliant code, 2. include a one-line meta tag). I feel pretty confident that this is unrealistic, but I hope that it will happen to the extent that Microsoft doesn’t have to go back on this decision.

I don’t write about CSS as much as I’d like to. I spend a lot of time working with them on an advanced level, however, both in my day job and in any side projects.

I spent a few minutes looking around on Google for issues that arise when designers need to work with and use CSS within the confines of a CMS that does not allow access to things inside the head of the document. Apparently, this is not a rare issue, so I’d like to post a few solutions that, while they are not ideal, do work.

Disclaimer: these options do not validate. The only valid way to include a CSS is inside the head of the document

Option One

Use inline styles. This method is, unfortunately, still the most common way of doing this. A designer might have the following code in place:

<div id="myDiv" class="myClass">
<p>foo. I'm a div with an ID and a class, but my ID
and class don't do what I want them to do.
Bah.</p>
</div>

If the div is, for example, defined with its ID or class as a very small div floated to the right, but it needs to be a very large div floated to the left, a designer might do this:

<div style="float: left; width: 500px; margin: 5px;">
<p>foo. I'm a div without an ID and class, and I have
ugly inline styles.</p>
</div>

Option 2

Option 2 allows the designer to access the head of the document through JavaScript. There are a number of techniques for doing this, but they have significant issues.

Mainly, this breaks the separation between content, style, and behavior that provides much of the underlying theory of why a designer would want to use CSS in the first place. In addition to this, it breaks the accessibility of the page. Anything that doesn’t have to be done with JavaScript, shouldn’t be done with JavaScript.

Option 3

This is the option I spend a lot of time using when working in this situation. A designer might have the following scenario:

<head>
<link href="a stylesheet I cannot access"
rel="stylesheet" type="text/css"
media="screen" />
</head>
<body>
<div id="myDiv">
<p>foo. I'm a div that needs some styles. I might be on
thousands of pages across this site.</p>
</div>
</body>

<head>
<link href="a stylesheet I cannot access"
rel="stylesheet" type="text/css"
media="screen" />
</head>
<body>
<link href="mycss.css" rel="stylesheet"
type="text/css" media="screen" />
<div id="myDiv">
<p>foo. I'm a div that has styles, even though
they're not where they should be. I might be on
thousands of pages across this site.</p>
</div>
</body>

The benefit of this is that it works in all major browsers and on all major platforms and, at least, mobile devices (this statement counts Linux and the iPhone as major platforms, for what it’s worth). Also, of course, there is the benefit that the given stylesheet can be called throughout the site, which inline styles do not allow.

There are a few downsides to this technique. Browsers, for one, have to work a bit harder to do this kind of thing. When they encounter style information outside the head, whether it’s in an external file or in the page, they have to break their normal flow of rendering content, and thus this causes pages to be slower. This slowdown, however, is not usually noticeable.

Of course, because browsers have to work harder to do this, and because it does not validate, it is possible (though it is highly unlikely) that future versions may not support this kind of functionality.

From the Internet Explorer team blog:

…I’m delighted to tell you that on Wednesday, December 12, Internet Explorer correctly rendered the Acid2 page in IE8 standards mode. While supporting the features tested in Acid2 is important for many reasons, it is just one of several milestones for the interoperability, standards compliance, and backwards compatibility that we’re committed to for this release. We will blog more on these topics.

Wonderful news. Web designers and developers everywhere agree with me that IE6 is the bane of our existence. There’s no need to discuss this further. IE7 is a massive improvement, and in general I’m pleased with the direction that the team seems to be taking for the future.

Acid2 compliance is, for me, an unexpected leap forward. Currently, Opera and Safari are the most widely used browsers that have achieved this milestone. Firefox 2.x does not reach this level, although Firefox 3 (which is in beta and, I’m sure, will be released well before IE 8 is) does.