Remember my recently posted conversation with Molly?  Boy, am I ever feelin’ that today.  In spades.

Some of you have noticed earlier today that things were presentationally unstable.  Depending on when you dropped by, you would have seen raw document presentation with no author styles at all, or some chunks of the site’s usual styles but not others, or all of the usual styles with a few oddities thrown on top for good measure.  For a few hours, during which I had to attend to something else, the site was fine except that in IE/Win, the main content column was quite a bit wider than usual, and some bits of content were visually exceeding the edges of the design box.  All that was happening because I was turning styles on and off in an attempt to stop freezing Internet Explorer for Windows.

Freezing?  Oh, yes.  As in locking it up so that people had to use the Task Manager to force-quit the process.  There were probably a few reboots out there as well; there were at least a couple here in Casa de Meyer.  Ordinarily, I’d apologize.  Not this time.  If you want an apology, try finding the person or persons responsible for IE’s CSS handling, and demand an apology from them.  I’m not taking the rap for this.

To set the stage, let me back up a couple of days.  As I passed by Kat’s office, she called out, “Hey, how come my browser keeps getting screwed up?”

“Because it’s Explorer,” I said.  “Next question?”

“Ha ha.  Seriously, every time I try to view your ‘ten things to do in Cleveland‘ post, the computer crashes.  I think there’s something wrong with it.”

Grumbling, I wandered over to her computer.  Sure enough, the browser was completely frozen.  She’d already called up the Task Manager and was forcing the browser to quit.  She said it was the third time she’d had to do it.  As I watched, the screen went blank, then drew the desktop color and stopped.  The cursor appeared as an hourglass, and refused to change or even move.

Once the system had gone through a hard reboot, I fired up Netscape 7 and loaded up meyerweb.  I surfed around to various posts.  No problems at all.  I then launched IE and loaded up the home page.  No problem.  I went to the offending post.  Instant freeze.

After a few more invocations of the Fatal Freeze, I wandered out of her office again, muttering about Explorer and Windows and pondering the possibility that her computer had been infected with some kind of virus, malware, or other nastiness.  But then, the next day, I got some e-mail reporting similar problems.  Then Ian Firth managed to get a comment in about the problem on the post “Really Undoing html.css“, even though others were getting the Fatal Freeze on that very post.  And he mentioned that it was happening in both IE and FeedDemon—which meant it was something in IE’s rendering engine, since FeedDemon just wraps itself around the engine.  A similar report cropped up in the FeedDemon forums this morning, where it was mentioned that a similar problem had already been seen in the post “Standards Savings“.  (Not that anybody had actually bothered to tell me, but hey, whatever.)

So I fired up VirtualPC this morning and tested the problem for myself.  And sure enough, I was very quickly the latest resident of Lockup City.  So I started narrowing down the cause.  I’ll spare you all the nasty details (and foul language) of my bug hunt, and cut to the chase: the lockup was happening on entry pages where the post content included an element that used left padding.  Blockquotes and lists were the prime triggers.  There wasn’t an absolute 100% guarantee of trouble, but it was close.  I could avoid the freeze by commenting out a single declaration in my main style sheet:

#main {
  margin: 0 15em 0 0;
  /* padding: 3em 4em 3em 4em; */
  border-right: 1px solid #AAA;
  background: #FFF;
  min-height: 30em;
}

That’s why the content was running rampant earlier today.  I had to leave that line commented out for a few hours.  But I knew that couldn’t be the real cause, because it didn’t cause freezes on the home page, or even on monthly or daily archive pages.  The freeze only happened on an individual entry page where there was a padding-indented element inside the content column.  Thus, the source was most likely to lie in style sheet that’s applied only to post pages.

So I started digging through my entry style sheet until I narrowed the problem down to this line:

.prev-next {margin: 0; padding: 0.25em 1% 0; 
  float: left; width: 98%;}

If I commented it out, and uncommented the padding declaration from before, there were no problems.  So the culprit lay somewhere in the .prev-next rule.  Anyone want to guess at the cause?  Go ahead.

Oh, all right, I’ll tell you.  It was float: left;.  As soon as I removed that declaration, the IE6 freezing problem just melted away.  So if you’ve encountered freezes while trying to view entry pages in the past, you shouldn’t any more.  (If you do, please comment on this entry with the exact browser and OS you’re using.)

The original point of the float statement was to get the unordered list to wrap around the floated list items within it, since floated elements wrap around floated descendants (for more details, see my article “Containing Floats“).  Since that was apparently a recipe for disaster, I modified the rule to read:

.prev-next {margin: 0; padding: 0.25em 1% 0; 
  width: 98%; height: 1em;}

It isn’t exactly the same as what I was doing before, but the result is close enough for now.

What else might I have done?  Well, in all honesty, I thought seriously about leaving things status quo and letting IE users go hang.  I don’t cater to potential crash bugs in NN4, for example; why should I make an exception for another browser?  But as I always knew I would, I grumbled a bit and then made an accommodation for IE.  I may one day restore the float for more modern browsers and use some sort of hack to hide it from IE/Win, but for now I’ll leave things be.

What’s odd to me is that the styles involved in triggering this problem have been in place literally for months.  If this was a problem, it should have arisen before now.  Yet the first I heard of this freeze bug was two days ago, and then all of a sudden I was hearing about it from multiple sources.  If I’d been updating my CSS, that would be understandable, but I wasn’t.  So what happened?  Did the installed Explorer population just get spontaneously and collectively buggier over the weekend, or what?  Is there a subtle worm running around adding bugs to IE’s rendering engine?  I’m really at a loss here.

As to why that particular combination of styles would cause IE to freeze up, I’m completely at a loss.  Not a clue in the world.

While I was mucking around in the CSS anyway, I decided to see if I could fix the rendering error in IE/Win that made the sidebar hang out over the vertical separator.  I did, so far as I can tell.  The problem there was the “Exploration” box and the styles I’d applied to it.  Apparently, if you set a form element to width: 95%; margin-left 5%; and then set a text input within that form to width: 100%;, it all adds up to something like 120%, or something.  So I did a little bit of a hack to hide the input element’s width value from IE/Win.  The input box won’t be as wide for IE/Win users, but as far as I’m concerned that’s an acceptable loss.

I hope your morning was substantially less frustrating than mine.

• When Browsers Attack! was published on Thursday, September 16th, 2004.
• It was assigned to the Browsers and CSS categories.
• There have been fifty-four replies.

There’s an aspect of document presentation most of us don’t consider: the browser defaults.  If you take an HTML or XHTML document—for the purposes of this exercise, assume it contains no presentational markup—and load it up in a Web browser with no CSS applied, there will still be some presentational effects.  A level-one heading, for example, is usually boldfaced and a good deal larger than other text, thus leading to the old stereotype of headings being “big and ugly”; the pre element typically honors whitespace and uses a monospace font; a paragraph is separated from other elements by a “blank line”; and so on.  From a CSS point of view, all this happens because the browser has built-in styles.

Tantek recently wrote about his creation of a file called undohtml.css, whose sole purpose is to strip away some of the default browser styles applied to common elements.  By resetting all headings to the same size, for example, he avoids the inconsistencies of heading sizes across browsers and brings everything to a common baseline.  If a different size is desired, the author has to do it manually.  (He should probably zero out the margins on headings as well, as those too tend to be inconsistent across browsers.)  He also zeroes out their margins, using a separate rule that I overlooked when I first posted.  Apologies to Tantek for my initial claim that he didn’t take that step.

Of course, Tantek isn’t really removing all the default styles, but (so far) just those that have given him the most trouble.  When it comes to Gecko-based browsers like Firefox and Mozilla, however, you can completely eliminate all built-in styles.  These browsers use a series of style sheets to control the presentation of documents, forms, MathML markup, and so on.  In OS X, you can find most of these style sheets by showing the package contents of the browser’s application file and navigating to Contents > MacOS > res.  On just about any other OS, it’s even easier; just search your hard drive for html.css and open the directory that contains that file.

If you look in html.css, you’ll find all of the styles that make what we think of as “unstyled” documents act the way they do.  Consider, for example:

area, base, basefont, head, meta, script, style, title,
noembed, noscript, param {
   display: none;
}

That rule is why the head element and all its contents don’t appear in your browser (as well as all those other “invisible” elements).  From a CSS standpoint, there’s nothing special about those elements as compared to others like div or ul.  The fact that they’re traditionally “invisible” is irrelevant—but with that one rule, the tradition is preserved.  You can always override the rule, of course; try style {display: block;} on a test document that contains an embedded style sheet and load it up in Firefox/Mozilla.  It isn’t magic.  It’s just a change from the usual way that documents are presented.  (See this test document for an example.)

There’s also:

/* nested lists have no top/bottom margins */
ul ul,   ul ol,   ul dir,   ul menu,   ul dl,
ol ul,   ol ol,   ol dir,   ol menu,   ol dl,
dir ul,  dir ol,  dir dir,  dir menu,  dir dl,
menu ul, menu ol, menu dir, menu menu, menu dl,
dl ul,   dl ol,   dl dir,   dl menu,   dl dl {
  margin-top: 0;
  margin-bottom: 0;
}

