Heikniemi Hardcoded

MSDN downloads now supports Firefox and Opera

Microsoft now supports Firefox and Opera for downloading stuff in MSDN subscriber area. I'm certainly not praising Microsoft for making a simple download service work with any browser - it should've done so a long time ago. Yet still, I do see a significant attitude shift here. Even with IE7 and all that coming out, they're actually recognizing that a group of by-heart Microsoft people such as the MSDN Subscribers has a valid desire to use other browsers.

No matter what IE7 does, it will be in a competitive position. Even though people at Microsoft (quite rightfully) seem to believe in its success, it's nice to see it not get supported by building non-compliant web sites. We're getting in a better direction, and I honestly believe it this time.

Longhorn embraces (and destroys?) RSS

IE team recently announced Longhorn's deep support for RSS. Although RSS is already getting rather common - and will be even more so by the time Longhorn hits the markets - Microsoft's move will energize the technology further. I think most of us ("us" meaning the loosely defined group of advanced Internet technology evangelists) agree it's a good move.

The point where the opinions split are Microsoft's additions to the spec, i.e. Simple List Extensions. Willie Wilson's comment on IEBlog about sums it up: "I'm really saddened that Microsoft has decided to defy standards yet again and alter RSS feeds so that they won't work in other news readers. You've done ruined Javascript; why must you go in and infect other products as well? It's like you guys are poison, destroying the veins of the Internet. Your IE-only hacks are getting old."

A more balanced view is provided by Tristan Louis. I believe the big picture is well described there: It may be questionable whether or not Microsoft's desires could've been better achieved by, for example, using Atom instead of RSS. However, so far I've seen no technically competent person blame Microsoft for the extension: it's made rather nicely in the spirit of RSS and XML namespaces. Any software development group could've done the same - now people fear market power, not the technology themselves.

Time will tell whether the SLE additions to RSS will prove useful. At the very least, comparisons to Microsoft's HTML and Javascript extensions should be avoided until we've seen some of the technology in practice. Unlike the web stuff in 90s, this one is a truly modular addition leveraging the best parts of XML technology.

What's more, Microsoft has provided a rather surprising licensing model: The Creative Commons Attribution-ShareAlike license. Read Lawrence Lessig's blog entry on this one. The commentary is particularly delightful. Paranoia rules the day?

At the loss of words

I usually don't bother posting links to The Daily WTF, no matter how ridiculous some of the postings are. But this time, I have to. The posting describes an application that passes SQL strings from one ASP page to another - using a cookie. Even by the normal WTF standards, this is... ugly.

Without starting on lengthy rants about all the possible problems with the mentioned approach, I'll make one general point. During the past two weeks I've reviewed quite a lot of code, both from in and outside our organization. I've seen both brilliant examples of truly responsible codership and totally horrifying lumps of code strung together by very fragile APIs. It's been a very demanding experience - with both patience and understanding being stretched to their limits. But it did come with lots of prizes in terms of understanding and knowledge.

This has to be the gem of all my learning: If your organization doesn't have a policy for frequent code reviews by colleagues, establish one. Most of the really horrible solutions simply stem from leaving bad code alone for too long. It doesn't matter if the reviewer isn't the Einstein of the coding world - the most important thing is having another human being evaluate the readability of the code. That, and feedback. DO IT.

XML sitemaps - so what?

Google has announced Google sitemaps, a service that allows webmasters to craft XML sitemaps to notify Google about their site structure. Another interesting move from Google. Life certainly isn't getting boring.

