Tuesday, February 03, 2009

On the semantics of HTML

Since we're having so much fun talking about tables and CSS and whatnot I thought I'd see how long I could keep the party rolling. Yes, I'm being ironic. I actually didn't want to get sucked into this. But I made an offhand comment in my last post that needs clarification:

HTML has no semantics beyond how it is rendered!

That resulted in comments like this one:

No. You're very, very wrong about this. The whole field of SEO exists because you are wrong. The title element, depths of heading, everything is used. Just because you can't see it being used, it doesn't mean it isn't.

It's commonly said that Google is the biggest blind user in the world. If your content isn't blind-accessible, it's likely to be less Google-accessible. Accessibility is for everyone.

This is too big a misconception to let slide, so here I go again.

First, notice that I did not say that HTML has no semantics. I said that HTML has no semantics beyond how it is rendered. It turns out that this is not quite correct, but the way in which it is not quite correct is subtle and rather difficult to explain. So I'll start with an example. There are two links there. They both go to documents whose HTML content is identical. The only difference between the two documents is the style sheet. Those of you who use custom style sheets in your browser will probably need to turn them off. Those of you who are blind (do I have any blind readers?) will completely not get the point of the example.

And that is precisely the point of the example.

Back in 1995 I wrote an essay for the Risks forum called the source of semantic content. Back then it was in the context of an attempt by then-Senator Jim Exon of Nebraska to pass legislation limiting the transmission of pornography on the Internet. The key sentence of that essay is as relevant today as it was forteen years ago:

[T]he semantic content of bit streams is in the eye of the beholder, and ... the apparent correspondence between bits and semantics is the result of engineering convention and not an inherent property of the bits.

Let me try to explain what I mean by that by way of a non-computer-related example. What gives words their meaning? One answer is that their meanings are given by their dictionary definitions. (The French take this to a whole nuther level.) This would be analogous to saying that the semantics of HTML are given by the standards published by the W3C. It is not an unreasonable answer. But it is wrong.

The best example I know of to show that it is wrong is so powerful that I almost dare not use it. It is the word "niggard", with an A, no E, and a D at the end. The dictionary definition of this word is, "A stingy, grasping person; a miser." A negative connotation to be sure, but on its face less offensive than some of the epithets that people regularly sling at one another. And yet the actual semantics of the word, which is to say, its actual meaning as measured in terms of the effect it has when it is employed, is radically different from its dictionary definition. (The word "ignorant" has a similar property. So does "liberal", at least in the U.S.)

Neither words nor computer programs derive their true semantics by fiat. They derive their semantics by the effects they have on the world. And the principal effect that HTML has on the world is that it gets rendered in browsers and those renderings are viewed by humans. The W3C and CSS purists can rant and rave all they want, but the fact of the matter is that what the HTML in the above example really means depends on which style sheet you use to render it.

And that is true for any HTML document. It's fairly easy to make a CSS style sheet that will take any HTML document and cause it to render in a completely arbitrary way. (How to do it is left as an exercise for the reader.) This is not just an academic observation; techniques like this are frequently used by spammers to get past filters.

The counter to this is that these people are undermining the true semantics of HTML. They are somehow "cheating" or "ruining the web" or some such thing. I have a certain amount of sympathy for this position. I am no fan of spam. The world would be a better place if everyone followed the rules. But this is just like arguing that the world would also be a better place if everyone agreed to abide by the dictionary definitions of the word "niggard". You can argue this until you are blue in the face. That will not change the fact that if you call a person with black skin a "niggard" you will likely cause more offense than if you called her a "miser". That is reality.

The reality for HTML is that its semantics are determined primarily by how it renders on the browsers that people actually use. And at the moment that includes IE6. The H1 tag doesn't mean "top level heading" because the W3C says it does. It means top-level heading because browsers by default render it in big bold type and as a block rather than inline. And if you believe that I have the causality backwards, that browsers render H1 big and bold because it means top-level heading, imagine an alternate world where the default style for H1 was NOT big bold type, and ask yourself how many people would use <font size=+10> instead. (Actually, you don't have to imagine. Just look at how many people use the "I" tag instead of the "EM" tag, or how many web forms are out there that don't use LABELs. Actually, I use "I" instead of "EM" myself. It's partly out of habit (when I started writing HTML there was no EM tag) and partly because "I" is less typing, uses up less screen real estate, and accomplishes the same thing for my purposes.)

Now, I said at the beginning that all this was not quite true, and the thing that makes it not quite is SEO, which is to say, Google. Google imposes a set of operational semantics on HTML that are substantially different from those imposed by browsers, and it is those differences that lie at the root of many a web designer's sleepless nights, and is responsible for the existence of the SEO industry. But here's the thing: even mighty Google has to yield to the operational semantics of browser rendering. Google puts in enormous effort to try to glean how a page will render, and not just extract its apparent content as defined by the W3C. The reason they do this is simple: if they don't they will be overwhelmed with spam. If Google could generate their index by rendering every page and running OCR on it they would. The only reason they don't is that it's prohibitively expensive.

By the way, if you still doubt that the semantics of HTML are inextricably bound to rendering, consider the P tag and tell me how you define a paragraph without talking about rendering. A paragraph is an inherently visual concept. If you doubt this, do the following experiment: take an audio recording of Barack Obama's inauguration speech and transcribe it. Now compare your transcription with the original text. Count the number of places you put in a paragraph break where there was none in the original text, and the number of places there was a paragraph break in the text that you missed. Now compare that count to the number of places where you missed (or added) the end of a sentence. Now ask yourself: why is there markup for paragraphs but not for sentences?

61 comments:

I would argue that the situation isn't as black and white as you make it out to be.

Your argument that the semantics of HTML are determined primarily by how it renders on the browsers relies on the premise thata description theory of reference is true. A description theory of reference states that a term, such as paragraph, header, or h1 refers via the descriptive content of the user of the term. In this case, the user would be the browser, and the term would be the HTML element.

For a greater summary of problems with description theories, I'll refer you to the SEP article. I'll just say that one user's internal representation and description of an external entity has been shown to be insufficient to pick out that entity.

If I write one HTML document with an h1 element, the fact that my first-level header is described differently by different browsers does not mean that there are multiple, different elements. There is simply one h1 element, the element in my HTML document.

Semanticists have generally turned to a causal theory, in which reference is fixed at a dubbing, and passed along through a causal chain. I can call a large, four-legged, bovine, milk-producing mammal a giraffe, but that doesn't make it a giraffe. It was dubbed a cow, and the term has been passed along through a causal chain.

