In light of the recent backlash against Safari’s HTML extensions, Dave Hyatt has come up with what he considers to be a reasonable solution that addresses most of the concerns and potential solutions raised by many such as Eric Meyer, and Tim Bray.
However, his solution involves extending HTML by adding an xmlns attribute, which is supposed to only be used in real XML, such as XHTML.
Seriously, what is the point of adding it to HTML? Why not just do it correctly with XHTML? I’ve heard the arguments that it’s not as easy to learn, and authors are already familiar with HTML 4.01, but I disagree.
Safari supports XHTML, and since these extensions are aimed at being used in Apple’s new Dashboard, there is no reason to follow the WHAT WG decision to be bugwards-compatible with IE, and thus extend HTML, especially when these additions are presentational, as I discussed earlier, and commented on again in Eric Meyer’s latest post on the topic.
Although Dave Hyatt does mention:
…the benefit comes when you switch to real XML. In the XML implementation, the namespace is completely real and effectively maps to a new language…
I think the Safari team should just go all the way, and implement these extensions purely as an XHTML module. Although, I would prefer that the presentational additions, such as the new composite attribute for the <img/> element were actually done as proprietary extensions to CSS. eg. -safari-composite: source-over;.
In conclusion, this is a quick fix to address recent concerns, which just isn’t quite good enough. It’s a pseudo-solution that’s come out of almost complete laziness to do things correctly!
This paragraph is probably the main reasoning:
cite=”http://weblogs.mozillazine.org/hyatt/archives/2004_07.html#005928″
“[…] Every modern browser, including Mozilla and Safari, is much worse at XHTML than at HTML. […] If you look at XHTML in both Mozilla and Safari and compare it to HTML, you’ll see that it’s slower, non-incremental, and generally buggier than HTML.”
I’ll admit I don’t know firsthand if this is true. Opera 7.11 had some interesting problems with XML processing, but I’ve seen nothing wrong in recent versions (nor have I ever really noticed any slowness). I suppose past problems are a good sign of bigger things lurking, though.
However, I fully agree with you that the argument of HTML being so very much easier on authors is bunk. There are differences between HTML and XHTML, but if authors don’t know, maybe they should learn? You have to have a solid knowledge of HTML to do a good job in the first place, anyway, so why not just raise the bar a little bit? Maybe I’m crazy, but I don’t think it’s asking too much. Then again, maybe I just don’t understand what Dashboard’s intended authoring audience is.
I’m a bit of a standards nut myself, so I definitely fall under the category of people who were a little bit concerned upon finding out about the Dashboard extensions. However, I find your conclusion to be downright silly. The very fact that Mr. Hyatt chose to detail the new extensions being developed is a clear sign that he is quite interested in working with the community. He could have simply said he’d “look into our concerns,” or even ignored the trackbacks altogether, but as you well know he quickly responded to constructive criticism with a proposed solution. It’s fine that you think a different route is better, and in fact I’m glad you’ve chosen to share your preference, but I am certain that laziness has nothing to do with Mr. Hyatt’s choice.
Yes, perhaps my comment was a bit harsh, since he is interested in working with the community. However the main reason I said that was because I don’t agree with extending a language (ie. HTML) that has been virtually obsoleted for 5 years, since XHTML became a recommendation in 1999. The only reason HTML should be used is to support legacy user agents, which Safari is not, thus any extensions can and should be done to XHTML.
Also, the solution of adding an XML namespace to HTML, which is clearly not XML just doesn’t make any sense. I’ve heard the argument that XHTML is slower to render, and it’s not incremental, but so what. These are dashboard widgets which appear to be fairly small, and thus any additional time to load would be barely noticable.
Of course, that same argument (ie. that they’re just dashboard widgets) can be used as an argument for these extensions, however if that were the case, then I would hope that they were confined to be used within the dashboard, and not allowed to work on any website outside that. If that were the case, then I would accept a new DashboardML DTD as Eric Meyer suggested.