{"id":85,"date":"2006-07-21T21:11:20","date_gmt":"2006-07-22T01:11:20","guid":{"rendered":"http:\/\/unitstep.net\/blog\/2006\/07\/21\/the-dinosaur-that-is-web-standards\/"},"modified":"2006-07-23T21:24:09","modified_gmt":"2006-07-24T01:24:09","slug":"the-dinosaur-that-is-web-standards","status":"publish","type":"post","link":"https:\/\/unitstep.net\/blog\/2006\/07\/21\/the-dinosaur-that-is-web-standards\/","title":{"rendered":"The dinosaur that is web-standards"},"content":{"rendered":"

If you’re into web design or development at all, you’ve probably run into the term “web standards” and the W3C<\/acronym><\/a><\/a>, the body whose job it is to organize and draft these specifications. The truth is, web standards are still by-and-large, just suggestions<\/em> on how to do certain things, and are as of yet, not completely<\/a> and widely followed<\/a>. This is more an artifact of the way the web and browsers have evolved, but sometimes, you gotta wonder what the W3C<\/acronym><\/a> is thinking.
\n<\/p>\n

Credit where credit’s due<\/h3>\n

To its credit, the W3C<\/acronym><\/a> has done a lot of great work. Headed by Tim Berners-Lee<\/a>, the creator of the web, it’s done good work in standardizing the data formats that encompass the Internet. Without some sort of guiding body, the web would certainly be a lot less usable than it is today. They’ve also made decent progress in updating standards as technology\/trends change, and haven’t left out accessibility for the sensory-impaired, something that should be lauded. <\/p>\n

Certainly attempting to standardize something as widespread as HTML<\/acronym>\/XHTML across something as big as the Internet is no easy task; working with the companies making the browsers must have been a hard task. After all, companies want to distinguish their product from the others; if they all support the same “standards”, what would make one better than the other? Perhaps this was the thinking during the browser wars<\/a> when companies started introducing support for non-standard elements<\/a> in order to make their browsers more appealing to users and web designers.<\/p>\n

Part of this is the reason why some pages still<\/em> render differently in IE than in Firefox or Opera. But these days, it’s mainly IE6 that’s the odd one out, with Firefox and Opera (among others) either supporting the W3C<\/acronym><\/a> standards better or completely. <\/p>\n

Competition breeds innovation<\/h3>\n

While this effort by browser makers to independently make their own<\/em> specifications often (especially in the past) resulted in broken web pages that only worked in certain browsers, once in a while, it provided browser programmers the ability to introduce a new feature that was actually of use, besides something like the marquee<\/code> tag. <\/p>\n

What I’m talking about is the XMLHttpRequest<\/code> object<\/a>, the basis for Ajax and hence a lot of the websites or web applications that you may use on a regular basis. If you’ve used Gmail, if you Digg, or if you use the new Yahoo!, you’ve benefited from Ajax and hence this non-standard web technology. While the original concept used an ActiveX object, its value was apparently seen by other browser makers, as Mozilla introduced support for their browsers back in 2002, with other browser makers following suit. (Though interestingly, Opera only gained support recently – perhaps this is related to the fact that they follow the W3C<\/acronym><\/a> specifications closer than either Mozilla or IE)<\/p>\n

Gmail’s been around for over two years, and other Ajax websites or web applications have also been in use for over a year. However, the W3C<\/acronym><\/a> published their first working draft<\/a> only back in April of this year, which is attempting to standardize a method that is already in wide use. Admittedly, it’s a valiant effort – currently, implementations differ across browsers (mostly IE in one corner, the rest-of-the-world in the other), so getting something down that everyone can agree upon is good.<\/p>\n

Too little, too late?<\/h3>\n

However, it strikes me that it took them this long to develop even a draft. And, with many JavaScript frameworks out there that already abstract the XMLHttpRequest<\/code> object in such a way that you don’t have to worry about incompatibilities, isn’t some of this work perhaps done in vain? <\/p>\n

Thankfully, there’s been some action to counter this slow reaction time. As with most standards bodies, slowness to adapt is a key problem. In fact, it’s why the W3C<\/acronym><\/a> was developed<\/a> in the first place, (ironically, it seems), in order to address the shortcomings of the IETF at the time. However, this time, the group that’s taken the helm is a not a vendor-neutral group, but instead one comprised solely of the companies and people who make browsers – the WHATWG<\/abbr><\/a>.<\/p>\n

The WHATWG is not meant to be competition for the W3C<\/acronym><\/a>; they aren’t meant to replace them. Instead, they hope that by fostering a good relationship between browser makers, good standards can be developed at a fast rate on par with development in the real world. These drafts will then be submitted to the W3C<\/acronym><\/a>, thus taking a lot of the workload off from the W3C<\/acronym><\/a>. <\/p>\n

W3C<\/acronym><\/a>-what?<\/h3>\n

The W3C<\/acronym><\/a>, which one shouldn’t remember to commend for their previous efforts, still sometimes comes up with specifications that, while looking good on paper, just don’t seem like they’ll translate into something real and usable.<\/p>\n

Take XHTML<\/acronym><\/a> 2.0<\/a>, for example. With a name like that, you’d expect it to be a successor to, and be backwards compatible, with the current version of XHTML<\/acronym><\/a>. Not so<\/a>. In favour of a stricter definition of a document, backwards compatibility<\/a> will not<\/a> be included. All the talk of making your HTML<\/acronym>\/XHTML documents validate in order to preserve backwards compatibility and to ensure forwards compatibility seems to have gone out the proverbial window. For those who were skeptical on the usefulness of web standards, XHTML<\/acronym><\/a> 2.0 must have seemed like the straw man<\/a> they were looking for – it really underlined the separation from reality that the W3C<\/acronym><\/a> seemed to taken. (Even the current versions of XHTML<\/acronym><\/a> have problems<\/a> that need to be addressed in the context of delivery over the web)<\/p>\n

Maybe it’s time<\/h3>\n

So perhaps what we needed was the WHATWG – something to keep the W3C<\/acronym><\/a> in line with reality, and to allow the speedy standardization of things that are still in the process of developing. So far, they’ve produced a few specifications, which have had an impact<\/a> on the W3C<\/acronym><\/a>. Their continued interest in text\/html<\/code> as a viable MIME type is rare; too often, people get caught up in current trends, such as the love-affair that everyone seemed to be having with XML<\/acronym><\/a> a while ago. While certain XML<\/acronym><\/a> formats are good, they do have issues<\/a> when there’s a chance the XML<\/acronym><\/a> will be hand-coded and not checked for well-formedness errors. In this case, traditional HTML<\/acronym> in the text\/html<\/code> MIME type is probably better. <\/p>\n

In conclusion, hopefully the state of web standards will be better in a few years or so. The W3C<\/acronym><\/a> has a lot of good to offer, especially when it comes to accessibility<\/a> and so forth. Combined with the helping hand of the WHATWG, things should progress for the better.<\/p>","protected":false},"excerpt":{"rendered":"

If you’re into web design or development at all, you’ve probably run into the term “web standards” and the W3C, the body whose job it is to organize and draft these specifications. The truth is, web standards are still by-and-large, just suggestions on how to do certain things, and are as of yet, not completely […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[15,39,50,2],"tags":[],"_links":{"self":[{"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/posts\/85"}],"collection":[{"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/comments?post=85"}],"version-history":[{"count":0,"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/posts\/85\/revisions"}],"wp:attachment":[{"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/media?parent=85"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/categories?post=85"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/tags?post=85"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}