Likewise, the W3C dubbed an h1 element in an HTML 4 document as the most important level of a heading element, defining a heading element as something that briefly describes the topic of the section it introduces. This was then passed through a causal chain to the makers of the browsers we use and the people who make websites. The browser makers each decided to display, or describe, this a little bit differently to it's users, but that description difference does not determine the semantics of the element: the spec does.

Having said that, I also have to acknowledge a complexity that I believe motivates your position. Some structures do deliver their semantics visually. As you said, a paragraph is a great example. So are line breaks in a poem. The W3C acknowledges this fact, and provides elements such as the p element and br element, and has taken steps to explicitly address this difficutly in the HTML 5 Specs.

To summarize, just because some the semantics of some elements are inherently tied to their visual presentation does not mean that the semantics of HTML are primarily determined by the visual presentation of each instance of being rendered by a browser. They are determined by the spec, and only by using elements properly can we make the vision of a semantic web possible. Everyone benefits and will benefit from a semantic web: clients, designers, and developers alike.

> I can call a large, four-legged, bovine, milk-producing mammal a giraffe, but that doesn't make it a giraffe.

No, but if enough people start to call a cow a giraffe it can change the meaning of the word "giraffe". This sort of thing happens all the time. At one time "gay" meant "happy" and "queer" meant odd. Now both words mean "homosexual". At one time a "computer" was a job description for a human. Now it is an artifact. The meanings of words -- and HTML tags -- is fluid, and depends entirely on how they are used, not on what a standards body says. Of course, what a standards body says can influence how they are used, like in the case of the H1 tag. But when push comes to shove, usage trumps fiat.

Imagine a time before the term "italic" was invented. A couple of guys were standing around their printing press saying "can you lean the top of those letters to the right a little bit?" Now we just say "italic."

Their communication was ineffective. By adopting a standard term for "lean it to the right" they become more efficient, better communicators, arguably more intelligent, and they provide something useful for others to define what "lean it to the right" means.

Maybe a semantic web will never happen but the pursuit of it undoubtedly provides some benefit for the future web.

This... Was interesting. Not that I agree, mind you (I instead find tables-based layouts impossible to handle), but quite provocative.First, why do you have to spread a layout in top, bottom, left, right, center left, center right? If your page contains a "first heading", a "menu", a "baseline", a "main content", a "shortcuts" section, then it is semantically correct to call these as such and mark them up in HTML - and then, you position them using CSS.

With this technique, I cover IE 7/8, Firefox, Safari, Chrome, Opera, in short pretty much all current browsrs; I can also make use of fluid design or fixed width design at will, and change stylesheets whenever I want (let's say I decide to add a "newsflash" section, taking up screen space from the "shortcuts" section: I change one line of CSS here, add a CSS line there, all done!)

Of course, you'll tell me that IE 6 will cause problems. Newsflash: due to the way IE 6 handles images in tables, how it handles tables (you can't make use of innerHTML on a table element, for example) and how it renders them (table must be closed before it is displayed), it actually makes table based layouts more limiting than CSS layouts in IE 6.

Said IE 6 (and even 5.0 and 5.5) can be fixed with a few lines of MS-specific Jscript, while the design can degrade gracefully with older browsers (for those odd Netscape 4 users out there).

The accessibility problem is real: put your content inside a table, lose most users with disabilities, and lose Google points. This must be added on top of printing, hand-held devices support and lower AJAX support (AJAX makes heavy use of innerHTML, see).

> it is semantically correct to call these as such and mark them up in HTML - and then, you position them using CSS.

Yes, of course. That would be great -- if it actually worked. The problem is, it doesn't work, at least not according to my personal quality metric. It's a huge effort to create a three-column layout in CSS that doesn't look like crap, and even if you manage to do it the result is invariably extremely fragile.

> put your content inside a table, lose most users with disabilities

That is far from clear. I just did a Google search on "html accessibility tables" and got a zillion pages on how to make tables accessible. Even the W3C's own web site says you can make accessible web sites using tables as long as you adhere to certain constraints.

Show me a liquid, 3 column layout that works (does not cause columns to overlap and spill into each other when you resize, columns stretch to the footer) in IE 5.5 - IE 8 and Firefox 2.0 -3.0 and Safari that is totally CSS based and I will eat my cats, and I love my cats.

Your example of the use of the word "niggard" as opposed to the word "miser" is interesting. Surely because of the number of people who would know what a niggard is and the potential offense that could be caused to someone who didn't or might mishear you would choose to say miser instead. Far more people know what a miser is.

So by the same logic, using semantically correct markup that is easily readable by search bots, users of assistive technologies and regular browser users is better to use than tables which are significantly less useful to two of those three user groups.

Also you say that there are ways of using tables in an accessible manner, which is true although I doubt it is true if those tables are being used for layout. Tables can be very accessible when used for what they were designed for: tabular data.

Finally, tabular layouts are hopeless when you're trying to select text to copy.

> So by the same logic, using semantically correct markup that is easily readable by search bots, users of assistive technologies and regular browser users is better to use than tables which are significantly less useful to two of those three user groups.

a SPAN shouldn't contain a block element. a TABLE is a block element (this is now enforced even in IE, a table in a paragraph closes the paragraph).

Using a hidden SPAN is a workaround for a specific browser failure; using tables for layout is a workaround for improper CSS support (browser or page maker). So, using a hidden span for a table used for layout is a workaround for a workaround!

This 'minor quibble', as you say, is actually an artificial limitation that you encounter time and again when using tables; another one is the arbitrary positioning of a box in an area, which, in table-based layouts, requires tables inside tables, and don't allow layers.

CSS is much more flexible here. Since mixing table layouts and CSS positioning is more often than not a lot of trouble, doing CSS-only layouts ends up being more simple than mixing them, and more flexible than purely table-based.

About HTML nodes semantics: frankly, pretty much all there is to say here can be found in the HTML 4.01 Strict rationale compared with HTML 3.2, Mozilla's Gecko 1.0 specifications or MSDN's documentation.

There ARE CSS Nazis, those that won't use tables even to display tabular data (that's stupid), and older browsers don't handle CSS very well; there are known, proven, and working non-hacky solutions for that (@import comes to mind).

Your point about 'I' and 'EM' tags, that 'EM' is irrelevant and a waste of bits, can be resumed as such:

