I still have some editing to do on older stuff and I there are still some areas of the CSS that I need to address. The pressing stuff is done, though. In the days ahead, I’ll concern myself with new stuff.

Until I get through all the old stuff (hopefully by the end of the week), please be patient.

The reason for all the changes is to help take Robertdot away from its original purpose as personal blog and move it toward my new goal for the site as a web design blog. That means I’ve purged everything, and I’ll slowly bring back content relevant to the site while letting the unneeded parts fall away.

If you’re used to keeping up with my personal life here on Robertdot, you may want to take a look at my new personal site, Robert Brodrecht’s Vanity Site.

So, keep an eye out in the coming weeks for things to get finalized and Robertdot to turn into a finished product, rather than the live beta you see now.

My main problem is that these lists are a poor excuse for content. I would ignore them (easily, since I’m not subscribed to their feeds), but people like Paul Boag love them. So, I have to notice them, even though I don’t want to.

Ok. End Poorly Written Rant.

The article goes over a brief history of Netscape. BBC left out the fact that the languishing browser has been the laughing stock of the alternative browsers for some time. The farce that was Internet Explorer Mode in Netscape 8 was the final nail in the coffin for me. Mozilla and, later, FireFox have been much better choices for alternative browsers since the Gecko rendering engine was unleashed, and Internet Explorer was arguably preferable in the Netscape 4 days (what the hell is a layer, anyway?).

Good riddance, Netscape Navigator.

Hello,
Congratulations on registering the domain: [removed for privacy]. Now is the time to establish an effective Internet presence. Domain Design Shop is an internationally recognized Web design company that specializes in marketing and branding. Our staff has assisted hundreds of companies, organizations, and individuals in achieving their goals of developing custom web sites and technology solutions.

Please click here to see our portfolio: http://www.domaindesignshop.com

Warm Regards,
DomainDesignShop.com [email: domain@domaindesignshop.com]

I’m not sure if these people are spamming me from my domain record or if they are in cahoots with GoDaddy. I’m guessing the former. I really need to set up a domains e-mail account.

So, here is this design company that spams new domain buyers in hopes that they will hire them. That is a really bad way to convince people of your services. But what the hell? I’ll take a look at their site.

I am greeted with a punch in the retina by an alarmingly green monstrosity. As usual, I look down at the bottom left of my browser at SafariTidy’s output. 6 warnings on their home page. I click to open the report. Each warning is about depreciated or proprietary attributes. The code is tag soup, and table based. None of the images have alt attributes. So far, these guys are spamming me, and showing me that the product they would provide me is complete shit.

Then I noticed that the color of the background image didn’t exactly match the background color of the document. The header image’s background color does match. So, there are all kinds of slightly different colored blocks floating around. It’s this sort of lack of attention to detail that separates the mediocre from the great. They also have a weird gray drop shadow-esque thing that I can’t figure out.

The thing that shines on their site is their logo work. I wish they would have included some one-color proofs, though. Other than that, their work isn’t particularly appealing to me. It is average, overall.

And, finally, the ISO Best Web Design 2006 badge on their site is… well, tacky. They don’t even provide a link to a press release. For all I know, it’s a stock graphic. I’ve never seen any other ISO Best Web Design badges. Since it dates the site to 2006, I’m sorry to say that the work done is not up to snuff for real professional designers. The lack of standards, offensive color scheme, and lack of attention to detail all point in the direction of Don’t Hire Me (ignoring the fact that they spammed me). In fact, they ought to be hiring me (or someone like me) to catch them up to 2005.

In mid-2003, Apple release Safari 1.0, ending the beta stage of development. The betas caused such a wave that Microsoft announced it would discontinue development of Internet Explorer for Mac (assuming they were developing it at all), and other browser developers made similar threats (i.e. Opera and Chimera). Meanwhile, other Mac browsers were reporting they would swap to WebKit. Needless to say, Mac users adopted Safari in droves, making Safari a major player in the browser space.

By 2005, however, Apple seemed to be shafting the KHTML team by not releasing patches, or releasing patches that were very difficult to merge into the main trunk, if they could be merged at all. This caused a bit of disdain in the open source development community (though Dave Hyatt queried for help on how to rectify the situation), but widely had no negative effect on Safari’s usage. Apple released WebKit, complete with version history, a few months later.

WebKit even crossed into the mobile space. The acclaimed WebKit-based Series 60 web browser from Nokia was released as open source, proving that WebKit was a viable rendering engine for mobile devices. Recently, Apple released the iPhone, which, of course, has a WebKit browser included. Safari Mobile builds on the concepts of the Series 60 browser, but easily one-ups it.

Yet, all this time, KHTML and WebKit have diverged, and were predicted never to merge. This prophecy held true. Recently, KDE decided to adopt WebKit and eventually remove KHTML after some final KHTML features are ported into WebKit. With recent additions to the WebKit family (e.g., Safari for Windows, Abrowse, Epiphany, and Adobe’s Air), all the major, graphical, desktop browsers will be united under the four major rendering engines (the others being the Internet Explorer Trident family, Gecko, and Opera). Also, TrollTech will bring WebKit into QT, which will allow the use of cross-platform WebKit integration with relative ease, hopefully countering the use of Internet Explorer’s engine in Microsoft’s development environments. I doubt this will swing WebKit to a much higher rank, but it certainly bodes well for the longevity of the project.

