Posts in the CSS Category

I was recently honored with a request to contribute to Design In-Flight magazine, and so the latest issue contains a piece titled “Stripped Down Style”.  The article is an expanded version of Really Undoing html.css, accompanied by some screen shots and containing a copy of Tantek’s undohtml.css.  The magazine also includes an article from Jon Hicks about his icon design process, focusing on the icons he’s created for NetNewsWire 2; a piece from Keith Robinson on public speaking; a how-to guide for mapping out the structure of your style sheets by Yasuhisa Hasegawa; and a good deal more.

It does cost a few bucks to get a copy the magazine, but they really are a very few—certainly several less than you’d spend on a comparable magazine in print.  You can also get a yearly subscription of four issues for ten bucks.  Having read the first two issues of the magazine, I’m definintely feeling an urge to subscribe.  Editor Andy Arikawa has proven a master at pulling together some great content from interesting authors, and at covering a diverse set of topics.

I must also admit to some amusement at how the title of this issue, “Not Your Father’s CSS”, echoes (most likely coincidentally) the title of my radio show.

• Stripped Down Style was published on Sunday, October 17th, 2004.
• It was assigned to the CSS and Writing categories.
• There have been no replies.

You probably know that I’m a long-time Macintosh user, going back to the days of the single-floppy Mac SE.  At one point, I worked in a computer lab that had a “Changing the world, one person at a time” poster on the wall.  Every single one of my books, articles, and other resources has been written or developed on a Mac.  So you can imagine how thrilled I am to be featured in an Apple Pro article.  Not only can you find out a little bit about how I got into this whole CSS thing, but see a picture of me dropping some fat horns on my listeners.

I’ll put this Pro file on the shelf with being made a comic strip character as “ways to know I’ve really made it”.  But you know what really told me I’d arrived?  Discovering that someone had created a Wikipedia entry about me.  It was a pretty stubby page at the time, but its mere existence was enough to drop my jaw into my lap.  Now I find myself wondering if I should edit my own entry to include a full biography and related links, or if that would in some way be incredibly gauche.  (And asking someone else to do it for me would just be gauche by proxy, which is worse.)

It’s an odd thing to be famous, even when the fame is limited to a specific field of activity.  As a matter of fact, I was recently asked to write an article about the “fame game” and I’m still mulling over how to tackle it.  See, when you get right down to it, being well-known is both a reward and a restraint.  When people look to you, there’s a certain set of expectations that gets imposed upon you, whether you want them or not.  You’re supposed to always be right, always be fair, and always be in agreement with whoever’s looking to you.  None of these things are possible.

Nevertheless, I am where I am because I worked to get here (and was lucky), and I’ve no real complaints about the position I occupy.  All told, it’s not a bad thing.  It isn’t even a good thing.  It just kind of is.

So there’s still the question of what I might write about the “fame game”.  As it was posed to me, the editor was interested in my thoughts on “how influential designers and developers must balance ‘responsibility’ to the community with their own need to say what’s on their mind and use their clout to get good things done”.  In many ways, it’s the classic “how do you feel about being a role model?” question.  I’m not entirely sure I’m qualified to answer the question, although I do have some ideas.  I often wonder what the community thinks, though.

So I’ll throw it out to you lot: in your personal opinion, how should influencers balance community responsibility with personal expression—or does there need to be a balance at all?

• Finding Fame and Fortu—Okay, Just Fame was published on Monday, October 4th, 2004.
• It was assigned to the CSS, Interviews, and Personal categories.
• There have been twenty-two replies.

Having talked about how to completely rip away all brower default styles in Firefox, let’s consider the bare minimum of styles we’d need to make the Web at least moderately readable.  As it turns out, the primary factor in document mangling caused by taking out the browser’s default styles is the loss of any display information.  In the absence of information regarding what kind of box an element should generate, they’re all made to generate inline boxes.  This is roughly equivalent to saying:

* {display: inline !important;}

Speaking of which, feel free to try that some time on a test document, or as an entry in a browser’s user style sheet.  The result should remind you of the no-defaults trick.

So let’s say we back up the browser’s default style sheets (you don’t want to lose them completely, unless you plan to re-install the browser) and then erase everything in html.css.  Having done that, we can restore a great deal of sanity to the Web by placing the following rules into html.css.

