Not sure what inspired me to do this. Maybe it was the Hand of God. But for some reason I felt moved to see how long it would take to generate a histogram of the words in the King James Bible using a modern computer. The answer turns out to be about ten minutes of coding (in Python) and a second or two of run time.
The results have some interesting features.
The King James Bible contains:
789,634 words
31,103 verses
12,808 distinct words, of which 223 are possessives. Of those 223, all but four are also found in their root form. The four possessives that are not found in their root form are "barber's", "nachon's", "stomach's", and "fisher's". (The last one is, of course, found in the plural -- seven times in fact -- but the singular "fisher" appears nowhere in the KJV.)
4046 hapax legomena, including "onions", "cries", and "moist'.
The most common word is, naturally, "the", which occurs 63,919 times. The most common word that is not a conjunction, preposition, or pronoun is "shall" with 9837 occurrences.
The word "love" occurs 310 times and "hate" 87. "Good" and "evil" are more evenly matched at 720 and 613 respectively (with "holy" adding to the margin at 611). "Lord" appears 7830 times, "God" 4442, and "Jesus" runs a distant third at 983 plus 555 occurrences of "Christ". (Interestingly for Bible-code enthusiasts, no word appears exactly 666 times. The closest are "like" and "way" flanking the Number of the Beast at 669 and 664.) "Mary" rounds out the Catholic pantheon at 54, but not all those references are to the mother of Jesus. At least twelve of the 54 are to Mary Magdalene (I say "at least" because there are some unadorned references to "Mary" that appear to my unschooled eye to be references to MM, e.g. John 12:3), and some are to an assortment of other Mary's, like Mary the sister of Martha and Mary the wife of Cleophas. If God had really intended for us to pay a lot of attention to Mary the mother of Jesus, you wouldn't know it from the histogram.
You can explore the complete list yourself here.
Saturday, February 28, 2009
Tuesday, February 24, 2009
The CSS Holy War
I'm not sure which is more striking, the fact that people are still posting comments on my CSS article, or the degree to which the discussion has come to resemble a religious one. Computer programmers talk about having religious wars about programming languages, but the term is usually understood to be at least partially tongue-in-cheek. I used to think that no one really got religious about these things. Now I'm becoming less sure.
I was really hoping to leave this topic behind but a comment posted today by someone who calls himself Pherdnut just pushed me over the edge. I happen to have a free hour between meetings, so against my better judgement I'm going to take this on yet again.
Pherdnut writes:
I never suggested anything was impossible. Go look it up. Go ahead, I'll wait.
Did you find the word "impossible"? No, you did not, because it isn't there. What is there is an explicit acknowledgement that all these things are possible:
The problem with CSS is not that it makes it impossible to do the things people want to do. The problem with CSS is that it makes it hard. There is nothing inherently flawed about the CSS approach. The problem is in the execution.
But I don't want to talk about CSS. I want to talk about the tenor of the discussion. Consider this comment:
I have not read CSS Mastery. I have read a lot of other material about CSS though, including several books, a boatload of web pages, and even some of the original source material. Does it matter that I have not read CSS Mastery? Pherdnut thinks so.
Well, actually, no, it isn't. CSS Mastery is by Andy Budd. Eric Meyer wrote a book called "CSS: The Definitive Guide."
How can I trust your assurances when you can't even get the most basic facts straight?
(UPDATE: I made an inadvertent but crucial edit in the above exchange. Pherdnut's full quote was, "I recommend CSS Mastery, which gets straight to a lot of the stuff that confuses people about CSS and also the CSS pocket reference which very quickly gets to the point when it comes to the specifics of how things are rendered (or supposed to be rendered) by the browsers. It's by Eric Meyer." The CSS pocket reference is indeed by Eric Meyer. This was simply an oversight on my part. I just missed the second reference, and thought the whole passage was talking about one book. I regret the error, but I stand by the substance of this post.)
But the question I want to ask is not whether or not "CSS Mastery" or "CSS: The Definitive Guide" or any of the other 41,803 results from an Amazon book search for "CSS" is a higher quality source of information about CSS than any of the sources I've actually relied on to date. The question I want to ask is: how is someone who doesn't know CSS supposed to know? Let us suppose for the moment that everything I've read about CSS (including the original source material from the W3C) is crap, and only Eric Meyer (or is it Andy Budd?) can show me the One True CSS Way. How fortunate it is that Pherdnut came along to set me right! What would I have done without him? Among the over 1000 comments that this post has generated in various venues, not a single person suggested either book before now. If not for Pherdnut, I might never have seen the light.
I submit that that in an of itself is a problem. But that's not what I want to talk about either. What I want to talk about is the form of the argument, which is something along the lines of, "Your conclusions about CSS are wrong because you do not have the necessary information."
On its face this doesn't seem altogether unreasonable, but in fact it is a very problematic argument. How much information is enough, and how can you tell? Suppose I read Meyer and I still believed that on balance tables ought to be used for layout. What then? Would someone else come along and say, "Oh, don't listen to that Pherdnut character, he's a moron, and so is Meyer. The person you really want to read is Arglebargle. He'll set you straight."
Notice how similar in structure this line of reasoning is to a truly religious argument: God doesn't answer your prayers? That doesn't prove that God doesn't exist, it just shows that you don't have enough faith, or haven't read the proper holy text. Maybe if you believed just a little harder next time...
Such arguments can never be answered, because there's no way to prove that you've attained a level of faith/knowledge that would falsify the hypothesis. No amount of unanswered prayers will ever disprove the existence of God to a true believer. Likewise, no demonstration of difficulty will ever convince the CSS true believer that there's a problem. The cause will always lie in the person experiencing the problem because there will always be some book he hasn't read or some technique or hack he hasn't mastered.
I think the reason that my original CSS rant got so much attention is not necessarily because I'm right but because I introduced some actual facts into the discussion, and nothing is more threatening to the true believer than facts. Notably, that claim is a hypothesis that can be tested by introducing some more facts into the discussion and observing the responses. Let's give it a try, shall we? Here are some more facts:
1. It has been claimed by the CSS true believers that using tables for layout is bad for SEO. You would think that if this were true, Google would say so on their webmaster guidelines, but they don't. In fact, the only reference to CSS and tables that I could find on Google is this entry from the Google blog:
Note that this is not an admonition against tables, it's an admonition against deeply nested tables, which is an admonition that I thoroughly endorse.
There's another bit of evidence that the tables-destroy-SEO argument is bogus, and that is that if it were true there would be an absolutely trivial fix that Google could implement: simply standardize a class identifier that indicates that a table is being used for layout, e.g.:
I submit that the reason they don't do this is because there isn't actually a problem to be solved.
2. A second claim made by the CSS true believers is that tables make a site inaccessible. But the W3C's own guidelines on accessibility say nothing about this, nor do the W3C recommendations on the use of tables have any mention of this. To the contrary, the latter page provides a few specific recommendations on how to make tables accessible to non-visual user agents.
Oh, and if that wasn't enough to convince you that the W3C doesn't agree with the CSS fanatics, check out their quick reference to Web Content Accessibility Guidelines. There you will find a whole pile of recommendations on how to make web sites accessible, including specific recommendations for using tables. There's also this:
You'd think that if tables were so inherently awful the W3C would have given this item more attention.
You can actually test the effect of tables on accessibility yourself. There are publicly accessible screen readers out there. Pick one and run a table through it and you can see for yourself how bad the "problem" really is.
Let the experiment begin.
I was really hoping to leave this topic behind but a comment posted today by someone who calls himself Pherdnut just pushed me over the edge. I happen to have a free hour between meetings, so against my better judgement I'm going to take this on yet again.
Pherdnut writes:
This would have been a better argument if:
What you suggest is impossible wasn't possible.
I never suggested anything was impossible. Go look it up. Go ahead, I'll wait.
Did you find the word "impossible"? No, you did not, because it isn't there. What is there is an explicit acknowledgement that all these things are possible:
Of course, all of these things can be fixed. But the point is they have to be fixed!
...
It [creating a three-column layout that doesn't have one of the many problems I cited] may be possible. I don't have a mathematical proof that it's not.
The problem with CSS is not that it makes it impossible to do the things people want to do. The problem with CSS is that it makes it hard. There is nothing inherently flawed about the CSS approach. The problem is in the execution.
But I don't want to talk about CSS. I want to talk about the tenor of the discussion. Consider this comment:
I recommend CSS Mastery, which gets straight to a lot of the stuff that confuses people about CSS...
I have not read CSS Mastery. I have read a lot of other material about CSS though, including several books, a boatload of web pages, and even some of the original source material. Does it matter that I have not read CSS Mastery? Pherdnut thinks so.
It's by Eric Meyer.
Well, actually, no, it isn't. CSS Mastery is by Andy Budd. Eric Meyer wrote a book called "CSS: The Definitive Guide."
I can assure that he knows a lot more CSS than whoever hacked together those tutorials you linked to.
How can I trust your assurances when you can't even get the most basic facts straight?
(UPDATE: I made an inadvertent but crucial edit in the above exchange. Pherdnut's full quote was, "I recommend CSS Mastery, which gets straight to a lot of the stuff that confuses people about CSS and also the CSS pocket reference which very quickly gets to the point when it comes to the specifics of how things are rendered (or supposed to be rendered) by the browsers. It's by Eric Meyer." The CSS pocket reference is indeed by Eric Meyer. This was simply an oversight on my part. I just missed the second reference, and thought the whole passage was talking about one book. I regret the error, but I stand by the substance of this post.)
But the question I want to ask is not whether or not "CSS Mastery" or "CSS: The Definitive Guide" or any of the other 41,803 results from an Amazon book search for "CSS" is a higher quality source of information about CSS than any of the sources I've actually relied on to date. The question I want to ask is: how is someone who doesn't know CSS supposed to know? Let us suppose for the moment that everything I've read about CSS (including the original source material from the W3C) is crap, and only Eric Meyer (or is it Andy Budd?) can show me the One True CSS Way. How fortunate it is that Pherdnut came along to set me right! What would I have done without him? Among the over 1000 comments that this post has generated in various venues, not a single person suggested either book before now. If not for Pherdnut, I might never have seen the light.
I submit that that in an of itself is a problem. But that's not what I want to talk about either. What I want to talk about is the form of the argument, which is something along the lines of, "Your conclusions about CSS are wrong because you do not have the necessary information."
On its face this doesn't seem altogether unreasonable, but in fact it is a very problematic argument. How much information is enough, and how can you tell? Suppose I read Meyer and I still believed that on balance tables ought to be used for layout. What then? Would someone else come along and say, "Oh, don't listen to that Pherdnut character, he's a moron, and so is Meyer. The person you really want to read is Arglebargle. He'll set you straight."
Notice how similar in structure this line of reasoning is to a truly religious argument: God doesn't answer your prayers? That doesn't prove that God doesn't exist, it just shows that you don't have enough faith, or haven't read the proper holy text. Maybe if you believed just a little harder next time...
Such arguments can never be answered, because there's no way to prove that you've attained a level of faith/knowledge that would falsify the hypothesis. No amount of unanswered prayers will ever disprove the existence of God to a true believer. Likewise, no demonstration of difficulty will ever convince the CSS true believer that there's a problem. The cause will always lie in the person experiencing the problem because there will always be some book he hasn't read or some technique or hack he hasn't mastered.
I think the reason that my original CSS rant got so much attention is not necessarily because I'm right but because I introduced some actual facts into the discussion, and nothing is more threatening to the true believer than facts. Notably, that claim is a hypothesis that can be tested by introducing some more facts into the discussion and observing the responses. Let's give it a try, shall we? Here are some more facts:
1. It has been claimed by the CSS true believers that using tables for layout is bad for SEO. You would think that if this were true, Google would say so on their webmaster guidelines, but they don't. In fact, the only reference to CSS and tables that I could find on Google is this entry from the Google blog:
If you are using a complex, multi-column layout for most of the content on your site, you might wish to step back and analyze how you are achieving the desired effect. For example, using deeply-nested HTML tables makes it difficult to link together related pieces of text in a logical manner.
The same effect can often be achieved using CSS and logically organized <div> elements in HTML. As an added bonus, you will find that your site renders much faster as a result.
Note that this is not an admonition against tables, it's an admonition against deeply nested tables, which is an admonition that I thoroughly endorse.
There's another bit of evidence that the tables-destroy-SEO argument is bogus, and that is that if it were true there would be an absolutely trivial fix that Google could implement: simply standardize a class identifier that indicates that a table is being used for layout, e.g.:
<table class=for_layout_only>...
I submit that the reason they don't do this is because there isn't actually a problem to be solved.
2. A second claim made by the CSS true believers is that tables make a site inaccessible. But the W3C's own guidelines on accessibility say nothing about this, nor do the W3C recommendations on the use of tables have any mention of this. To the contrary, the latter page provides a few specific recommendations on how to make tables accessible to non-visual user agents.
Oh, and if that wasn't enough to convince you that the W3C doesn't agree with the CSS fanatics, check out their quick reference to Web Content Accessibility Guidelines. There you will find a whole pile of recommendations on how to make web sites accessible, including specific recommendations for using tables. There's also this:
Using CSS rather than tables for page layout (future link)
You'd think that if tables were so inherently awful the W3C would have given this item more attention.
You can actually test the effect of tables on accessibility yourself. There are publicly accessible screen readers out there. Pick one and run a table through it and you can see for yourself how bad the "problem" really is.
Let the experiment begin.
Thursday, February 19, 2009
A new look for Rondam Ramblings
I've finally updated my blog template so I could add a TipJoy button. This is more of an exercise in market research than a serious attempt to make money. This blog is not and was never intended to make money. It's just a place for me to express my opinions so that anyone who cares to know what I think can find out. But today I got a reminder email from TipJoy that I needed to pay my bill (which I did), so I thought I'd try it out. Any money I make will be donated to charity.
I've decided not to add AdSense ads, at least for now, because I'm afraid they will prove too much of a temptation to abandon my editorial independence. Also, Google has been getting kind of evil lately.
I've decided not to add AdSense ads, at least for now, because I'm afraid they will prove too much of a temptation to abandon my editorial independence. Also, Google has been getting kind of evil lately.
Thursday, February 05, 2009
CSS: the last word (I hope)
The flood of comments on my CSS versus tables rant has finally died down to a trickle. The final tally (as of 9 AM PST) was 146 on Hacker News, 198 on Rondam Ramblings, and a whopping 716 on Reddit (plus 921 karma points for Nicou). That smashed my previous record by a factor of four! There were also ~250 comments on my followup piece. Yowza! I wish I could say that I read every comment, but I didn't. After a while they started to get a little repetitive, and the ad hominem attacks in particular started to get annoying. But despite the fact that I didn't respond much because of the overwhelming volume, I did read a lot of them. And I wanted to thank everyone who commented, even the ones who attacked me. Notwithstanding accusations to the contrary, I did not write the piece as a publicity stunt. You will notice there are no ads on my blog, nor on my personal web page. [UPDATE: I've added a TipJoy button just to see what happens. Any money I make will be donated to charity.] I wrote it because I thought the CSS versus tables controversy could benefit from the injection of some actual data, and because I wanted to take a stand against what I saw as faulty arguments in favor of CSS. Nonetheless, as a writer it's always good to know that someone out there is paying attention, even if that attention is negative. So thanks to all of you.
I did want to take time to respond to some of the common themes that kept repeating themselves over and over in the comments. I doubt this will stop any of these memes from reproducing in the future, but everyone else is getting their two cents in so I figure I'm entitled.
Theme #1: CSS is hard, and you have no business expressing an opinion until you've paid your dues and spent five years learning all of the ins-and-outs.
I already addressed this point in a previous post but this theme kept showing up even in the comments to that post so apparently I was still being a little too subtle. I utterly reject this view, and not just when it comes to CSS, but in all aspects of life. This idea that only the experts have opinions worth considering is not merely wrong, it's corrosive. It is -- to cite but one example -- what got us into this economic mess. The idea that the crisis "could not have been foreseen" is absurd on its face. Not only could it have been forseen, it was foreseen. It was predicted at least as far back as 1992 and probably earlier than that. You don't have to be a rocket scientist nor an economist to see that if you spend more than you make, sooner or later you will wind up in trouble.
Likewise, you don't have to be a CSS expert to see 1) a lot of broken CSS on the web, 2) a lot of people tying themselves into knots trying to do conceptually simple things. You don't have to be an expert to know that if text is spilling out beyond div boundaries everywhere you look, and people are proving their CSS studliness by doing something as simple as a liquid three-column layout, something is wrong.
Now, tables are not perfect. Much of the criticism leveled at them is valid. But it is unsound reasoning to conclude that because tables have problems you should therefore use CSS. CSS has problems too. That makes the choice between tables and CSS a valid engineering tradeoff. My personal quality metric is that all else being equal the simpler solution wins. The situation could change as the technology landscape shifts, but right now, that calculus comes down on the side of tables. Reasonable people could disagree.
(BTW, if you are a fan of arguments from authority, you should keep in mind that just because someone chooses not to wield their credentials doesn't mean they don't have any.)
Theme #2: CSS does not really have the problems you think it has, you just need to study it more.
I anticipated this argument as well, but again people didn't seem to notice. I knew people would say this, which is why I used someone else's code to make my point. People still didn't get it. They attacked the code anyway and said that those people didn't know what they were talking about. Here's the thing: on that criterion, no one knows what they are talking about. There is not a single CSS-based solution to the "holy grail" problem that does not have some deficiency or other. The mere fact that people even talk about the "holy grail" in connection with CSS ought to tell you something.
I don't have anywhere near the time to deconstruct every putative solution to the three-column layout problem, so I'll pick just a few of my favorite examples. The first is ChristianZ, who I am choosing to pick on because his comments were particularly vituperative. He held out his website as an example of three-column layout in CSS. I must confess, I think his website is looks outstanding. Trick is, it's not done in CSS. Turn off Javascript and suddenly it doesn't look so hot.
The second is Matthew James Taylor's oft-cited solution. Once again I have to doff my hat to what is truly a heroic effort to rescue a hopeless situation. As a thought experiment you might want to ask yourself why it is that Taylor's solution (nor YUI grids, nor anything else) has not emerged as the definitive solution to the problem. If you can't come up with an answer, try this: take Taylor's "holy grail" solution and modify is so that the left and right columns are not always butted right up against the edges of the screen. (BTW, even Taylor's solution suffers from the ubiquitous CSS malady that text will spill out beyond the div boundaries if it's too wide to fit.)
Theme #3: CSS is not meant for dynamic content
This one I did not anticipate. It was not a common theme so it could be that the commenter was simply wrong. But I list it here just an case anyone else has something to say about it.
That's pretty much all I have to say on this. Thanks again to everyone who commented.
I did want to take time to respond to some of the common themes that kept repeating themselves over and over in the comments. I doubt this will stop any of these memes from reproducing in the future, but everyone else is getting their two cents in so I figure I'm entitled.
Theme #1: CSS is hard, and you have no business expressing an opinion until you've paid your dues and spent five years learning all of the ins-and-outs.
I already addressed this point in a previous post but this theme kept showing up even in the comments to that post so apparently I was still being a little too subtle. I utterly reject this view, and not just when it comes to CSS, but in all aspects of life. This idea that only the experts have opinions worth considering is not merely wrong, it's corrosive. It is -- to cite but one example -- what got us into this economic mess. The idea that the crisis "could not have been foreseen" is absurd on its face. Not only could it have been forseen, it was foreseen. It was predicted at least as far back as 1992 and probably earlier than that. You don't have to be a rocket scientist nor an economist to see that if you spend more than you make, sooner or later you will wind up in trouble.
Likewise, you don't have to be a CSS expert to see 1) a lot of broken CSS on the web, 2) a lot of people tying themselves into knots trying to do conceptually simple things. You don't have to be an expert to know that if text is spilling out beyond div boundaries everywhere you look, and people are proving their CSS studliness by doing something as simple as a liquid three-column layout, something is wrong.
Now, tables are not perfect. Much of the criticism leveled at them is valid. But it is unsound reasoning to conclude that because tables have problems you should therefore use CSS. CSS has problems too. That makes the choice between tables and CSS a valid engineering tradeoff. My personal quality metric is that all else being equal the simpler solution wins. The situation could change as the technology landscape shifts, but right now, that calculus comes down on the side of tables. Reasonable people could disagree.
(BTW, if you are a fan of arguments from authority, you should keep in mind that just because someone chooses not to wield their credentials doesn't mean they don't have any.)
Theme #2: CSS does not really have the problems you think it has, you just need to study it more.
I anticipated this argument as well, but again people didn't seem to notice. I knew people would say this, which is why I used someone else's code to make my point. People still didn't get it. They attacked the code anyway and said that those people didn't know what they were talking about. Here's the thing: on that criterion, no one knows what they are talking about. There is not a single CSS-based solution to the "holy grail" problem that does not have some deficiency or other. The mere fact that people even talk about the "holy grail" in connection with CSS ought to tell you something.
I don't have anywhere near the time to deconstruct every putative solution to the three-column layout problem, so I'll pick just a few of my favorite examples. The first is ChristianZ, who I am choosing to pick on because his comments were particularly vituperative. He held out his website as an example of three-column layout in CSS. I must confess, I think his website is looks outstanding. Trick is, it's not done in CSS. Turn off Javascript and suddenly it doesn't look so hot.
The second is Matthew James Taylor's oft-cited solution. Once again I have to doff my hat to what is truly a heroic effort to rescue a hopeless situation. As a thought experiment you might want to ask yourself why it is that Taylor's solution (nor YUI grids, nor anything else) has not emerged as the definitive solution to the problem. If you can't come up with an answer, try this: take Taylor's "holy grail" solution and modify is so that the left and right columns are not always butted right up against the edges of the screen. (BTW, even Taylor's solution suffers from the ubiquitous CSS malady that text will spill out beyond the div boundaries if it's too wide to fit.)
Theme #3: CSS is not meant for dynamic content
This one I did not anticipate. It was not a common theme so it could be that the commenter was simply wrong. But I list it here just an case anyone else has something to say about it.
That's pretty much all I have to say on this. Thanks again to everyone who commented.
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?
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?
Monday, February 02, 2009
CSS and the meaning of life
Wow, my little CSS screed seems to have really hit a nerve. In just six hours it has hit #6 on the Reddit front page (up to #5 now). I didn't even submit it to Reddit because it has been ages since I was able to get any traction over there! All those karma points, they could have been mine. Oh well.
I would love to respond to all the comments, but the volume is pretty overwhelming. But this one really stands out as my favorite:
Yes, you are an idiot.
Why mince words? I confess, I am not a CSS expert. I all but admitted as much in my piece, which is why I based my example on code that was not written by me, but by someone who holds themselves out as being a CSS expert. Maybe I'm so idiotic that I can't even tell a real expert from a snake oil salesman. But I submit that whatever the case, I am an very good company. The mere fact that the CSS wars have gone on for as long as they have is ample evidence that there are a lot of people out there who do not find CSS a model of intuitive clarity.
I don't want to re-fight the CSS wars here. Instead I want to focus on some things that surely we can all agree on, to wit -- that the CSS wars have been going on for a long time, that a lot of people have put a lot of effort into fighting them, and that very little progress has been made towards resolving the dispute -- and ask the following question: What conclusions can we draw from these observations?
One possibility, of course, is that one side is right and the other side is wrong, and that the people on the wrong side are simply dim-witted or intransigent, or both. I try (not always successfully) to take seriously the possibility that I could be wrong whenever I write anything. Maybe Dr. Howard R. Fine is right and I really am an idiot. One of the many problems with idiocy is that it does not yield readily to introspection. I take some comfort from the fact that the vast majority of the people accusing me of idiocy don't actually dispute any of the points that I made. But maybe I'm such an idiot that I'm not even worth educating (hard to tell from where I'm sitting). So the best I can do is to leave that on the table as a possibility and move on to the next option, which is, I believe, if it not a more plausible hypothesis, at least more promising as a potentially productive line of inquiry.
I humbly submit for your consideration the possibility that different people want different things out of life. It seems self-evident, but it can sometimes be surprisingly hard to wrap your brain around the fact that someone else doesn't want the same things you do. One person wants long-term maintainability while another just wants to get it done as quickly as possible. One person wants their web site to be accessible to blind people, another doesn't. One wants SEO, another doesn't care.
Underlying my conclusion that tables were the way to go was a tacitly assumed quality metric that not everyone shares. At the time I was writing I was not even consciously aware of some aspects of my own quality metric. For example, accessibility to the blind had not even entered my mind. It's just not something I have ever had to deal with, and about which I know next to nothing.
There are other aspects of my quality metric about which I was aware, but about which I was not explicit. For example, I tacitly assumed that having content spill out beyond the boundaries of its containing DIV is Bad. I think most people would agree on this and other tacit aesthetic judgements that I made, but not all would. A blind person, for example, couldn't care less where on the screen something ended up. (I'm actually guessing about this. I really know very little about how blind people navigate the web. Maybe someone can enlighten me.)
There are likewise tacit aspects of other people's quality metrics that manifest themselves in their comments. For example, a lot of people seem to think that anything that was done in the 1990's is automatically bad. It is certainly true that tables can be, and during the 90's often were, badly abused. But IMO that is no reason to throw out the baby with the bath water. It's overreactions like that that led to throwing out Lisp with the rest of AI during the 80's, a mistake from which computer engineering is still not fully recovered.
And then there is one element of my quality metric which seems to be at the heart of the controversy: I believe that computers are meant to serve people and not the other way around. That means that if something inherently simple is difficult to do, it's wrong.
Not everyone agrees with this. A surprising number of people like things to be difficult. I have never understood this, but it is a fact. Some people revel in the intellectual studliness of mastering, say, C++ template programming or x86 assembler. I don't. I think C++ is a pain in the ass. Life is short, and I would rather spend my allotted time skiing or making love to my wife than worrying about whether or not I need to define a virtual destructor in my base class in order to avoid memory leaks. And that means that when I want, say, for something to appear centered on the screen, I want to be able to do it by typing "center" rather than "margin:auto". If I can't tell a computer to center something by saying "center", then as far as I'm concerned the computer is wrong, not me.
Like I said, not everyone buys in to this worldview. I don't get it, but it is surprisingly common. I think it might have something to do with job security. I first encountered the complicated-is-beautiful mindset when I was working for NASA. I had an idea for how to simplify spacecraft sequencing and make it less error prone. I figured everyone would love it. To the contrary, the establishment fought the idea tooth-and-nail (and still does to this day). And this attitude is everywhere. It's the reason the tax code is so fucked up. It's the reason the law is so byzantine. It's the reason that languages like C++ and Perl thrive.
I like simplicity. I think the computer should have to conform to my brain and not the other way around. That's why I like tables. They are simple, and they work -- for some value of "work".
Different people have different ideas of what it means to "work". For me, the ratio of effort expended to the quality of the visual appearance on the screen is paramount. I want to put forth as little effort as possible to get something that looks decent. (Yes, I'm a lazy bum. It's my greatest strength. Laziness is a powerful motivator for finding more effective ways of doing things, and it has served me quite well.) Everything else is secondary. I don't have any blind customers. I am not in any business where SEO really matters all that much. But your situation, of course, could be different.
That said, I do believe that some of the things said in favor of CSS and against tables are just flat-out bogus, and to point out some of those was the purpose of my essay. CSS is touted as separating layout from content. It doesn't. Maybe with the new table layouts in CSS3 that will change, but one of the external constraints that I have to live with is that what I do has to work in IE6. While the popularity of IE6 is mercifully in decline, the sad fact of the matter is that it still has a significant market share, and I am not in a position to ignore that much as I would like to.
Another common thread is that "tables are for tabular data, not layout." Why? Just because they are called tables? Here's a news flash: HTML has no semantics beyond how it is rendered! (That's not quite true. Links have semantics beyond their renderings. And maybe label tags. But nothing else in HTML does.) This is the reason that the "semantic web" is still a pipe dream. HTML was supposed to have semantics, but it doesn't. Giving real semantics to a markup language is really really hard. The history of computer science is lousy with failed attempts, from KRL to SGML.
Finally, a lot of people pointed to the Zen Garden as evidence of CSS's power. I remember seeing the Zen Garden for the first time and being blown away. But if you look closely you will see that it's not really CSS that makes the Garden beautiful, it's images! Don't get me wrong, the Garden is lovely, occasionally spectacular. But how much of the loveliness is due to CSS and how much is due to photoshop is far from clear. And this is to say nothing of the fact that the Garden completely sidesteps one of the most thorny issues for CSS, namely, dealing with dynamic content. If you know ahead of time what your content is going to be it's not hard to write CSS that will make it look nice. The challenge is writing CSS that looks good if you don't know ahead of time what your content is going to be. The Garden, beautiful as it is, has nothing to say about that.
I want to point out one more thing: I am not bashing CSS. I like CSS. Its goals are the right ones, and in many ways it is well executed. You can do some really cool things with it, often without having to work very hard. But layout -- at least the three-column layout that everyone seems to want -- isn't one of them.
I would love to respond to all the comments, but the volume is pretty overwhelming. But this one really stands out as my favorite:
Yes, you are an idiot.
Why mince words? I confess, I am not a CSS expert. I all but admitted as much in my piece, which is why I based my example on code that was not written by me, but by someone who holds themselves out as being a CSS expert. Maybe I'm so idiotic that I can't even tell a real expert from a snake oil salesman. But I submit that whatever the case, I am an very good company. The mere fact that the CSS wars have gone on for as long as they have is ample evidence that there are a lot of people out there who do not find CSS a model of intuitive clarity.
I don't want to re-fight the CSS wars here. Instead I want to focus on some things that surely we can all agree on, to wit -- that the CSS wars have been going on for a long time, that a lot of people have put a lot of effort into fighting them, and that very little progress has been made towards resolving the dispute -- and ask the following question: What conclusions can we draw from these observations?
One possibility, of course, is that one side is right and the other side is wrong, and that the people on the wrong side are simply dim-witted or intransigent, or both. I try (not always successfully) to take seriously the possibility that I could be wrong whenever I write anything. Maybe Dr. Howard R. Fine is right and I really am an idiot. One of the many problems with idiocy is that it does not yield readily to introspection. I take some comfort from the fact that the vast majority of the people accusing me of idiocy don't actually dispute any of the points that I made. But maybe I'm such an idiot that I'm not even worth educating (hard to tell from where I'm sitting). So the best I can do is to leave that on the table as a possibility and move on to the next option, which is, I believe, if it not a more plausible hypothesis, at least more promising as a potentially productive line of inquiry.
I humbly submit for your consideration the possibility that different people want different things out of life. It seems self-evident, but it can sometimes be surprisingly hard to wrap your brain around the fact that someone else doesn't want the same things you do. One person wants long-term maintainability while another just wants to get it done as quickly as possible. One person wants their web site to be accessible to blind people, another doesn't. One wants SEO, another doesn't care.
Underlying my conclusion that tables were the way to go was a tacitly assumed quality metric that not everyone shares. At the time I was writing I was not even consciously aware of some aspects of my own quality metric. For example, accessibility to the blind had not even entered my mind. It's just not something I have ever had to deal with, and about which I know next to nothing.
There are other aspects of my quality metric about which I was aware, but about which I was not explicit. For example, I tacitly assumed that having content spill out beyond the boundaries of its containing DIV is Bad. I think most people would agree on this and other tacit aesthetic judgements that I made, but not all would. A blind person, for example, couldn't care less where on the screen something ended up. (I'm actually guessing about this. I really know very little about how blind people navigate the web. Maybe someone can enlighten me.)
There are likewise tacit aspects of other people's quality metrics that manifest themselves in their comments. For example, a lot of people seem to think that anything that was done in the 1990's is automatically bad. It is certainly true that tables can be, and during the 90's often were, badly abused. But IMO that is no reason to throw out the baby with the bath water. It's overreactions like that that led to throwing out Lisp with the rest of AI during the 80's, a mistake from which computer engineering is still not fully recovered.
And then there is one element of my quality metric which seems to be at the heart of the controversy: I believe that computers are meant to serve people and not the other way around. That means that if something inherently simple is difficult to do, it's wrong.
Not everyone agrees with this. A surprising number of people like things to be difficult. I have never understood this, but it is a fact. Some people revel in the intellectual studliness of mastering, say, C++ template programming or x86 assembler. I don't. I think C++ is a pain in the ass. Life is short, and I would rather spend my allotted time skiing or making love to my wife than worrying about whether or not I need to define a virtual destructor in my base class in order to avoid memory leaks. And that means that when I want, say, for something to appear centered on the screen, I want to be able to do it by typing "center" rather than "margin:auto". If I can't tell a computer to center something by saying "center", then as far as I'm concerned the computer is wrong, not me.
Like I said, not everyone buys in to this worldview. I don't get it, but it is surprisingly common. I think it might have something to do with job security. I first encountered the complicated-is-beautiful mindset when I was working for NASA. I had an idea for how to simplify spacecraft sequencing and make it less error prone. I figured everyone would love it. To the contrary, the establishment fought the idea tooth-and-nail (and still does to this day). And this attitude is everywhere. It's the reason the tax code is so fucked up. It's the reason the law is so byzantine. It's the reason that languages like C++ and Perl thrive.
I like simplicity. I think the computer should have to conform to my brain and not the other way around. That's why I like tables. They are simple, and they work -- for some value of "work".
Different people have different ideas of what it means to "work". For me, the ratio of effort expended to the quality of the visual appearance on the screen is paramount. I want to put forth as little effort as possible to get something that looks decent. (Yes, I'm a lazy bum. It's my greatest strength. Laziness is a powerful motivator for finding more effective ways of doing things, and it has served me quite well.) Everything else is secondary. I don't have any blind customers. I am not in any business where SEO really matters all that much. But your situation, of course, could be different.
That said, I do believe that some of the things said in favor of CSS and against tables are just flat-out bogus, and to point out some of those was the purpose of my essay. CSS is touted as separating layout from content. It doesn't. Maybe with the new table layouts in CSS3 that will change, but one of the external constraints that I have to live with is that what I do has to work in IE6. While the popularity of IE6 is mercifully in decline, the sad fact of the matter is that it still has a significant market share, and I am not in a position to ignore that much as I would like to.
Another common thread is that "tables are for tabular data, not layout." Why? Just because they are called tables? Here's a news flash: HTML has no semantics beyond how it is rendered! (That's not quite true. Links have semantics beyond their renderings. And maybe label tags. But nothing else in HTML does.) This is the reason that the "semantic web" is still a pipe dream. HTML was supposed to have semantics, but it doesn't. Giving real semantics to a markup language is really really hard. The history of computer science is lousy with failed attempts, from KRL to SGML.
Finally, a lot of people pointed to the Zen Garden as evidence of CSS's power. I remember seeing the Zen Garden for the first time and being blown away. But if you look closely you will see that it's not really CSS that makes the Garden beautiful, it's images! Don't get me wrong, the Garden is lovely, occasionally spectacular. But how much of the loveliness is due to CSS and how much is due to photoshop is far from clear. And this is to say nothing of the fact that the Garden completely sidesteps one of the most thorny issues for CSS, namely, dealing with dynamic content. If you know ahead of time what your content is going to be it's not hard to write CSS that will make it look nice. The challenge is writing CSS that looks good if you don't know ahead of time what your content is going to be. The Garden, beautiful as it is, has nothing to say about that.
I want to point out one more thing: I am not bashing CSS. I like CSS. Its goals are the right ones, and in many ways it is well executed. You can do some really cool things with it, often without having to work very hard. But layout -- at least the three-column layout that everyone seems to want -- isn't one of them.
Why CSS should not be used for layout
I wrote an essay about why CSS should not be used for layout. Unfortunately, I can't post it here because it relies on a whole bunch of embedded HTML and CSS. But I'm putting this entry up here in case anyone wants to comment on it.
You can also weigh in over at Hacker News.
You can also weigh in over at Hacker News.