If you tell a blind user that said text is in italics, he'll answer: what's italics? No, there is no Braille italics. If you tell him there is emphasis on said text, he'll get it (think screen reader). This is actually the 'raison d'être' of italics - EM is broader than I, eventhough in a graphical browser (for your eyes only) both appear the same way.

Also note that IE 6 causes strange behavior with italics texts (expanded boxes causing scrollbars), and as such you often end up having to not use italics in IE - saying something like em {text-style:normal; color:#00F} won't be nonsense (italics are blue text, not a tilted font?), it will be a different typographical convention (emphasis is written in blue). It will also work better for fonts that are naturally tilted.

The point of putting the table in the span was not to get it to display inline, it was just to create a DOM node whose innerHTML you could replace in order to emulate replacing the table's content, which IE doesn't support. It is a workaround, but it is not the workaround you think it is. :-) I probably should have said DIV instead of SPAN, but I was in a hurry.

@Ron: unfortunately, innerHTML wouldn't 'remove' the SPAN, it would put the table inside of it (which would be wrong, as SPAN shouldn't contain a block element like a TABLE), and indeed a DIV would be better, but you would then end up with a case of DIV-itis (senseless DIVs all over the place).

On the other hand, creating an empty UL, filling it with innerHTML (or standard DOM methods, take your pick) with a series of LI that also contain children (since LI can contain both inline and block-level elements) and setting their CSS to table-cell and table-row where appropriate would:1 - re-create a table-like layout on graphical browsers (but retaining advanced CSS positioning abilities),2 - retain a semantically correct list for non-graphic/text only/sound only browsers.3 - as soon as the UL is filled with LI elements, it has a sense; moreover, an empty UL does mean in markup 'a list goes there, expect a list' - while a nameless DIV means 'something, I dunno what, goes there'.

If only for code readability, this single use removes the need for many comments.

@RFGoku: yeah? So what? - if I don't feel like creating a workaround, I can let the system fall back gracefully. - if I do feel like writing a workaround, I use a conditional statement loading an IE-specific style sheet and use display:block and display:inline-block with some fixed widths.

You'll tell me, using a conditional comment to provide IE-only CSS is a workaround too. It's required anyway, as IE < 8 deviate too much from the standard to use it without workarounds. The advantage of conditional comments: - they do not pollute the markup nor impede other browsers as they really appear as comments - with an external style sheet, bandwidth waste is minimal - with a careful set of conditions, it's forward-looking: setting [if IE lte 7] does consider IE 8 to be CSS 2.1 compliant (and it is).

Nice thing: using a table-less design and CSS workarounds for IE failings allows the use of innerHTML on table-like data - even though IE doesn't support it!

You want to know how I know your right Ron?... because you read my mind when sharing your debates.

On top of everything, my major issue is the compliance of the browser's standards. They all render differently.

I see people telling Ron he should get off the net, I think cliche narrow minded people that are jumping off a cliff like blind sheeps should get off the net.

I started a war of my own becasue when IE8 came out and failed the test at acid 3 (google "acid 3" and hit the first link) I see that the browser writters/programmers don't care about you, or your site. They been saying that CSS was going to be awsome once all browsers had to follow a standard and render pages all the same way. Do you realize they been saying that since 2000. Almost 10 years later.... should we hold our breath? How many times must you CSS-P extremist must be hit over the head before you realize your being abused?!

@Ben: when programming 'pure' CSS (in "Standards" mode), all current browsers render the same - except when it comes to native OS widgets (heh) which CAN'T be specified by CSS since it isn't dependant upon the browser nor on the page's data.

IE 8 fails at Acid3 not because it lacks CSS support, but because Acid3 uses DOM modifications to modify its original markup until it matches the reference screen, but also uses some draft CSS3 specs.

When you say that 10 years ago everybody promised that CSS would be the panacea, that was true; it was championed by Microsoft (!) which then dropped ALL browser developments between 2001 and 2006.

Now, see which browser is late to the game. Because, if you use "modern" CSS now, chances are it'll work properly (or fallback gracefully) in Mozilla Suite 1.0rc2 - out in 2002. It will also probably work properly in Opera 7.

But it will go ka-boom in IE 6, and probably display horrendously in IE 7.

No, but if enough people start to call a cow a giraffe it can change the meaning of the word "giraffe". This sort of thing happens all the time. At one time "gay" meant "happy" and "queer" meant odd. Now both words mean "homosexual". At one time a "computer" was a job description for a human. Now it is an artifact. The meanings of words -- and HTML tags -- is fluid, and depends entirely on how they are used, not on what a standards body says. Of course, what a standards body says can influence how they are used, like in the case of the H1 tag. But when push comes to shove, usage trumps fiat.

if enough people started calling cows giraffes, we'd eventually change the dictionary entry.

I would argue that @Matt has you beat and you're just playing devil's advocate at this point to keep the conversation going.

From a technical perspective, your issue with three-column layouts have plenty of prior art to prove you wrong.

Tables aren't going to replace CSS for layout as far as the HTML specification is concerned.

Tables are for tabular data. So sayeth the W3C and the majority of the web developers out there.

If you have issue with that, you're going to have to come up with a far more reasoned and compelling explanation as to why. Backing into esoteric relevatism doesn't fly on a panel of engineers.

I've been developing web site for 12 years and still layout using tables. It's far faster, easier, renders better in all browsers, less code and just as fast at render than CSS.

I do know CSS (not expert) and use it to control the formatting of my content on the site and some shared styles. I think the right mix is important and going all or nothing with any technology is stupid.

So, my vote is that a simple table layout is BETTER than CSS. I use a .net masterpage as a template so I only have one page to format and upload upon change. CSS brings nothing to the table for me as a layout option.

@Eric: I add a simple requirement to your website: it must be readable on a low resolution screen and with a screen reader.

Good luck doing that with even a simple page, as tables don't resize well in those cases where they are used for layout. Moreover, screen readers don't deal well with them. These arguments have been described ad nauseam, so I'll stop here.

I have several PHP master pages for different sections of my site; some are geared for images, others for pure text contents; most have several, but not all, interface elements in common.

Those interface elements are designed using CSS; by merely containing them inside identified DIVs, I only need to call them once when required to have them appear where they are needed, the way they are needed. If I ever need to redesign my whole website, even with several different master pages, I only need to rewrite a single CSS file - and be done with it.

I will add that currently, the only browser not adhering to advanced CSS positioning principles is IE 6 - so compatibility isn't much of a concern.