My main concern comes from the WHATWG’s lack of DTD specification in the DOCTYPE. WHATWG proposes that HTML 5 use <!DOCTYPE html> as the DOCTYPE because browsers don’t care about DTDs. The only reason they include a DOCTYPE is to alert browsers to use standards mode (and DOCTYPE isn’t used in HTML 5 if the page is sent as XML). I think this was short sighted.¹ WHATWG is essentially forking HTML. They made the false assumption that there would be no competing HTML standard. Since browsers would implement WHATWG’s HTML 5, they could take shortcuts. If the WHATWG can fork it, anyone else can.

Now there is a competing standard in the works from W3C. The W3C charter suggests that the W3C HTML Working Group will try to converge with the WHATWG’s HTML. They key word is try. They didn’t promise compatibility.

Can there be standards with multiple varying recommendations? I think so. That is what DTDs are for. The designer can even write his own DTD if he would like to define his own elements. This isn’t typically done, but it can be. WHATWG’s reasoning is that HTML 5 is no longer an application of SGML, but defines its own syntax. That’s all well and good, but DTDs at least gave us a way to determine what version of HTML to use, even if it was for our own personal standardizing. Declaring the use of the HTML 3.2 DTD, no matter what version of HTML the browser actually renders against, guarantees that the author attempted to make an HTML 3.2 document. If any problems are introduced (e.g. depreciated elements), at least it isn’t the author’s fault. After all, this standards thing is, in part, about future proofing and there is something to be said about not being on the bleeding edge.

The problem is that if the W3C departs from the WHATWG’s recommendation and agrees to the lack of DTD, there is no way to pick which version of HTML 5 you want (WHATWG’s or W3C’s). If there was some way to sniff DTDs, the designer could tell the browser which to use. WHATWG has ruled that out because, currently, browsers don’t care about DTDs / HTML 5 is not SGML.

Once upon a time, browsers didn’t care about DOCTYPE (as far as I know). When it became necessary to differentiate between standards mode and quirksmode, the DOCTYPE became important. If it becomes necessary to differentiate between versions of HTML 5, browsers may start to care about DTDs.

I imagine the reply to my concern would be, Browsers will support both recommendations, ultimately resulting in a better hybrid implementation of both WHATWG’s and W3C’s recommendations. This reasoning would work if, for example, WHATWG supported the footer element and W3C did not. The designer could still use the footer element, even though it technically isn’t part of the traditional web standards view (that is, the W3C created standards), and have global browser support (e.g. innerHTML in JavaScript is supported across all browsers, even though it isn’t in the ECMA standard²). However, this isn’t ideal. There are reasons to use particular recommendations (e.g. future proofing and avoiding proprietary elements). For longevity, picking a particular recommendation and sticking to it would be good practice, even if browsers supported the hybrid model. For argument’s sake, however, using the hybrid model in this instance isn’t problematic.

The problem will come when the two specifications differ on how to implement a particular element. While it is not the exact same case, compare the Internet Explorer box model to the standard box model. If, for example, WHATWG described something like the Internet Explorer box model, and W3C described something like the standard box model, how would the browser know what to choose? It wouldn’t unless it sniffed the entire DOCTYPE tag. Assuming the W3C keeps the DTD, a special case would have to be coded for WHATWG’s HTML that says something like, If there is a DOCTYPE but no DTD, assume it is the WHATWG’s version of HTML. Again, this isn’t ideal, but it would work. If W3C decides that the DTD isn’t necessary either, there would be no way to determine what the author wanted to use, resulting in a great deal of confusion.

Again, some may reply, Browsers will support both recommendations, ultimately resulting in a better hybrid implementation of both WHATWG’s and W3C’s recommendations. Presumably, this would eventually trickle up to the two recommendations resulting in normalizing the two documents. Again, I’ll reference the box model. The Internet Explorer team implemented the box model one way. Everyone else implemented it the other way. It was years before the two became congruent (if they even are yet). Until the two documents become normalized based on browser implementations, there will be confusion and incompatibility (aka instability). Further, it has never been a good idea for browser makers to decide what should be standard. If it were, we may have both LAYERs and DIVs. We’d have proprietary filters in our CSS and parts of CSS 2 would have to be axed completely because browsers don’t support them. It’s the job of the standards body / bodies to tell the browsers what they ought to do. It’s not the job of the browser implementation to dictate what standards ought to be.

Simply put, I’m worried about how WHATWG’s HTML and W3C’s HTML will interoperate. It could easily work out, but there could be problems just as easily. Luckily, WHATWG’s HTML isn’t a final recommendation and W3C hasn’t started yet. These problems can still be worked out.

1. This might be an unfair statement. They might not be short sighted. They might be looking out for developers by making it easier to use DOCTYPE. This is noble, but ends up being a problem if I’m right. The other explanation is that the WHATWG is arrogant and believes it is the only version of HTML that matters. If we were talking about the W3C, I might suggest this was the case. I’m hoping that the WHATWG doesn’t pick up on the W3C’s bad habits. I’m giving them the benefit of the doubt since I have a lot of respect for many of the members.
   ↩

2. This was proclaimed by Douglas Crockford in his talk called An Inconvenient API: The Theory of the Dom that can be seen via the Y!UI blog.
   ↩

Update: There is some discussion going on over at 456 Berea Street. Particularly of interest is how to install multiple stand alone versions of Internet Explorer. While this info can be gathered elsewhere, the feed back from the comments is useful in deciding which method to use. Plus, these are opinions from web designers rather than tech pundits. So, that is nice.

Update: Apparently someone already found a vulnerability. Some things never change.