So in order to remove the top and bottom margins from nested lists, which is a traditional behavior of HTML browsers, that rule needs to be in the default style sheet.  Remove it, and nested lists would have top and bottom margins thanks to another rule in the style sheet:

ul, menu, dir {
  display: block;
  list-style-type: disc;
  margin: 1em 0;
  -moz-padding-start: 40px;
  -moz-counter-reset: -html-counter 0;
}

That rule not only sets the usual margins and such, but also includes some Mozilla-proprietary properties that help lists act in accordance with our expectations.  There are certain aspects of traditional presentation that aren’t (yet) fully describable using CSS, so the Mozilla folks have had to add properties.  In accordance with CSS2.1, section 4.1.2, these proprietary extensions are marked with a vendor prefix; here, it’s -moz-.  So any property or value you see starting with that string is a proprietary extension.  (For the record, I have no objection to extensions so long as they’re clearly marked as such; it’s the “silent” extensions that bug me.)

There is more to the presentation story than just html.css.  In the same directory, you can find quirk.css, which is applied instead of html.css when the browser is in “quirks” mode.  Another style sheet, viewsource.css, affects the presentation of any view source window.  All the nifty color-coding happens as a result of that style sheet, which is applied to automatically-generated markup that underlies the actual source you see.

So how do you completely strip out the default styles for an (X)HTML document?  Quit the browser application and rename the file html.css to something like html222.css.  Do the same for quirk.css.  Now re-launch the browser and find out just how much you’ve been taking for granted.  Feel free to browse around the Web and see what happens on various sites, but you’ll have to type blind, because the address bar won’t show any text.  You can still drag HTML documents on your hard drive into the window and see what happens.  If a document has any CSS applied to it, then the browser will use it.  It just won’t have any of the default styles available, so you’ll be applying your styles on top of nothing, instead of the usual foundation of expected presentation.

So what exactly is the point of all this?  As it turns out, I believe there are four:

1. By studying html.css, beginning CSS users can compare the rules to the “unstyled” presentation of documents, and thus get a much better idea of how CSS works.
2. By removing the default styles, you can come to a much greater realization of how much presentation is taken for granted, and how much there is to be dealt with when creating a new design.
3. On a related note, note that the absolute bare minimum presentation of a document is to render all elements with inline boxes, and to show every scrap of content available.  Even something as basic as making a paragraph generate a block box is a style effect.
4. It helps us to realize that what we often think of as the “special handling” of HTML is anything but: in Firefox/Mozilla, HTML documents are just a case of some markup that happens to have some pre-defined CSS applied to it.  Granted, the proprietary extensions needed to keep things in line with expectations are a case of special handling, and those tell us one of two things:
   • CSS still has a long way to go before it can be called a full-fledged layout tool, since it can’t fully recreate traditional HTML layout.
   • Old-school HTML layout was so totally wack, it’s no surprise that it’s hard to describe even with a tool like CSS at your disposal.
   I’ll leave it to the reader to decide which of those two they prefer.  Or, heck, choose both.  It isn’t as though they’re mutually exclusive.

Have fun fiddling with or completely removing the built-in styles!  Just remember: modifications like those described are made at your own risk, I’m not responsible if you do this and your hard drive vaporizes, no warranty is expressed or implied, not a flying toy, blah blah blah.

• Really Undoing html.css was published on Wednesday, September 15th, 2004.
• It was assigned to the Browsers and CSS categories.
• There have been sixty-six replies.

Okay, apparently that wasn’t the rest of the story.  In part, that seems to be because I didn’t express what I was trying to say very clearly.  In others, it’s because people reminded me of points I should have made, or else brought up good points I didn’t address (or consider).  Time for some follow-up.

A few people said “who cares about three/six bytes?”  Me, obviously.  On many pages, such as the archived entry, it’s not going to be a big deal.  On the home page, it will be a slightly bigger deal.  On a monthly archive page, it’s common to see twenty or more dates on a single page.  There we start to measure weight reductions in tenths of a kilobyte.  If I take a similar approach in five other cases, that’s half a kilobyte.  It adds up over time, especially when you get several hundred thousand page views a month.  The difference is even more fractional when using gzip encoding, as I am.  But a gzipped 10.4KB page is still smaller than a gzipped 10.5KB page.  It will always be smaller.  Why not take the improvement, if nothing else is harmed?  (As I believe to be the case here, although obviously not everyone agrees.)