Finally, to conclude, using tables for layout is bad because it's always badly used: - a table should have a caption for accessibility purpose; what caption will you put on such a table? - a table should have a header and footer section: what will you put in these? - a table must have a body, and a browser usually assumes that whatever is inside a table, entails the creation of a body element. However, not all browsers reflect this change to the DOM, so navigation requires more testing and/or more convoluted programming when writing scripts. - corollary to the above, current versions of IE don't allow scripts to manipulate a table's content, and other browsers behave differently depending on the method used: using tables for design thus reduces page scripting capabilities tremendously.

So, if your website is limited in scope, not AJAX-friendly, blind people-unfriendly, doesn't run too many scripts or is incompatible with browsers you haven't tested it with, then please do use tables for layout.

Tables were designed before separating content from layout in HTML. CSS was designed to separate content from layout. It does it wrong, as pointed out in an earlier blog post by Ron.

HTML tables do what they were designed to do. CSS does not.

If what Mitch says is true, tables are less than ideal. What Ron says is true, and CSS is less than ideal. We need something better.

Also, another thing I've started wondering: since when was HTML anything but layout? We write PHP programs, or CGI scripts, or web servers, and they output HTML *as their display*. PHP or CGI provides the "content", HTML is how it does the "layout"!

@cavegeek: if you think HTML was intended to be made for layout, you are DEAD wrong: HTML was intended to store the semantics (its order, importance, and use in the hierarchy of the document) of an element first and foremost.

Case in point: a title and a paragraph. Both contain text. Some say that a title should be written with a serif font of size 14pt while paragraphs should be written in sans-serif with size 10 pt, others would rather have titles written vertically on the left hand side of the paragraphs they precede: that's layout (how it looks, how big it is, how it is presented and where it is positioned)

