Bb's RealTech

I thought it interesting and even odd how few people have remarked on the fact that Ray Ozzie began the opening keynote of a conference focused specifically at developers by talking about ads.

My source for things geek, Planet Intertwingly, has had very few entries devoted to IE8. I imagine people either don't care or are trying things out. Or perhaps they're at ETech or on their way to SxSW. What a way to filter your audience: schedule the conferences at the same time. What sad irony that Ozzie next spoke of the Yahoo deal, as Yahoo itself was launching its latest, greatest tech initiative, which was then overshadowed by Microsoft's rolling out of the IE8 public beta.

Not to be outdone, Apple has something today probably about its SDK. All we're missing is something from Adobe, but it preferred to dance alone.

To return to IE8. One doesn't have to tax one's imagination to read the purpose behind the 'advances' in IE8. All of the new functionality is focused on Microsoft's new "cloud" agenda, including client data storage support for offline working, and back button navigation. According to the "readiness" document I linked yesterday:

Internet Explorer 8 provides a simplified yet powerful programming model for AJAX development that spans browser, webpage, and server interaction. As a result, it is easier for you to build webpages that have much better end-user experiences, are more functional, and have better performance. APIs are based on the W3C HTML 5.0 or Web Applications Working Group standards. Enhancements or novel intellectual property for AJAX will be made available for standardization before the Internet Explorer 8 release.

The thing is, HTML5 is most definitely a work in progress. What Microsoft has done is cherry picked what it wanted, implemented it, threw in its own stuff and then glossed it over by either attaching it's own bizarre "open source" license, or tossed the non-critical bits into the public domain.

The proprietary bits aside, it is typical for vendors to start implementing standards before they're finalized, as a test and a validation. Just as typically, though, the other members of the standards group are usually aware of such plans. I am curious to hear what other members of the HTML5 working group think of IE8 and the HTML5 bits.

As for me, not hard to see that I'm unhappy. I have a choice now: do I continue to serve this site using the XHTML MIME type, in which case it will never be accessible by IE (because I now believe Microsoft will never support the XHTML MIME type); or do I "break" my site by adding back content negotiation?

I wrote previously that I had a plan I was going to implement if Microsoft didn't support XHTML with IE8. In the back of my mind, I really thought the company would. Not to do so is the company saying that, for all its talk about standards and openness, it will implement only those standards that support its own agenda, and no others. While I expected this attitude, I didn't expect Microsoft to be so obvious about it.

I really didn't expect Microsoft to blow off XHTML, and now that it has, I have some work to do on my sites to follow through on my fallback plan. I'm not doing anything earth shattering, or probably all that interesting to most folks (since, seemingly, standards take a back seat to ads for today's new web developer). I'm just dealing with the situation.

I'm also investigating Drupal, as a content tool–either alone or perhaps with Wordpress. I've been interested in Drupal since I started looking through the site and the code base. I became more interested when Maki mentioned the SVG Toolkit for Drupal, and Elaine talked about how improved it is. Then Ian Davis at Nodalities mentioned Drupal's RDF and semantic web commitment yesterday, and that's all she wrote for me.

The Drupal folks seem more committed to supporting standards, all standards, than the Wordpress folk. And when I read something about Drupal, I read about the technology; I don't read about ads or mergers. This focus on technology appeals to me right now.

Though RealTech is a weblog, it's also the place where I do much of my experimentation with technology. It's the site I use to test out the plug-ins, graphics applications, and what not I'm eventually planning on using in the rest of my web sites. Normally you don't use a 'live' site to test changes, but I happen to think a live technology weblog is one of the better places to try something out. All those juicy testers.

However, one of the downsides to such effort is that the page may be challenging to access at times. Or a challenge to access at all times for IE7 and lower if it comes to that.

Another downside is that when I'm pushing one type of technology, my uses of other technologies may make it seem like the one I'm pushing is causing problems, when the reality is it could be any number of other tweaks and tricks.

As an example, I'm a big fan of SVG and XHTML. I serve my pages up as XHTML, and I use SVG inline. I write quite a bit on XHTML and SVG because I'm trying to encourage the use of both. If you access this page and it loads slowly, or seems to have other problems, you might think ithe problems are generated by my use of SVG, because it's the technology I write about the most. However, it could also just as likely be any of a number of other tweaks I'm currently trying out.

In my post Wordpress at the Top: Not, a couple of folks (Seth and Daniel) mentioned they had problems loading the page and scrolling and both thought it might be the inline SVG. It's true that in their client environments, the inline SVG could be causing the problems–especially with my use of gradients, which are quite CPU intensive.

However, a little experimentation of my own shows that problems with the scrolling could also be caused by two older technologies: the first being the use of the CSS fixed background, which no browser seems to handle efficiently; the second being the use of the JavaScript-collapsed posts.

I also use rather large images in the header, and load them as background for elements, which turns off image caching. The lack of caching and the larger image sizes, combined with the derived CSS could slow load times. However, my experiments for sampling images and deriving CSS elements rather depends on my use of the CSS background attributes for adding the images, rather than just loading them using IMG.

To determine whether it is the SVG causing problems, or my other tweaks, I've removed the fixed CSS positioning, for now, as well as the collapsed posts and optimized the images and slimmed down the code deriving the CSS. If you've noticed performance problems in the past, can you access the pages now and see if the problems you had have been eliminated?

In the meantime, in addition to the other changes I'm making to support XHTML (BTW, you'll notice that my XHTML validation of comments is too strict at this time, and will more or less give you invalid errors for any use of element attributes), I'm going to look more closely at my use of photo sampling, photo as CSS background, and what I can do to improve this type of functionality.

Then I'll probably corrupt all that hard work by experimenting around with something else new, and causing my site performance to tank. Again.

Jeff Schiller writes:

It turns out, as Shelley has mentioned, that the best developer experience to work on XHTML is also (by far) Opera. Instead of Firefox’s “yellow screen of death” we’re greeted with Opera’s “light grey screen of mild achiness”. Instead of cryptic messages about unexpected tags, the element which failed to be terminated and the tag that broke the XML parsing are highlighted for you.

Jeff just finished creating a new site design that incorporates XHML+SVG. He also did something I didn't think to do, which was submit a bug to Mozilla for the poor way Firefox manages bad XHTML. Opera really does provide a beautifully graceful way of dealing with bad XML, including an option to re-parse the page as HTML. Even Safari does a better job than Firefox.

Jeff is also using content negotiation with his site, which I don't use with this site. Because of this decision, my stats show that only 3.9% of page accesses are from IE. I do support content negotiation for my topmost site, which is accessed about 39% of the time with IE. However, I have been recently rethinking my decision to use content negotiation.

I run the risk of losing page views by serving pages up as XHTML. At the same time, though, if more of us did this, I wonder how much this would hasten the demise of browsers that don't support what is now a fairly mature standard specification?

Sometimes you have to "break the web" in order to save it.