The most common objection to what I wrote is that using b violates “semantic purity”.  I disagree entirely.  span has no more semantic purity than b, in my view.  Both are intended for purely presentational effects.  Neither adds anything to the document’s semantics in a fashion that, for example, strong does.  So on those grounds, the choice is a wash; neither is any better than the other.  The only real difference between the two elements (besides their names) is that b has, mostly by tradition but also by way of description, a default presentational rendering—the text uses a bold font face.

Which leads to the next point, one I forgot to make in the previous post (that’s what I get for writing entries late at night).  As I just said, if you use b, then in a view of the document free of author CSS, the text will be boldfaced.  That’s exactly what I want in this case; in a browser where an h5 isn’t boldfaced by default, and there is no CSS being applied at all, I’d like the date to be boldfaced.  Why?  I just do.  Oh, sure, I could come up with a rationale like it being important to highlight the entry date in a weblog, but the reasons aren’t really relevant.  As the page author, those are the kinds of decisions I get to make.  So given that desire, b has another advantage over span for the case I’m describing.  In cases where you don’t want the text to be boldfaced in a rendering free of author CSS, then b is actually disadvantageous.  There will be inevitable complaints about presentational markup, but in a non-CSS environment, what other presentational influence can I have?  None.

It was also pointed out by a few people that I’m over-classing my markup, since I could easily use descendant selectors to get the same results.  That’s absolutely true.  The classes (title and meta) are more remnants of earlier designs, and have outlived their usefulness.  In the beginning, I used the classes because I thought I’d want to use sub-headings in journal entries, in order to break up long posts.  (Andrei does this quite a bit, as do some others.)  I wanted to be sure that the title and date styles applied only to those particular headings in an entry, and no others.  Since then, practice has shown that I never write entries with sub-headings, so the classes aren’t necessary, and in fact my CSS didn’t even need the classes to be there.  Thus, I’ve taken out the classes.  If I ever find myself wanting to break up an entry into headed sections, I’ll use h6 to do it.  So thanks to those who held my feet to the fire on that point.

Lachlan Hunt pointed out that I could save a lot more weight by using UTF-8 characters instead of encoded character entities.  True.  And if I could get UTF-8 to work, I’d probably try do that, assuming I could be sure the content wouldn’t be mangled in current browsers, a worry I definitely don’t have when it comes to element handling.  Lachlan also mentioned that in a CSS3 world, I could use the ::outside pseudo-element to generate another box for styling, instead of nesting one element inside another.  Yes, and in an XBL world I could just generate the extra box(es).  Until either one or both of those worlds comes to pass, markup is the answer.  In this case, I prefer b to span for all the reasons mentioned earlier.

As you might suspect, anyone who doesn’t accept my earlier assertions about markup semantics isn’t going to agree with my markup choices.  I’ve no problem with that; note that I never said anything even remotely resembling “b is always better than span“.  It isn’t.  Neither is span always better than b, as I’ve discussed here and in the previous post.  By all means, if you have a deep-seated aversion to presentational elements, then don’t use them.  In my world, one avoids using them when a semantic element would better serve the intent.  When there is no semantic need, then I figure you should use whatever works best for you.  Knowing how to tell the difference between these cases is a big step toward really understanding how to use markup efficiently and well.

• More Markup was published on Tuesday, August 24th, 2004.
• It was assigned to the CSS category.
• There have been twenty-six replies.

In a previous post on heading levels, I used some of meyerweb’s markup as an example.  In that markup, an apparently useless <b> element appeared.  Here’s the markup:

<h4 class="title"><a href="…” title="…">entry title</a></h4>
<h5 class="meta"><b>entry date</b></h5>

In that post, I also said:

And yes, there are b elements in my markup, and I’m doing that on purpose.  I’ll talk about it some other time.

So now it’s time.

The boldface element is actually a holdover from the previous designs of meyerweb.  You can still mess with them on the theme example page, if you like.  The original idea was to provide an inline element as a hook on which I could hang some styles.  For example, if I wanted to put the date in a box that exactly surrounded the date’s text, but no more than that, I’d need an inline box.  Therefore, I could either style the <h5> element to generate an inline box, or I could have an inline element there for styling purposes.

In the first case (inlining the h5), I’d lose the block box that the element generates by default, thanks to the browser’s built-in HTML styling.  That might be okay in some cases, but more often than not it would be a problem.  Inline boxes accept a limited set of properties, and putting an inline box between two block boxes is generally a recipe for funkiness.  So that left me with the second case, that of adding an inline element.  As an added bonus, doing so gave me two elements (h5 and b) to style, if I wanted them both.