It doesn't take away from the fact that a title must be found chronologically before the paragraphs it introduces, and that a title is important to a document's structure. That's ALL there is to HTML! You call a sentence a title because it is the subject of the following text and illustrations, important stuff is drawn out of the text flow (emphasis, strength), lists contain elements that fit together, numbered lists do the same but set an order, a document may be divided into blocks because one is the index, another adds a precision on the document's main topic, another cites a source... (DIV's)But who is to say that an index should always be written in yellow over a blue background? And why should it be WRITTEN? Can't it be spoken? How do you translate, through speech, that because a bunch of text is written in yellow over green, it's an index?

On the other hand, if you have a text reader saying "division id:main index; content: blablabla..." Where's the green? Where's the yellow? But still, the division marked in HTML was transcribed, without loss, into a media that has NO layout whatsoever.

So how can HTML be about layout, if it can be transcribed losslessly into speech? Notice then, that CSS would say #mainindex {color:yellow;background:green} and give you the element's layout on a visual media...

PHP, ASP etc. are used to make HTML documents less redundant: before them, you had to repeat the same thing over and over in separate HTML files; PHP allows you to translate the content from a database into HTML, can be made to create an index according to what content was retrieved, can aggregate data from several sources into a single document... And generate an HTML resource.

If for example, someone asks you data about the dodo bird. What will you do? run to the library, gather a couple books and drop them on his lap, or read the relevant sections, sum them up, articulate them with titles etc. and deliver a structured exposé?

Doing the first, at work, gets you the door. Doing the last may get you a good evaluation. Well, PHP, ASP etc. are like a word processor's framework: they allow you to decide what should go where on request and then do it for you (more like a master document with programmable fields than a single page Word document, if you get my drift).

In fact, if you separate presentation and content, then PHP etc. become much easier to use: you only have to organize the content of your page with them, CSS will do the rest for you (it's always better do do without a 'if $databaseelement[value] like 'your test parameter' then echo "v p visualproperty=on v.".$databaseelement[content]."v /p v' else echo 'v p v$databaseelement[content]v /p v' and instead do 'echo "v p class="$databaseelement[value] v$databaseelement[content]v /p v"' with your CSS containing several classes with visual settings matching your PHP! A new class? No need to revise your PHP code, you merely add a value to the database and a line to the CSS (note: no need to touch your PHP), and it's stored, done and online!

Presentation elements and properties were added to tags before CSS existed, because, well, a black on white page is quite bland; but, once CSS came out, these elements and properties were removed (try adding them to an HTML 4.01 Strict page, then validate: cry).

Just because something can be read doesn't mean it doesn't have layout. I can read a book out loud too, yet people get paid to lay out books.

Looking at Wikipedia: HTML originated as a markup language. "A markup language is a set of annotations to text that describe how it is to be structured, laid out, or formatted."

Also from Wikipedia "HTML is a text and image formatting language used by web browsers to dynamically format web pages."

Now I'll argue from another tack, incase you don't like the above. Let's step away from the web, and look at the desktop. Suppose I write a program whose purpose is to display some information it got from somewhere. Somewhere I'll have something like:

doWindow(twoPaneVertical(textArea(topData),textArea(bottomData)))

Clearly that is the layout. The content is somewhere else. Yes the content is put into the layout (as leftData and rightData), but that's because the display, in this case the window manager, needs to know what text to put in something. But you'll notice that that looks basically like HTML, but with a different syntax. In fact, this could have been a PHP program using HTML as its display without any serious change.

I wish XSLT had more support. I love outputting XML (which is just serialized data), and using XSLT to have the client side translate it to HTML and CSS (the two-part display and layout language). XSLT and XML actually separate content from layout.

Good grief, didn't anybody read the original article? Yes, HTML was intended to be a markup language. Yes, CSS was intended to be able to do layout. But CSS fails operationally to do layout, at least for fluid layouts with dynamic content, and HTML succeeds. Insisting that HTML is no good for layout because some document says that it's a markup language is rather like saying that you shouldn't open a can of paint with a screwdriver because screwdrivers are meant to be used for driving screws. Tools are often useful for things other than their intended application.

Ron, I was agreeing with your original posts! I'm arguing against Mitch saying that I'm wrong about HTML being intended for layout. HTML was intended for layout initially! I'm also arguing that that made sense.

Ironically, I found it hard to read my previous post while writing it because the layout of this blog failed and gave me a teeny tiny text area so I could only see 3 words at a time.

@Ron: when you say that "But CSS fails operationally to do layout", do you mean that CSS can't be used for layout?

If that's the case, then I wonder who put pixie dusts on the fluid layouts I make, because I was pretty sure I was using CSS for them. And it must be potent pixie dust to allow my layouts to work on 800x480 screens as well as on 1920x1200 ones.

While people are paid to lay out books, they are paid to create a visual representation of a book; there are people paid to lay out a book in larger fonts, people paid to lay them out in pocket editions, and people paid to record books (audiobooks).

In short, there are several layouts possible for a single book. However, please tell me how the text of a full-size, deluxe edition of the Lord of the Rings is different from the one found in the pocket print of the same title? Would it mean that, if I read the deluxe edition, I should also read the pocket edition, because the content is different? Note: the pocket edition also contains all of Tolkien's illustrations and maps.

Still, at the start, a book was written by an author with no layout indication: only title, chapters and paragraphs were actually marked in the manuscript. Or is the manuscript not the basis for a printed book, or an audiobook?

@cavegeek: the very fact that the command is doWindow means that you use a layout-dedicated function: doWindow() is INHERENTLY a layout function, as a window can't exist outside of a _graphical_ user interface; newsflash, not all interfaces are visual.

Let's take another example.

In Javascript, what does alert(text) does? In a graphical browser, it pops up a warning in a windowed element - and please note that no browser displays a modal window identical to another browser's. In a text browser, what would it do? It could very well add a text at the bottom of the terminal screen (Lynx for example communicates interaction on the last line of the terminal): meaning would be the same, but layout is different (no more window). It could also entail a sound alert, followed by the text being read:"ALERT: text". In all cases, the function is entirely carried out and its meaning transparent to the user - whatever interface is used.

So, alert() is NOT inherently visual - just like a H1 tag's content isn't inherently text in bold Times New Roman 14pt. Nope, H1 is NOTHING MORE than a heading of first level. Typographic convention mean that it will be presented on visual medias as an independent text block from the rest of the text, with top and bottom padding (with defaults varying from browser to browser), in a larger font than 'normal' text; screen readers would mark a break before and after reading it aloud, with a different voice intonation.

In text mode browsers, headings are shown in different colors and/or shades of gray - you'll notice that text browsers don't allow layout, however well-done pages are as useful and carry as much meaning in text than in graphical mode; if HTML 4.01 Strict was inherently about layout, then this wouldn't be possible.

Note that HTML 3.2 (the version that is referred as 'Quirks mode trigger' in most browsers) does contain layout capabilities in HTML (so Wikipedia is right; HTML does, sometimes, contain layout indications); note also that all current browser makers recommend AGAINST using HTML 3.2, and similarly don't push HTML 4.01 Transitional; most recommend Strict or Frameset, and all recommend the use of CSS for layout for the most forward-looking pages.

If your page is unique (it doesn't share any aspect of its layout with another), with only few instances of each type of node (one single menu, one column, one heading, one banner), then using HTML inline properties for layout is understandable (one may find the 'style' parameter a bit cumbersome).

Personally, I don't: I was glad the day I discovered CSS to not have to remember how each browser declared fonts and colors in HTML parameters, and what colors were 'safe'. But then, to each his own.

But, if your layout is being used by several pages, then using HTML parameters becomes such an overhead that it's very cumbersome; and putting tables everywhere didn't really help.

I'll give you the following example that made me switch: I was once in charge of a website that had 400 pages based on the same static template, a pure HTML 3.2 Netscape 4 and IE 4 compliant layout. Said website weighed at 20 Mb, and each and every change made to the layout required 20 minutes (or more in case Dreamweaver crashed) to propagate to each page.

When compressed with a dictionary-based, solid-file able compression algorith, shrank to 90 Kb. It could thus be said that the only 'relevant' data (that, is, page content) must have weighed at 500 Kb at most, uncompressed. This website was rather high traffic.

Imagine the bandwidth cost, if it took a 20 Mb download to read the whole website to access only 500 Kb of relevant data.

The same website, re-done with CSS for layout, shrank to less than a megabyte total. A layout update, done in CSS, was instantaneous. It is now compatible with all major browsers, and degrades gracefully for older ones (advanced CSS disabled on browser older than IE 5 or Netscape 6, basic CSS disabled on 3rd generation browsers).

You'll tell me, I could have used PHP or whatever to store the template once, and relevant content inside a database; true (that would have reduced layout updates propagation time), but insufficient (actual traffic would still have generated 20 Mb for a full site download).

In short: for a single web page, or a set of unique ones, CSS _is_ cumbersome; but, as soon as you have to deal with a template, CSS reduces complexity and code size. If you deal with your template with a page generator, it is also extremely easy to merely identify or give a class to your HTML node, and be done with it; you can then style the object or its class through CSS - or not. Identification and class more often than not also reflet the object's ID and class in your PHP/ASP/etc. code, so it's easier to manage here too.

While HTML-based styles overhead increases linearly with code size, CSS doesn't: a single CSS stylesheet can deal with one, five, or a thousand pages similarly. You can more easily do an atomic change with HTML properties, but a change that covers a large population is what CSS is about.

It's like saying that BASIC is a better programming language than C, for example

> Personally, I don't: I was glad the day I discovered CSS to not have to remember how each browser declared fonts and colors in HTML parameters, and what colors were 'safe'. But then, to each his own.

I think you may be interpreting my position overbroadly. I distinguish between styling, which CSS is great for, and layout, where CSS leaves much to be desired IMO. Styling applies to individual elements (fonts, colors, border, etc.) Layout applies to the spatial relations between elements, i.e. "Put this next to that and make them the same height." The core problem with CSS is very simple: it cannot express relations between elements. So if you can't say "Put this next to that and make them the same height" in CSS. You can only say, "Put this here and make it so high, and put that there and make it so high" and then hope that the net result is that this and that end up next to each other and the same height. Sometimes they do, and sometimes they don't.

HTML lets you say directly "Put this next to that and make them the same height." Here's how you do it:

< table>< tr>< td>this< td>that< /table>

That's 27 bytes of overhead.

Tying this comment back to the point of the original post, this may not have been the intended semantics of the table tag, but they are the de facto operational semantics of the table tag. So until CSS expands its vocabulary to allow you to specify explicit spatial relationships between elements instead of just specifying layout constraints on individual elements and crossing your fingers I vote for using tables. For layout. For styling, definitely use CSS.

@Ron (apologies about the previous comment: re-reading it, I noticed it could sound condescending; I was actually rather embarrassed WRT my comments' length): I guess that you approach layout as organizing siblings inside a DOM tree; it's true, CSS doesn't do much positioning between siblings (at least in CSS 2.1) apart from inline, block and float.

And, well, here I agree wholeheartedly with you, if you want to organize the layout of sibling elements, then CSS is indeed less straightforward than tables (IE 7-'s limitations in selectors didn't help at all either) in classical table layouts (where you position and size elements that stand side by side or one on top of the other).

In fact, to position siblings with CSS, you need to define a parent's size and THEN position and size contained elements inside the parent. It's delicate and rather involved, that's true; in that kind of situation, tables size the parent (tbody) depending on the size of the content (tr/td/th) - but, you have to understand that most of the tables' behavior is an inheritance from the past, as they are the only block elements that adapt their sizes WRT their siblings and children; if one day, browser makers decide that tables and table elements should size themselves like other block elements (like paragraphs), you'll need to define your tables' dimensions with CSS...

Please note that it IS possible to do table-like stuff in CSS 2.1 too, with the min-width property, along with some clever use of margins, padding, and floats; it requires some fiddling though, I won't deny that (that's what nth-element selectors in CSS 3 will improve).

However, you'll notice that I mentioned layout through tables as a siblings-based approach: I consider layout to be more 3-dimensional than that, as CSS is very good at positioning children elements WRT their respective parents; since the window is the original parent, there are some layouts you can do with CSS that are very complicated to do with tables (and, consequently, weren't much used at the time tables were all one had to do layout).

Since a Google search on "css layout" led me to your article at www.flownet.com/ron/css-rant.html and your opinions on markup semantics, I invite you and your readers to take a look at http://exprdev1.dca.expr.net/css-3-panels.html. This method of layout is extremely simple, works in all modern browsers, and with styles disabled the content remains semantically and syntactically intact.

I am constantly amazed by the complicated tricks people try to use with positioning just to accomplish something so simple. I'm working on a Drupal theme using this layout in order to avoid many of the headaches I've encountered in overly complicated CSS.

Not if he adds 'overflow:scroll'. Personally, I also play with min/max-width and floats to make the layout adapt to the screen's or window's dimensions (making the menu float to the top or bottom is damn useful for vertical, narrow outputs - like smarthones).

Good grief! This is like playing wack-a-mole. Every time I point out a problem with a CSS layout, someone comes along and says, "But all you have to do is X." And yet, no matter what X is, there is always another problem. This is why no two CSS advocates can agree on what X is. My patience with this game is beginning to wear thin. Overflow:scroll does NOT solve the problem. Figuring out why is left as an exercise.

Let this thing rest: there's now a way to have your cake and eat it too.

You merely need to declare a container as a table, and its children as table rows and table cells to do a table-like layout in CSS. That wasn't possible with IE 6 (which is now, for all intents and purpose, dead), but IE 7, Firefox 3 and all others can now apply table-like layout to non-table elements, including vertical aligning and parent autosizing - like in 'real' table.

This is an excellent article. I noticed two websites using HTML tables:

1) Pixar Animation Studios http://www.Pixar.com

and

2) teNriA Book Publishing http://www.teNriA.com