Why is this better than crawling? Well first, it allows the webmasters to suggest indexing intervals and notify Google about new content. That by itself allows huge enhancements in retrieval efficiency. Second, it generates a framework for passing more metadata to the search engines - in this case, Google provides the possibility for using an intra-site priority variable, allowing webmasters to further refine the indexing speed and frequency of their site (note: it doesn't allow you to affect your position on the search results). And third, it makes indexing of dynamically generated pages considerably easier.

An XML sitemap is not really a new idea - for example, Whidbey has internal support for it for the purpose of breadcrumb path and navigation menu generation - but Google's strike was well-timed. The Sitemaps technology is early enough to make people actually think about generating sitemaps for it, thus perhaps creating the de facto standard for sitemapping. Well, luckily Whidbey's sitemap reader is constructed with a provider architecture, so making the new ASP.NET controls talk to Google XML is a snap.

It'll be very interesting to see how the sitemapping stuff picks up. It won't be easy for large sites with loads of dynamic content - the task of constructing the site map is huge, and keeping it up to date may require considerable changes in existing publishing systems. On the other hand, if Google uses the technology as promised (and I believe they'll do - a good track record helps here), it'll certainly be worth serious consideration.

Accessibility for newbies

In her recent post, Heidi writes about the incomprehensibility of accessibility material on the web. To an extent, I agree. On the other hand, the concept itself is far from being cut-and-dried: Start defining accessibility for starters! While she goes on to recommend quick testing lists for accessibility, I'd be a bit more constrained on this. Of course, testing the site is by no means a bad idea, but testing without understanding the context you're working in is an entirely different thing.

The innate problem with learning accessibility is that it is not about learning a certain technique or understanding a few key concepts. It's not a module of knowledge you can easily add to your existing base of knowledge. It's more about a way of thinking and using the existing technology - and true expertise in the field is hard to gain without heavy practice. (By the way, I find the learning process to be very similar to the one in application security field!)

Just like web app security isn't about html encoding, accessibility is not about proper alt texts and tableless layouts. While those are important parts of their respective fields, they're only tools. The key is understanding human behavior and limitations. This is incredibly hard. Building architecture has had millenia to develop, but even today only few buildings are truly accessible for all groups of people!

For web sites, you can get far by getting rid of the technical hindrances. But once you have perfect textual replacements and a fully working linear layout, are you accessible? Perhaps. But for most cases (like this blog!), the problems lie in the content and its organization. Perhaps it's written in complex enough language to leave most of the population out in the cold? Perhaps the site is structured in a way that, while being technically navigable using a screen reader, actually requires a visual layout to make sense or be rememberable (i.e. usable)? Are you ready to seriously reshape your original vision of the site, or did you just want to get away with getting the technical approval from Bobby?

All that said, I agree accessibility needs demystification. There is room for good tutorials - but like many important philosophies, it cannot be properly approached from a technological point of view. Again, there's more room for useful testing metrics. Stepping into the boots of a f.e. blind person is something most people with normal vision cannot reliably do. Making a young web designer evaluate the usability of a site from the perspective of a 70-year person with little practical web experience or subject matter knowledge is... well, irresponsible.

If you can read Finnish, Jukka Korpela's book Web-suunnittelu is actually a decent example of taking accessibility into account without making too much noise about it. Once you know the basics, the W3C checklist for WAI with all its links is a good next target.

More CSS coolness

Take a look at this map with a modern CSS-enabled browser (at least IE6 and FF1.0.3 seem to work). Mouse over it. Now, perhaps that's not the greatest innovation in the world, but it certainly works for me. That particular feature (dynamically adjusting the clip property) would also be useful in demonstrations that have nothing to do with maps - anything with two different layers such as a technical drawing and a photo (or two photos, such as a human body with and without skin) would work quite nicely.

I'm still amazed with what you can do with CSS. Now we only need to get the web creators to learn all the useful stuff waiting out there.

Paving the road for CSS layouts

Not like it's really news anymore, but the IE team published some details on IE7 beta 1. Oh all right, they only said it'll have PNG alpha support as well as CSS compatibility fixes, but at least that's something the web community wanted to hear.

Putting aside the discussion on whether the new version of IE will win back converts from Firefox and Opera, I find the most interesting aspect to be the new possibilities for CSS layouts. They are quite doable already, but with IE's enhanced support, even the most stubborn table-defenders are going to have to reconsider their position. With the bugs gone, CSS layouts will no longer be the tricky magic they've used to be. Rather, they'll hopefully be an everyday alternative for projects ranging from trivial to extremely complex.

One more important aspect: The slow browser upgrade/adoption rate has traditionally been a hindrance to the evolution of browsers. I believe this particular problem is subsiding. Here the key factor is called automatic updates. Predictions are dangerous, but I'll make one: When IE7 is out, most of IE6 will vanish in a relatively short period of time. We'll then have a set of IE5.x browsers (and some IE6s too, of course) running on older platforms with less aggressive update schemes than Windows XP - and a majority of users with IE7 or Firefox. Now guess which family of browsers is going to be the next Netscape 4?

Converting your girlfriend into a CSS zealot

Can't be done? Think again! Go check out John Allsop's blog and read his girlfriend's confession on sexually transmitted CSS knowledge, the effect of accessibility arguments and all the related stuff (now you couldn't help getting curious, right?). Categorized as "funny, worth the 10 minutes".

Apart from being funny, the story does remind of certain facts: First, things such as standards often look pretty distant and irrelevant. They may be, until you come face-to-face with them the first time. And the time will come, for all of us. After that, you'll see the flaws everywhere. No wonder the attitude towards standards is often either complete ignorance or religious zeal. There are no shades of gray.

Second, simple arguments often make the difference. The tables versus CSS debate has been hashed out often enough to wear out most of the key points made by the CSS camp. But I still love that PDA/cellphone point. It's so irresistible. It has certain charm - in spite of the fact that most modern sites never lure a single PDA visitor before their next redesign. Somebody ought to craft a "How to convince your manager on CSS benefits" discussion flow chart. I'll bet a pre-written script would work just fine 90% of the time.

Thanks for the original link go out to Heidi.

IE7 - what an interesting turn

The announcement of IE7 took me by surprise. Ok, we have no tangible promises on features and "betas during the summer" isn't much said, but still - it's a Redmondian move on the browser field, first significant one after several years of sleeping.

The comments on the IE team blog entry speak volumes. Standards compliance and tabbed browsing seem to be the top requests - no surprises there. Microsoft itself only talks about security, which makes me wonder if it's just going to be IE6 SP3 with a nice name.

On the other hand, if Microsoft doesn't show its innovation muscle now, it will have a very hard time proving itself in the future. The patience of the cutting-edge web users (and developers) is growing thin. At any rate, IE7 should be a good addition to the field - it's very unlikely to be worse than IE6, and it will quite likely mean considerable improvement for those users unwilling or unable to switch browsers.

At best, IE7 will bring us something really new. I wouldn't rule out that possibility either, even in spite of the tight schedule Microsoft has put themselves into. They have surprised me before. Firefox and Opera have had competition in the marketing field, but Microsoft's passiveness has taken a lot away from the evolutionary progress of browsers. Perhaps this will change now? Prodding Microsoft to do this release seems to be one of Firefox's chief achievements so far.

Live bookmarks bring RSS to your bookmark folder

Firefox 1.0 preview release is out, and live bookmarks rock. If you don't know what they are, take a look at the previous link and the image to the right. Simply put, it's an RSS reader inside your bookmarks folder.

I need to think about this a bit more, but I believe this technology offers some great possibilities. Distributed bookmarks are just the beginning.

Spam-related, part 2

A while ago I wrote about spam filtering in MovableType. It turns out that the blog spamming bots are a bit more advanced than I expected. A simple hidden field (even with an html encoded value) didn't cut it - apparently the bots have gotten to the point of actually parsing the HTML, at least to some extent. I still believe they're hacky at best, so throwing in some SGML anomalities will probably curb them. Too bad browsers are hacky too - it's going to be another balancing run to do something that browsers will interpret correctly and spambots will be mislead.

Until I have the time to manipulate my blog templates again, I installed MT-Blacklist which seems to be quite a good temporary solution.

To change the subject to email spam, CodeProject's recent article called Avoiding spam-bots is a good example of fixing problems the wrong way. It's got exactly the same idea as I described below: Try to store data in a form that's unreachable for spambots, but that can still be useful for the normal user (browser or the human). In the example, Javascript-based encoding is used.

It hurts to read the comments: Most readers applaud the solution, but apparently without understanding the implications of requiring JS in the first place. Oh well, it's going to bite them - or their possible customers - at some point. At least they weren't talking about embedding the email address into an custom generated image.

Still, I agree spambots are an issue. Personally, I've stopped caring. I just publish my email address freely and focus the effort on filtering the spam at my mail client. So far, the combination of SpamAssassin and Thunderbird is working remarkably well. It takes me a few seconds every day to wipe the couple of spam messages getting through, but it's better than requiring everybody wanting to contact me to either have JS or manually fix my email address. Btw, the filtering ratio is at 95-97% currently, so I'm pretty happy.

Gmail is (nothing but) a good webmail

The people at Google seem to have a golden touch. They create a positive media hype with almost everything they do, including Gmail.

Every now and then they have lived up to the hype. But having used Gmail for some time now, I'm saying the biggest cool thing in it is the Google logo. Ok, you have decent threading and a lightning-fast search. However, I still have to see the person who actually uses webmail with enough mail to significantly benefit from these features. Gmail UI is good, but it's not good enough for me to switch over - I still need the richness of a native GUI app. Gmail's famous JS hacks are evolutionary, not revolutionary.

But to be honest, I don't think I've ever seen a better webmail. Gmail rocks, but it just doesn't rock enough to become an alternative to traditional desktop mail apps. Not for people like me.

Then again, if you're going to get a webmail account anyway and can get an invitation, I'll recommend Gmail anytime. Or, if you're a Linux geek, you'll certainly want it. Why, you ask? Two words: Gmail filesystem.

Firefox as the default browser: opening issues

Firefox 0.9 has a bug that causes errors of style "The system cannot find the file specified" when urls are opened using the default browser (ie. just starting a new process with the url as programname). If you're using .net, System.Diagnostics.Process.Start("http://www.heikniemi.net/") nets you a System.ComponentModel.Win32Exception from System.Diagnostics.Process.StartWithShellExecuteEx. Scary, huh?

Luckily it's just a Firefox bug, bug 246078 to be exact. It has been fixed, but at the moment no release available has the fix (apart from nightly builds). There is a 3rd party registry hack that fixes the issue.

Slightly related, Firefox has recently started opening external URIs in new windows. This is being discussed in bug 172962, and right now it looks like Firefox 1.0 is going to have a user option which allows you to select the behavior between "Last active window/tab", "New tab in last active window" and "New window". Yay!

Spam in blog comments (on MovableType)

Gerv blogged about trouble with comment spam in his weblog. I think most of us have suffered from this at some point. IP blocks tend to help with one group of spammers, but also weed out some possible real commenters. Also, IP lists are a maintenance headache.

Googling for other solutions (for the MovableType engine specifically) reveals there's a really varying bunch out there; ranging from referrer based blocking to url-based blacklisting. Including image-based keywords that a user must type before being able to add the comment. And a miscellaneous set of seven tips to avoid spam.

I'm pretty certain many of those are applicable and do their job, but so far, I'm also thinking many of them are overengineered. My theory is that there are so many MT based blogs out there that almost any non-trivial customization is sufficient to thwart most of the comment spam. Even if you just added a text field saying "Type 'foobar' into this field: [ ]" and required foobar on comment submission, I don't think most spammers would bother to create a custom rule just for your blog - it's easier to spend the energy looking for new blogs. Perhaps even just renaming mt-comments.cgi helps?

Anyway, suffering from the problem myself, I decided to start from the easy end of solution spectrum: I added a hidden field and a single-line check for its content in mt-comments.cgi. A few days into it, I haven't seen spam yet. See an older Burningbird blog entry for details.

It's quite likely that at some point an MT spam script will parse the HTML form and fill my hidden fields correctly. But that's ok, I've got a bag of tricks left even with the hidden field stuff, and once that approach is done with, I'll just throw in more logic. But until I get my first post-hack spam comment, I believe a simple solution goes pretty far here. Whichever approach you pick, the point is doing it yourself: any out-of-the-box solution will be worked around because the gain is big enough. Any personal solution is much more likely to be left alone.

Bookmarking is still a vague concept

I accidentally bumped into a W3C XForms mailing list posting by yours truly, sent back in January 2002 and strongly advocating the role of GET http method. I had no memory trace of posting something like that, but I still agree with many of the points.

Not just GET, but the message also talks about related ability to bookmark: Bookmarking is considered an essential tool for web browsing. But what is it really? Is it just storing the url for the current frame (as most browsers do it)? Or, as IE does for framesets, is it storing the frameset and the urls of pages within? For Mozilla and Firefox, you can also bookmark a group of tabs - essentially storing a few urls and their order in the tabs.

But it could be so much more: it could be about storing the position in-page, it could be about storing values of form fields, state of in-page script and external applets, cursor focus... Whatever. The bookmarking concept hasn't really evolved much since the first browsers. Meanwhile web applications have become massively complex, and any navigation help is even more necessary than it was before. If I think about the Finnish railway company's Internet ticket sales system, I certainly could use a bookmark pointing to a readily filled booking form with my basic information, usual route and so on. That's the kind of "state freeze" I'd love to see there.

As a web developer, I can easily come up with dozens of good reasons why implementing a broader concept of bookmarking is very impractical in the general case. Yet still, if it was possible for a web page to tell (via standardized markup) which elements of it are stable or relevant enough to have their contents bookmarked, considerably better implementations would be possible. And of course it would always be possible to fall back to a simpler bookmarking mechanism, ie. just the url of the current frame.

Those who think browser evolution is already at its peak couldn't be more wrong. Even fundamental concepts like bookmarks need a lot of innovation and dedication. It's great to have several serious browser projects going on again.