Here’s the CSS that applies to the date headings and their boldface elements:

#thoughts h5 {font-size: 1em; line-height: 1em;
  margin: 0 0 0.5em; padding: 0; color: #CCC;}
#thoughts h5 b {font-weight: normal; font-size: 0.9em;}

Although I’m not doing much with the b element, style-wise, what I’m doing is useful.  First, there’s making sure the font weight is normal, and not bold.  All right, that’s not really useful.  Second, the boldface element is used to reduce the size of the date’s font by a small amount.  I use the b element to reduce the size of the font because that leaves the element box of the h5 alone.  In other words, its text box is not reduced, which means it’s consistent with the text around it.  If I ever go back to a design where the date and title are “on the same line” and lined up with each other, as was the case in many of the old designs, I won’t have to do weird fractional math just to make it happen.

Of course, in the current design, that isn’t an issue.  So in a sense, the b element is sort of a vestige from an earlier stage in the site’s evolution, like a markup appendix.  The only difference here is that the b element might become useful again, whereas I don’t think the appendix has much chance of a comeback.

The other expected question is why, if all I wanted was an inline element as a styling hook, I used a b instead of a span.  Simple: the element name is three letters shorter, so for every hook, I’m saving six characters.  If there are, say, twenty such hooks on a page, that saves me 120 characters.  It’s a small consideration, but by such incremental savings are document weights reduced.  “What about semantic purity?” you may ask.  In my view, b and span have the same semantic value, which is to say basically none.  They’re both purely presentational elements, with the difference that span doesn’t have any expected presentational effects in HTML.  So I used the presentational hook that made the most sense to me: b.

If my goal was to emphasize the date, then I’d have used em or strong, but it wasn’t.  I just needed a hook, at least once upon a time, and that was the element I chose as my hook.

And now you have the rest of the story.

• Markup Missive was published on Monday, August 23rd, 2004.
• It was assigned to the CSS category.
• There have been forty replies.

Thomas Jogin recently posted an interesting entry that asks about HTML headings.  He starts out this way:

For some time now, something has been bothering me about the common way of marking up a document structure. First of all, it doesn’t seem like there is a consensus on wether or not to use multiple H1 tags, or any at all.

I agree: there isn’t a consensus on that point.  There is also a lack of consensus on his second question:

Secondly, since H1-H6 are supposed to denote the structure of a document, do they really have a place in the side column as section headlines?

In fact, there’s very little consensus on heading use in general, except that you should use them instead of font size="+3" and that sort of thing.  Headings make for more visibility in Google than does presentational markup, after all.

In considering Thomas’ question, Andy Budd goes to the specification, which is always a good place to start.  As he points out, HTML 4.01, section 7.5.5 states:

A heading element briefly describes the topic of the section it introduces. Heading information may be used by user agents, for example, to construct a table of contents for a document automatically.

There are six levels of headings in HTML with H1 as the most important and H6 as the least. Visual browsers usually render more important headings in larger fonts than less important ones.

So as far as a semantic definition of the heading elements goes, all we have is that heading levels indicate degrees of importance.  Nothing about what order they have to be in, or whether you can skip levels, or anything else besides the creation of a spectrum of importance, as it were.  Because that’s all we have, there is plenty of room for people to fill in their own interpretation of what’s best.  I approach headings as merely indicating a level of importance, and don’t bind myself to a decreasing numeric order.  That’s my take on it; others feel differently.  Let’s take a look at two cases where my approach led to very different results.

The first case is Netscape DevEdge.  Here’s the markup skeleton for the first part of the home page as I set it up (the actual markup as of your reading this may be different):

<h1>
 <a href="/" target="_top"><span>Netscape</span> DevEdge</a>
</h1>

<form action="/search/app/" id="srch" method="get">
<h4><label for="search-input">Search</label></h4>
(...inputs...)
</form>

<h2>Netscape 7.1 is now available</h2>
(...paragraph text...)
<h2>The DevEdge RSS-News Ticker Toolbar</h2>  
(...paragraph text...)
<h3>Recent News</h3>
(...list of links...)

Here, the order is h1-h4-h2-h2-h3.  I guarantee you that some readers are feeling a deep outrage right now, because we got more than one piece of feedback berating us for putting the headings ‘out of order’.  The h4 was clearly out of place, we were told, and needed to be fixed.

The placement of the search markup in the document was dictated by our preferred document linearization, however.  In an unstyled view (a really old browser, say, or a cellphone text browser) we wanted the masthead to be immediately followed by the search feature, and that to be followed by the main content.  The main content was in turn followed by the sidebars, which was followed by the navigation and configuration links, and finally the footer.  So we weren’t about to move the search markup just to make its heading level fit into a descending-number hierarchy.