With the increasing capabilities of modern mobile / cell phones and tablet computers (iPad) being able to browse using fully functional internet browsers, the CSS compatibility argument is not 100% valid.

Tables were at one point used by "PROFESSIONAL" web designers for big corporations, and tables are STILL used by some big corporations (see examples above) therefore they are still valid and easier to use than CSS. This is especially useful if you have large numbers of editorial staff that need to create and update webpages fast without having to learn coding.

I maintain and fix websites for a living.Table based layouts are a PAIN: you can't use images or other inline-block elements in a table without getting a gap at the bottom - or you need to, WITH CSS, set line-height at 0 on each table cell that contains images only.The other solution is to use an Almost Standard parsing DOCTYPE - which is limiting, as you can't then enjoy the advanced validation available in Strict parsing modes, or a Quirks mode one - which SUCKS at cross browser compatibility and makes several scripts unusable.If Pixar has let the company that makes their website use tables, that's their problem. Moreover, it SUCKS at accessibility: most of their content and text is rendered as IMAGES, and is PASSIVE: no animation, no slideshows, nothing!

Yeah in addition to the comment above that mentioned Pixar.com and teNriA.com, I noticed that the BIGGEST search engine in the world GOOGLE.com uses HTML TABLES for layout!!! And so does YAHOO.com!!!

These guys are obviously top of their game and still use tables--so what does that say?

Perhaps it is all hearsay and a myth that CSS is better for SEO and that tables will put your results at the bottom of Google's search results. I use HTML tables only for layout and CSS for text styling and my websites are at No. 1 of search rankings for my subject topic.

Personally, I 100% AGREE with this BLOG author that tables are better for LAYOUT (but I do AGREE that CSS is better for TEXT STYLING)!!!

Google use tables for their front age, as they want the greatest compatibility possible with as many browsers as possible - including all Netscape 4-compatible ones found on mobiles.However, as soon as you enter one of their advanced apps (say, Gmail), then it's table-less HTML5 (DOCTYPE html without DTD) all the way.

Their message is actually: "if you have pages that are almost empty and must show where CSS isn't supported, use tables; otherwise, forget about them and use CSS."

Can't believe that this article was written nearly 2 years ago and is still pulling in comments! Also Mitch074 good point--I see that Google uses it on their homepage but not on Gmail! (hadn't noticed that before).

Well here is my take on all this...

I found this blog that has listed all the top 30 sites that still use tables for layout:

Secondly, I am not an expert at CSS / HTML or any other programming, I am an MBA with NO tech background whatsoever. However, I have written eBooks and set up websites to sell them, and because of my lack of programming skills I used KOMPOZER and tables.

My dream would be if someone created a WYSIWYG CSS software program that would let you create CSS DIVS or boxes that you could just drag and drop etc just like KOMPOZER allows you to do for tables.