@namespace url(http://www.w3.org/1999/xhtml);
  /* set default namespace to HTML */

html, body, p, div, h1, h2, h3, h4, h5, h6,
ul, ol, dl, dt, dd, blockquote, address, pre,
listing, plaintext, xmp, menu, dir, isindex, hr, map,
multicol, center, frameset, marquee {display: block;}

li {display: list-item;}

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

table {display: table;}
caption {display: table-caption;}
tr {display: table-row;}
col {display: table-column;}
colgroup {display: table-column-group;}
tbody {display: table-row-group;}
thead {display: table-header-group;}
tfoot {display: table-footer-group;}
td {display: table-cell;}
th {display: table-cell;}

That rule set will not only cause block-level elements to start generating block boxes again, but it also lets list items be list items, hides the elements we’d like to have vanish, and restores table behavior to table markup.  With those few rules in place, browsing around will be much easier.  It might not be pretty, but it will avoid the extreme wreckage of removing all default styles.

There will still be some notable differences.  For example, paragraphs may now generate a block box, but they aren’t being given margins, so on most sites paragraphs will suddenly not have a “blank line” of separation.  Similarly, heading margins are gone.  Lists don’t have any predefined indentation.  Table cells don’t have default padding, and the “gutter” around page contents has vanished.  Of course, you might see some or all of those things on a site.  If you do, it means that information has been provided by the site’s styles.

In a quick browse of the Web, I found that CNN‘s site was still kind of scrambled by these styles, though certainly not as badly as before.  As an example, a lot of the article sidebars and pictures weren’t floated, which means the float behavior is markup-driven, not CSS-driven.  Why does it matter?  Because in Firefox, align="right" is just a markup hook on which the default style float: right; gets hung.  If that declaration doesn’t appear in the default styles, the markup will have no visible effect.  In other words, no floating.

The home page of The Mozilla Foundation, on the other hand, hung together pretty well, which indicates all of their layout is driven by CSS instead of presentational markup.  This didn’t come as much of a surprise, but it was nice to see.  I was pleased to find that meyerweb’s home page also stayed in decent shape.

So should you add these rules to your style sheets?  Not unless you’re feeling extra-super-mega-paranoid.  The percentage of visitors displaying your site with the default style sheets removed can be safely estimated to very closely approach zero, maybe even touching it.  Besides which, if someone does drop by with all default styles removed, they’ve probably done it on purpose.  If they then send you snarky e-mail about they broke your site that way, feel free to answer them with a polite acknowledgment that they did, indeed, successfully cut their own throat.  It’s not like that’s your problem, any more than you should be bothered that someone “broke” your site with an anarchic user style sheet that suppresses display of lists and paragraphs, or sets all non-replaced elements to use white text on a white background, or whatever.

A more interesting question is whether you should set up a browser to use just those rules as defaults.  I’m giving serious thought to maintaining two copies of Firefox: a normal install, and a development install that’s been hacked to use just the styles I listed before.  It could prove valuable in checking the design assumptions of a work-in-progress, and thus to identify possible weak points in the author styles.  As an example, if I loaded a new design into the development browser and found that lists were completely non-indented, then I’d know I was leaving the list indentation distance up to browser defaults.  At that point, I could decide whether or not that was a good idea.  In some designs, it might be fine, but in others it could be a problem.  Either way, I’d have the chance to consider that question directly, and reach a decision, instead of sailing blindly on, never having thought about it either way.

• Fractionally Restoring html.css was published on Monday, September 20th, 2004.
• It was assigned to the CSS category.
• There have been ten replies.

I was just recently asked if attribute selectors must use quotes around the value.  In other words, are both the following two selectors legal?

a[href="http://www.meyerweb.com"] {font-weight: bold;}
a[href=http://www.complexspiral.com] {font-style: italic;}

“No, they’re optional,” I said with assurance.  And then the doubts started to gnaw at me.  What if they actually weren’t, which might make sense given that you can require the exact match of a space-separated list of attribute values? By this, I mean that if you declare:

div[class="this is a test"] {color: orange;}

…then the selector will match any div element whose class attribute is exactly this is a test, in that order, and with nothing else in the attribute value.  Or so I’ve always been given to understand.  In that case, if you left off the quotes, couldn’t that somehow be confusing to the browser?  Maybe not, but it still bothered me.

So I went digging through CSS2.1, Appendix G and found the grammatical definition of an attribute selector.

attrib
  : '[' S* IDENT S* [ [ '=' | INCLUDES | DASHMATCH ] S*
    [ IDENT | STRING ] S* ]? ']'
  ;

You all understood that, right?  Uh-huh.  Me either.  (This is one of those hostile-to-outsiders posts I mentioned a while back.)

I never liked grammar in school, and I still don’t, but it is sometimes sadly necessary.  So here goes.  When you run down the definitions of the all-caps words (I think those are tokens) you find that IDENT is an identifier, which is sort of a catch-all bin for things like selectors, property names, values, and such.  Fine.  STRING, on the other hand, is a collection of symbols and other fun stuff, again including the non-ASCII range but not the ASCII range.  But then it includes the entirety of Unicode.  I’m not sure how much sense that makes, but whatever.

So the whole point of this is: if quotes around an IDENT are optional, wouldn’t it have made more sense to say this?

attrib
  : '[' S* IDENT S* [ [ '=' | INCLUDES | DASHMATCH ] S*
    [ STRING? IDENT STRING? ] S* ]? ']'
  ;

Or even:

attrib
  : '[' S* IDENT S* [ [ '=' | INCLUDES | DASHMATCH ] S*
    [ '"'? IDENT '"'? ] S* ]? ']'
  ;

It’s the [ IDENT | STRING ] from the original definition that has me befuddled.  It seems like it’s saying you can include an IDENT or a STRING but not both, and since IDENT doesn’t include quotes, that implies that you can either drop in an identifier, or a string with quotes.  Why is this a good idea?  Does it mean that any identifier has to be unquoted?  Does it mean that there’s no practical distinction between a STRING and an IDENT in this situation?  Does it mean that quotes prevent the inclusion of anything useful?  Somebody let me know.

• Grammar Question was published on Saturday, September 18th, 2004.
• It was assigned to the CSS category.
• There have been sixteen replies.

Since a few people asked for it, I’ve created a test file that reproduces the Internet Explorer freeze reported yesterday.  You can find it with the title “Internet Explorer Freezes — BEWARE!“.  If you follow that link with a non-IE browser, you should see a static copy of the “Ten Things To Do…” post, with two differences:

1. I stripped off the theme stylesheet so the masthead graphic isn’t shown.
2. I inserted a warning/explanatory comment near the top of the document.

Under the hood, the main difference is that the style sheets are all embedded in the document, so if you’re so inclined you can download that single page to your hard drive and fiddle with it to your heart’s content.  If anyone can narrow down this problem to a very minimal test case, I’d love to see it.  Refer back to “When Browsers Attack!” for notes on what I discovered.  There may well be more to the story, but if so, I didn’t find it.

I’ll reiterate the warning, in case it somehow wasn’t clear enough: iif you load this document in IE/Win, the odds are very, very, very high that it will freeze Internet Explorer, necessitating a force-quit of the application.  It may also crash Windows.  If you don’t want those sorts of things to happen to you, then don’t load the document.  Clear?  Good.

• Freezer Case was published on Friday, September 17th, 2004.
• It was assigned to the Browsers and CSS categories.
• There have been twenty-three replies.

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.

There’s a faint tendency in my work to operate in threes.  I wrote a theory book, a reference book, and a practical book, for example, even referring them to the three legs of a stool.  (Okay, so I’ve written more since then.)  Hopefully, this will serve as the third of three posts on tables and layout, and not the third of more than three.  I have other things I want to write about that have been delayed, and honestly, I grow weary of tromping the same ground again and again.

Brad Bice pointed out that my example markup could be noticeably reduced in size by doing the following:

div#layout {display: table;}
div#layout > div {display: table-row;}
div#layout > div > div {display: table-cell;}

<div id="layout">
 <div>
  <div>...content...</div>
  <div>...content...</div>
  <div>...content...</div>
 </div>
 <div>
  <div>...content...</div>
  <div>...content...</div>
  <div>...content...</div>
 </div>
 <div>
  <div>...content...</div>
  <div>...content...</div>
  <div>...content...</div>
 </div>
</div>

That brings the CSS approach roughly into line with the weight of the table-based approach, which is good.  That still leaves us with the larger problem that Explorer still doesn’t support the application of table-related display values to non-table markup, so the layout will completely fall apart in IE/Win, which is bad.  I suppose you could script your way around the problem, a la IE7.  I wonder how you’d account for the lack of things like rowspan and colspan, though.  CSS doesn’t offer anything comparable.

There were a few responses to the effect of “what Eric fails to say is that table elements already have a predefined meaning”.  True, I failed to say that, mostly because I didn’t think it was important to bring up.  I think it’s fairly safe to assume that if you’re worrying about any of this stuff, then you’re going to try to use semantically appropriate elements when you can.  However, if you accept that there are times when a grid layout system is needed, then you have to accept that need will override any concerns about defined element meanings.  In other words, the defined semantics of table markup are important, but they aren’t important enough to block the use of table markup when it’s needed for layout purposes.

Some would say that if you can’t accomplish your design without violating markup semantics, then you should create a different design, one that doesn’t require the use of table markup.  That’s one of those “you can choose any color you want as long as it’s black” arguments that just make me sadly shake my head.  There’s no argument that will change that kind of thinking: it rejects reality in favor of internal consistency.  If that works for you, great, but I can’t operate that way.  We’ll just have to agree to disagree.

Then there were the responses that ran something like “okay, so tables are necessary for a few things, but for almost every type of Web design you don’t need to use tables”.  Yes.  I said that.  I said it several times, in fact, in different ways.  Maybe that was a mistake.  So, if I may, allow me to summarize the points I’ve apparently been obscuring over the past few days.

• In the vast majority of Web design cases, you can accomplish your layout without the use of table markup, and you can do so in today’s browsers.  This applies even to most layouts that appear to be grid-based at first glance.
• There are a few cases, very rare ones, that require grid-driven layout where all the grid pieces line up both horizontally and vertically, both side to side and top and bottom, and the contents of the pieces have dimensions that cannot be predicted in advance.
• At the current stage of the Web’s evolution, such layouts require table markup if you want the design to work as intended in Explorer as well as more recent browsers.
• The table markup used in such designs can and should be very light-weight, and use CSS for presenting all of the visible content within the table.  The table itself can also be styled using CSS for the most part, although row- and column-spanning still has to be done at the markup level.
• From this point on, anyone who uses these posts to claim that I’m saying tables should always be used for layout is either not paying any attention, has an agenda to promote, or both.  Probably both.

Fin.  I hope.

• To Be Tabled was published on Monday, September 6th, 2004.
• It was assigned to the CSS category.
• There has been one reply.