We could have elevated the heading to an h2, but that struck me as being a poor choice.  Is the “Search” title really as important than the top headlines on the site?  I certainly didn’t think so.  My only other option was to change the h4 to some non-heading element and style it that same as I had the h4  That’s certainly easy to do, since with CSS you can make any non-replaced element look like any other element, but that would mean the search area had no heading at all.  That also struck me as a poor choice.

So I took the route I did.  I suppose I could have, as Richard Rutter suggests, put in some extra headings to increase the structure and then “switched off” their display with CSS.  That would mean inserting an extra h2 and h3 between the masthead and the search.  What would they say?  Personally, I’m not thrilled with that idea either, at least for the DevEdge case.

The second case I’d like to consider is meyerweb.com itself.  Here’s the basic structure of the home page, at least as of this writing:

<div id="sitemast">
<h1><a href="/"><span>meyerweb</span>.com</a></h1>
</div>
<div id="thoughts">
<h3 id="thtitle"><span>Thoughts From Eric</span></h3>
<div class="entry">
<h4 class="title"><a href="..." title="...">entry title</a></h4>
<h5 class="meta"><b>entry date</b></h5>
</div>
<div class="entry">
<h4 class="title"><a href="..." title="...">entry title</a></h4>
<h5 class="meta"><b>entry date</b></h5>
</div>
</div>

Here, I skipped the h2, but other than that everything’s in a descending-order hierarchy.  In this case, such an approach was a fairly natural fit to the information being presented.  I don’t have an h2 on the home page because it’s reserved for page titles, such as the “Eric A. Meyer” at the top of my personal page.  The page title of the home page would be “Home Page” or “Main Page” or something equally silly, so I left it off.  (And yes, there are b elements in my markup, and I’m doing that on purpose.  I’ll talk about it some other time.)

Meanwhile, in the sidebar, the section headings (such as “Distractions”) are enclosed in h4 elements.  That makes them as important as entry headings, and I’m okay with that.  I might have chosen h5 instead, but probably not h3.  The one exception is “Blog Watch”, which is an h5 element.  I don’t have any rigorous logical explanation for this; it’s all based on gut feelings.

In the end, I don’t think there will ever be a heading consensus.  XHTML 2.0 attempts to bridge the gap by adding the generic h (heading) element, which helps create a descending-order hierarchy when combined with nested section elements.  What bothers me is that the Working Group hasn’t decided whether or not h1 through h6 should be deprecated; to do so would in effect attempt to force a consensus in favor of a descending-order hierarchy.  That would mean that headings were no longer as much about importance as they were about having a document that’s structured like a specification, or maybe an e-book.

In the here and now, though, we’re left to ponder these questions and arrive at our own conclusions.  Each answer will depend on the temperament of the ponderer, and the project upon which the pondering is predicated.

• Pick A Heading was published on Wednesday, July 21st, 2004.
• It was assigned to the Standards category.
• There have been sixty-five replies.

At last week’s Web Design Meetup, a couple of people showed me their current projects.  As is my wont, I glanced over the visual design and then started digging into the document markup.  In the course of the resulting conversation, I pointed out some ways to tighten up the markup.  I’ll repeat them here for those who are curious.  All of them relate to using classes and IDs efficiently.

The first recommendation I had was to use classes and IDs in conjunction.  Not everyone is aware that an element can carry both a class and an ID.  Well, they can.  So it’s no problem to have markup like this:

<div id="utilities" class="menu">

That way, you can style all menus consistently via the menu class, while having the utilities ID there for any ‘Utilities’-specific styling you need to do.  This has always been possible, and it’s supported by multiple browsers.  You don’t see it often, I admit, but then it’s not often needed.

The second recommendation was to use space-separated words in your class values.  This is thoroughly legitimate, and can make things a lot more compact.  So you might have something like:

<td class="subtotal negative">(-$422.72)</td>

You can then have one rule that styles all subtotals, and another than styles any negative number.  For example:

.subtotal {font-weight: bold;}
.negative {color: red;}

By using these kinds of class values, you can avoid having to construct one class for subtotal, and another for subtotal-negative.  If you’re doing that sort of thing, I can tell you right now that your CSS is larger and more complicated than it needs to be.  Multiple-word class names also free you from having to do things like throw in extra spans or other elements just to add more information, like so:

<td class="subtotal"><span class="negative">(-$422.72)</span></td>