I have never mastered Dreamweaver, but if anyone knows of a WYSIWYG CSS DIV (Drag n' drop) type program for absolute clueless NON-programmers I would be SO VERY GRATEFUL!

Awesome blog--loving the comments--I never realised this CSS Vs Tables topic was such a sensitive one! *WOW*

Hi it's me again (I posted the last three "ANONYMOUS" comments above).

I have some AMAZING news! Having played around with Mozilla's KOMPOZER free software, I started understanding CSS. I have now COMPLETELY changed my view from being a HTML TABLES fan to a COMPLETE CSS convert.

I have to say, after sitting down for 18 hours one day, I got to grips with the entire basics of CSS and it is SO EASY! You can change 100s of web pages in one instant and it is so powerful in terms of creating professional, layouts.

Over the last few days I learned about H1-6 headings, #Divs, z-index, positioning (absolute, relative etc), background colour and images (scroll and fixed), and so much more. I literally taught myself the entire basics of CSS in one day!

CSS is SO EASY to use and implement, and with over 76% of people using modern browsers and high resolutions, there is little need for IE5 "HACKS".

CSS is AMAZING! I now take back all the comments I made trumpeting HTML tables, I have been BLOWN AWAY by the sheer POWER of CSS! *WOW*!

Having been working with html since the html 3 days, before CSS had any decent browser support, and not bothering or caring to wrap my head around CSS until relatively recently, I've found CSS to be more of a pain for layout than the simplicity of tables.

If I need to create a framework for a layout for a website, I can throw together one in about 2 minutes and not have to worry that the table will break if too much content fills one cell.

In an effort to understand how my drupal theme organized and placed the different columns and regions, I could not figure out how the theme told the browser the order to place the regions as I wanted to move things around and add additional regions.

My best guess was that this information was found somewhere else, but my question is why? I wonder if a year later when you go back to modify this convoluted mess you created, that you'd actually remember which css file you need to change in order to make a relatively minor change. Of course, not knowing CSS beyond styling of elements will of course contribute to this, which leads to my next point:

When it takes effort to learn how something works when something viable already exists, there is no ROI of my time.

I'm wondering whether it was easier back in the day to learn the extreme and challenging complexities of tables and what they could be used for, or if I've just gotten dumber and CSS really is simpler than tables...

Considering all the extra effort you have to go through to make things work, just right, I question whether CSS is the right tool for the job of layout.

Even if tables weren't meant to be used for layout, the reality is that they can, and I have yet to see evidence that CSS does a better job at it, and in a much simpler manner than tables.

Rule #1: KISS

When it ain't broke, don't fix it.

Don't get me started on EM and STRONG. Whose idiotic idea was it to add extraneous characters to markup, for the 'descriptive' qualities of it? When I first came across EM and STRONG, I had to do a search to figure out what these meant. These terms aren't intuitive or meaningful.

In general computing the letters "B" and "I" have more meaning to represent these font styles than EM and STRONG.

Want any proof. Take a look at any word processor that has buttons to add bold and italic formatting. What do you see there? and for this example, I did search for word processor screenshots to confirm most word processors on both windows and Mac use the same characters. What's the usual shortcut key for those? Ctrl+B/Ctrl+I.

@S.Broadbent: I'll sum up your post."I know how to use tables, and I can't figure CSS. So, since I consider myself smart, and I don't understand CSS, then CSS is crap as it's too complicated".

Second, "KISS": please inform me on the way to properly align the images at the bottom of a table cell in a XML document (I do mean, a XML document, not HTML 4.01 Transitional without DTD), considering that since an image is considered as an inline-block element and a table cell contains text, it will by default align to a text line's bottom - which is not the cell's bottom.

You can't, because you don't know XML? Answer: you need to set the table cell's line-height to 0.

Oh, you don't care because, for you, Quirks Mode is the best way to build a web page. Nevermind about interoperability and consistent rendering across browsers, it's all IE to you.

Last, Word 2007 puts Styles to the front: you're provided 'emphasis' and 'strong' with nice previews right at the center of the ribbon. Here's you 'strong' button.

I guess that, on top of being unable to understand CSS, you also can't read. Or you are still using Office 2003 - which is getting a bit old. As a professional, you should at least keep yourself up to date.

@Mitch: It's about using what works, not about considering myself smart. Before coming to my previous posted opinion, I've looked at more than a few opinions on the pros and cons of both. So far I have yet to see that CSS is inherently superior to tables for layout.

Mind you, when I use tables for layout, they don't become a convoluted mess that's impossible to figure out. There's a table cell for the header/masthead, one for a left side menu (if applicable), one for the center/main content, one for a right side menu (if applicable), and finally one for the footer.

On accessibility, it's been claimed that tables are bad for accessibility. Perhaps they are, but at least for the software I use (Drupal), if I wanted accessibility, I can download a single module that detects browser/device, and redirects them to an appropriately simplified theme.

I don't believe in spending countless hours trying to make a single layout fit all possible display devices, when there are solutions to providing a layout that is optimized for a certain display.

What's the relevancy of XML in this discussion?

Quirks mode?

I've never used (or cared about) IE since I got onto the internet. Even in the era when IE and netscape were adding browser specific extensions. I started with Netscape, then moved to Firefox, and now Chrome. I occasionally use Opera when I need to test how a page looks to a person not logged into my site, and recently I installed Safari and Firefox to ensure that what I'm working on appears at least somewhat consistent across browsers.

Does emphasis and strong appear in the default layout of the formatting tool bar? To support my claim I looked specifically for screenshots of all the major programs, and I just checked for Office 2010, and no, emphasis and strong don't appear as a default. Instead, you get the perrenial "B" and "I".

Remember, the default format toolbar/layout is what most users will see and associate with when it comes to these formatting options. Your point fails if it's a user selectable option to change them to em and strong or they appear somewhere else.

Whether I may be using Office 2003 or not, the fact is that it does work and up to this point in time it handles the tasks that I need it to. Of course, I don't really use Office enough want to spend money for something that won't add productivity. At some point in time I might.

Well, considering the article these comments are attached to is about the semantics of html, and not css vs tables for layout, perhaps the comments themselves should be laid to rest, and not the article itself ;)

With that said, the comments just show that CSS isn't superior to tables when it comes to layout and anyone who wants to bury them is merely trying to hide proof that the subject is divided. Should all CSS vs tables debates disappear it would lead to people believing CSS is the only option, and thereby spend countless hours of frustration getting their design to work right.

@Mitch: It's about using what works, not about considering myself smart. Before coming to my previous posted opinion, I've looked at more than a few opinions on the pros and cons of both. So far I have yet to see that CSS is inherently superior to tables for layout.

Mind you, when I use tables for layout, they don't become a convoluted mess that's impossible to figure out. There's a table cell for the header/masthead, one for a left side menu (if applicable), one for the center/main content, one for a right side menu (if applicable), and finally one for the footer.

On accessibility, it's been claimed that tables are bad for accessibility. Perhaps they are, but at least for the software I use (Drupal), if I wanted accessibility, I can download a single module that detects browser/device, and redirects them to an appropriately simplified theme.

