Recovered from the Wayback Machine.
There is a belief that if it weren’t for the fact that the earliest versions of HTML were unstructured–full of proprietary idiosyncrasies and ill-formed markup indulged by too-loose browsers–the web wouldn’t have grown as fast as it did. Somehow, we’ve equated growth with bad and imprecise specifications rather than the more logical assumption that the growth was due to interest in an exciting new medium.
As such, we’ve carried forward into this new era in web development an almost mythical belief in bad specifications. If we wish to have growth, we think to ourselves, we mustn’t hinder the creative spirit of the users by providing overly rigorous specifications. Because of this belief, we’re still battling ill-formed, inaccessible web pages created by a legion of web page designers who picked up some pretty bad habits: namely the use of deprecated attributes and proprietary elements, as well as the use of HTML tables for everything. Well, everything that isn’t covered by the use of non-standard and proprietary Javascript–use of which results in the annoying messages that one needs a specific browser, or worse, a specific operating system in order to see this Wonderful Thing. Go away until you’re properly equipped.
What we’re finding now with web page designers today, whether they’re amateur or professional, is that it’s just as easy to learn how to do things the right way, as the wrong. What’s important is to provide good, clear documentation, as well as good, clean examples. Contrary to some expectations, adherence to standards, and precise specifications have not killed the spirit of creativity.
In the end, rather than aid the growth of the web, bad specifications slowed it down as a new generation of web pages had to be created out of the ashes generating by burning the old.
Learning how to do things right has such rewards, too. It’s knowing that your page looks good in all operating systems and most browsers; that people can easily navigate your site; that there are a hundred new tools and toys you can use now because you’re using precise and structured markup. Being able to validate a page isn’t a matter of dumping a fairly useless sticker into a sidebar; it means being able to drop in a Google map, or add in-place editing, or automatically pull your calendar out of the page, or any number of wonderfully useful and fun innovations.
We still continue with this belief, though, that to standardize or embed precision into a specification is to stifle the creative juices of the consumer of the specification: whether they be developer, designer, or end-user. Why? What can possibly lead anyone to believe that you can create good technology out of a bad specification?
Some would point to RDF and say that this is a case of a very precise specification that has not led to quick adoption. However, it isn’t surprising that there isn’t billions of RDF/XML documents scattered here and there, and it has nothing to do with the precision of the specification. Some folk didn’t, and still don’t, like the look of the externalized syntax of RDF; others felt that semantics should arise from existing elements; and still others just don’t see the need for it, and won’t until you give them an application that demonstrates this directly for them.
Oh, there’s some pieces of the RDF model we might do without, but precision is not one of them. I look at the precision of the specification of RDF with nothing but relief. I know that the work I do now with RDF follows a model that’s been carefully defined, intimately documented, and rigorously tested. I can trust the model, and know that the documents I create with RDF today will parse just as successfully as documents I’ll create five years from now; more importantly, knowing without a doubt it will mix with your data modeled in RDF.
That’s why I look with some confusion at the backlash against efforts to clarify the RSS 2.0 specification. There is no doubt–none whatsoever–that the RSS 2.0 specification, as currently written, is ambiguous; from what we’re hearing now, in comments and email lists, it is being kept deliberately so. I don’t understand this. This would be no different than to ask Microsoft not to follow standardized use of CSS in the new IE 7.x. Why on earth would anyone want this?
I am just a simple woman who works in technology. Perhaps one of you can explain it to me in such a way that I can understand.
I wrote on the ambiguity in RSS 2.0 as regards to enclosures here, and actually had to modify Molly Holzschlag’s weblog software (WordPress) because her posts with enclosures would cause tools such as Bloglines to break. These are two very popular tools; hence, the ambiguity in RSS 2.0 specification does cause problems. This is a proven fact that no amount of marketing and cheerleading can obfuscate.
Throw as much money as you want at it; write the most glowing reviews; get prestigious names to exult its beauty and power; seek to crush a non-existent enemy if you must–it is still not ‘good technology’. It may have damn good marketing, and lots of dough invested in it, and even have widespread use–but it is not good technology.
I am puzzled as to how anyone, particularly those who work in technology, could say otherwise. I await enlightenment.