That kind of structure is almost never needed, except in extremely rare cases where you must have an inline element on which you hang some presentational styles that can’t be applied to the table cell.  I can’t even think of a concrete example right now, but I’m sure there is one.  In which case, I’d say do this instead:

<td class="subtotal negative"><span>(-$422.72)</span></td>

But, as I say, the odds of your having to do that are very very low.

All this leads to a third recommendation that came to mind as I looked over the markup.  Remember to use document structure to your advantage, and not to class everything in sight.  I can’t tell you how many times I’ve seen this kind of markup:

<div class="navlinks">
<a href="blah01" class="navlink">Blah01</a> |
<a href="blah02" class="navlink">Blah02</a> |
<a href="blah03" class="navlink">Blah03</a> |
<a href="blah04" class="navlink">Blah04</a> |
<a href="blah05" class="navlink">Blah05</a>
</div>

Out of the six classes that appear in that markup fragment, five are completely useless and simply bloat the page weight.  Here’s a much more efficient way to structure the markup:

<div class="navlinks">
<a href="blah01">Blah01</a> |
<a href="blah02">Blah02</a> |
<a href="blah03">Blah03</a> |
<a href="blah04">Blah04</a> |
<a href="blah05">Blah05</a>
</div>

Now all you do to style the links is write a rule that uses the selector div.navlinks a instead of one that uses a.navlink.  In addition to making the HTML weight smaller, it also makes the document cleaner and a whole lot easier to read.  Your users don’t really care about that, of course, but I bet you will, if you ever have to go in and adjust either the markup or the content.

So there you go.  Hopefully it was of some help to you.

• Competent Classing was published on Sunday, July 18th, 2004.
• It was assigned to the CSS category.
• There have been forty-five replies.

After I threw out my two cents on ID naming conventions, Andy Clarke revisited the subject and made some more detailed proposals.  As I said before, I think this is a good conversation to be having.  However, the reactions of some people make me think that I wasn’t entirely clear about why.

A standard nomenclature offers the ability to restyle sites, sure.  That’s kind of cool in an übergeek kind of way, like making jokes involving TCP/IP terminology or wearing a T-shirt that says SELECT * FROM users WHERE clue > 0.  That isn’t really the primary reason why I support the exploration of ID naming conventions.  I’d like to see those conventions emerge because they will serve as a useful starting point for beginners in the standards-oriented design field.  It would help reinforce the idea of structural naming, as opposed to presentational naming.

We’re all familiar with presentational naming.  It’s things like id="leftbar" and id="pagetop".  In terms of layout, it’s the equivalent of <b> and <font>.  Structural naming, on the other hand, encourages the author to ask “what role does this piece of the document play?”  Rather than obsess over the visual placement of the navigation links, structural naming gets authors to consider the document structure.  This can’t be anything but good, at least for those of us who want to promote improved structures.  To pick one set of examples from Andy’s recent post:

#branding

Used for a header or banner to brand the site.

#branding-logo

Used for a site logo

#branding-tagline

Used for a strapline or tagline to define the site’s purpose

While #branding is described as “Used for a header or banner…” you may note that the actual ID name has nothing to do with visual placement.  It’s all about identifying the (dare we say it?) semantic role of that bit of the document.  By encouraging that thinking, a structural-naming convention keeps the author in that frame of mind when he has to go outside the common set of names.

I see this as being much like the often-promoted ‘rule’ that link-state styles should go in the order link-visited-hover-active.  I even wrote an article explaining why that order is important.  Here’s the thing: once you understand why the order is important, you can break the ‘rule’ in creative ways.  For example, suppose you want your hover effect to apply only to unvisited links, whereas visited links should get no hover.  No problem!  Just put them in the order link-hover-visited-active, or even link-hover-active-visited if you want visited links to get no active styles, either.

(Side note: if you chain pseudo-classes, such as with a:visited:hover, then the ordering problem goes away.  If Explorer supported that syntax, we could all move on from the LVHA rule.  Too bad it doesn’t.)

Conventions and ground rules exist for a reason: to provide a lower barrier to entry, and to help guide those new to the field.  Once you become experienced, you can break the rules in creative ways.  It’s been said that the key to good jazz improvisation is a thorough understanding of the rules of music.  In other words, once you really know those rules, then you know how to break them.  In order to know the rules, though, there have to be rules.

That’s why I’m glad to see them starting to emerge in blog postings and the public thinking of people in the field.  The development of these rules is not a barrier to creativity, but an enabler of it.

• Structural Naming was published on Saturday, June 26th, 2004.
• It was assigned to the CSS and Web categories.
• There have been thirty-eight replies.