I don't believe in spending countless hours trying to make a single layout fit all possible display devices, when there are solutions to providing a layout that is optimized for a certain display.

What's the relevancy of XML in this discussion?

Quirks mode?

I've never used (or cared about) IE since I got onto the internet. Even in the era when IE and netscape were adding browser specific extensions. I started with Netscape, then moved to Firefox, and now Chrome. I occasionally use Opera when I need to test how a page looks to a person not logged into my site, and recently I installed Safari and Firefox to ensure that what I'm working on appears at least somewhat consistent across browsers.

Does emphasis and strong appear in the default layout of the formatting tool bar? To support my claim I looked specifically for screenshots of all the major programs, and I just checked for Office 2010, and no, emphasis and strong don't appear as a default. Instead, you get the perrenial "B" and "I".

Remember, the default format toolbar/layout is what most users will see and associate with when it comes to these formatting options. Your point fails if it's a user selectable option to change them to em and strong or they appear somewhere else.

Whether I may be using Office 2003 or not, the fact is that it does work and up to this point in time it handles the tasks that I need it to. Of course, I don't really use Office enough want to spend money for something that won't add productivity. At some point in time I might.

Well, considering the article these comments are attached to is about the semantics of html, and not css vs tables for layout, perhaps the comments themselves should be laid to rest, and not the article itself ;)

With that said, the comments just show that CSS isn't superior to tables when it comes to layout and anyone who wants to bury them is merely trying to hide proof that the subject is divided. Should all CSS vs tables debates disappear it would lead to people believing CSS is the only option, and thereby spend countless hours of frustration getting their design to work right.

I think we should perhaps specify exactly what HTML and CSS successfully accomplish and what they don't. HTML is good at logically (or "semantically") representing hypertext and CSS is good at styling flowed HTML elements. CSS is awful at expressing layout; so awful, in fact, that I think such attempts should be considered just as "hackish" as using table-based layouts.

As we all know, when Tim Berners-Lee invented the web in 1993, he simply wanted to share with others on the Internet marked up hypertext documents. He defined a set of tags that reasonably reflected what he thought should be in a hypertext document. Clearly he left some things off, but HTML 0.1 worked. HTML quickly evolved to include those elements. This is so true that even Google Docs uses HTML as its internal representation of word-processing documents, and the tag set is basically HTML 3.02. Reader's Digest version: HTML is really, really, really good at expressing linked text documents.

HTML, however, was ugly with the default renderings. Plus, adding "font" tags everywhere cluttered the markup and made change nearly impossible. Thus, CSS was created as a way to make formatting text documents easier and more modular. The basic idea behind the original CSS was that each element would be rendered in an almost linear, flow-like fashion, just like in documents. CSS concerned itself with inline style and block, much like any good document editing software. CSS also allowed users to define how the flow should behave around "boxes" - this is where we got the wonderful 'float' and 'clear' properties. For these problems, CSS was a really, really good solution at adding modular and fairly granular style to hypertext documents.

For reasons I will never understand, the CSS designers didn't quit while they were ahead, but instead kept going. Trying to make CSS a panacea of problem solving, they introduced a new set of flimsy position properties and other layout properties that are, quite frankly, bizarre. Likewise, web designers saw the power of CSS at accomplishing tasks at which CSS is really, really good and made the fallacious assumption that CSS must therefore be good at layout as well. The omniscient, benevolent CSS designers SHOULD have come up with a layout language, but instead added a bunch of crap to CSS that IMHO weakened it.

HTML is today powerful enough to describe all web applications' features needs to be described in these applications. Unfortunately, CSS is beyond broken with respect to layout. "Misusing" HTML elements is sometimes the only solution. However, I don't think CSS was *originally* intended to be the panacea as it is treated today. Someone who uses {margin:auto;} is just as guilty of using "hacks" as someone who uses tables for design in my book. Hacking is necessarily about pushing the envelope to achieve what you want with what you have instead of waiting for a perfectly designed set of rules to fall from heaven. Google Maps and Gmail, which were truly revolutionary web apps when they came out, pushed the envelope and did all sorts of hackish things in their day, like using a hidden iframe to preserve back-button behavior. The processes for holding history evolved, and so Google no longer has to hack to achieve these same requirements - but they are certainly hacking in other ways to continue to push the envelope.

In time, I am sure we will develop new systems to accomplish layout more effectively. But we will never get there if we keep defending CSS as the Holy Grail of Layout. Although I find CSS as the lesser of two evils in my design work, I am highly sympathetic to the author's arguments. If more people like him had the guts to stand up and say CSS was bad at doing layout, maybe we would get something better than CSS. There is a reason we don't use Babbage's difference engine today - it sucks compared to what we have now.

@Marcus: you're right - if it were actually possible to REALLY layout a web page!

Fundamentally, you can't lay out an HTML document: its display WILL and MUST change depending on the media showing it - something as simple as a different screen size has to be taken into account.

And you've put a big finger on the problem: you can't define the position of an element WRT the media, because said media will change size. How can one put a rigid layout on something which is, by definition, fluid?

So, the only way one can define an element's position, is by setting it up in relation with: - its parent, - its siblings, - itself.

CSS 1 went ahead and styled an element by itself, and in relation with its parent; it had one huge problem then, named Netscape 4.

CSS 2(.1) refined CSS 1, adding several missing properties from CSS 1, especially those allowing table elements positioning - adding the first notions that allow an element to be positioned in relation with its siblings to CSS. It was hampered by IE 6.

The biggest hurdle one has when learning CSS is that it is NOT a layout language that allows one to say, "put this element here" - as "here" changes depending on the media, but also font metrics, the page's content changing dynamically... How can one define a layout (by definition, a static disposition) in such a situation?

Saying "fluid layout" actually is a bit of a contradiction - the goal and aim of CSS is to allow something that table-based layouts can't do, a 2.5 dimensional setup of how a page's elements interact one in relation to the others. Once one understands that, and then the dynamics of page (and text) flow on top of mere block positioning, CSS starts to make a lot more sense.

Thanks for showing why the 'tables are redundant' crew are wrong, Ron. On the 'niggard' issue, here's what I suggest: if a black person is a miser, call her a jew. If jewish, call her a niggard. Everyone else, say they're misers.

Never tell a Welshman he's welched on his debts. Call him a Scotsman. And a Scotsman, call him a CSS purist.