Doug Bowman’s observations on the separation of presentation and content are well made, and illuminate an oft-overlooked corner of the whole standards debate.  Even with some semantic correction, we still have room for discussion.

My semantic correction is that we aren’t trying to separate presentation and content, but presentation and structure.  Doug makes this point throughout the latter part of his post, but I think this is the important thing to state right up front.  Without content, it’s very difficult to have any presentation, except maybe a blank browser window (very minimalist, but not necessarily useful).

Even there, however, the divorce is not complete and never can be.  I’ve been saying this in public presentations for a while now, and it bears repetition here: you can have structure without style, but you can’t have style without structure.  As Doug observes, you have to have elements (and, also, classes and IDs and such) in order to apply style.  This is absolutely the case, and it should come as little surprise, really.  If I have a document on the Web containing literally nothing but text, as in no HTML or other markup, just text, then it can’t be styled.  Presented, yes, using the browser’s defaults for showing raw text.  But not styled.

This is also why I’ve argued that the document structure is dependent on your presentational needs.  Document structure is like the support beams for a building.  The final layout and appearance of the building will depend very heavily on the shape those support beams create.  If you ignore that, and assemble the beams with no thought toward the final product (not following the blueprints, as it were), the best you can hope for is an inefficient, almost unusable building.  In the worst case, the building will utterly collapse as soon as you try to add anything useful to the structure.

This has been a minor issue in HTML, but XML throws the issue into sharp relief.  Consider the following fragment of XML:

<city name="Cleveland" state="Ohio">23</city>

Okay… any idea what that number represents?  No, probably not.  What’s worse is that if I hand that element to a user agent, it will display the element’s content: 23.  The user won’t even have the attribute values to give them what little hints you got by looking at the source.  They just see the number 23.

That’s because attribute values don’t get displayed, while element content does.  Yes, we can use CSS generated content to make the attribute values show up, but how crazy is it that the following would be needed to make the display more useful?

city:before {content: attr(name) " " attr(state) ": ";}

And then, if you wanted to make the bits of data lay out like a table—you can’t.  Oh, sure, you could get the generated content into one layout piece, and the element content into another, but you can’t get the city name and the state name into separate cells.  Even if you could apply display: table-cell to the generated content, you can’t split it into different cells.

We can argue that this illustrates limitations in CSS, and to a degree that’s true, but to do so misses the point entirely.  There will always be some limitation we can’t overcome, something the styling language of the moment can’t make possible.  What I’m talking about is the fact that presentation is inextricably bound to structure, and document authors ignore that connection at their peril.  Let’s return to that XML fragment and restructure it to be more intelligent:

<city region="midwest">
  <name>Cleveland</name>
  <state>Ohio</state>
  <hightemp scale="c">23</hightemp>
</city>

Now, not only do we have more actual content to be displayed by default, but we have more elements to actually style.  So we might turn the above into a table-like structure, complete with some useful cues for the user, like so:

city {display: table-row;}
city > * {display: table-cell; width: 33%;}
hightemp[scale="c"]:after {content: " degrees Celsius";}
hightemp[scale="f"]:after {content: " degrees Fahrenheit";}

Now, thanks to our structure, we can make the display much more useful for the user, and understand it better ourselves.  We can even style the city and state differently now, whereas before that was impossible.  We’ve also been able to use an attribute value to affect presentation.  I included the attributes to show that attributes aren’t at all useless, or even have to stay completely out of the presentation.  They can be quite handy.  However, the region attribute is a good example of data that has to be carefully considered.  If we ever want to display a city’s region next to its name, then it’s probably a good idea to use an element (like <region>...</region>) instead of an attribute.  If we just want that information in the data structure for purposes of transformation, or to style descendant content without actually displaying the region’s name, then an attribute makes far more sense.  For example:

city[region="midwest"] {background: green; color: white;}
city[region="northeast"] {background: purple; color: white;}

If we’re going to do that kind of thing, treat the region almost like it’s a class, then we definitely want it as an attribute.  If it were an element, with the region name as content, we’d have no way to style it (or anything else) based on its content.

What it comes down to is that structure is critical to presentation, with or without the style—although intelligent structure makes styling lots easier.  Contrary to what some may have claimed or implied, you can’t just create an arbitrary structure with no consideration toward its presentation.  If you want something on the screen, it needs to be element content.  That may not be ideal, but it is inescapable.  Structure may be able to break up with style, but style still needs and depends on structure in a big, big way.  Personally, I’m not sure it can ever be otherwise.

• The Incomplete Divorce was published on Wednesday, October 15th, 2003.
• It was assigned to the Standards category.
• There have been no replies.