The weird setup

• The choice of desktop OS is sort of trivial – Ubuntu 10.04 Lucid Lynx. The reasoning is simple – 99% of things just work and I’m quite familiar with it. The active community plays a large part too.
• VirtualBox as the main virtualizer. I’m already a bit familiar with it, and I like its small footprint and the fact that it is easy to setup. I also made a stupid mistake of activating my Windows 7 inside of it, before trying out other VM software. At the end of the day – with guest additions installed, it is absolutely amazing and I have no problems there. Seriously – I can watch YouTube inside Win7 inside a VM practically without glitches!
• Proxmox Virtual Environment inside the aforementioned Virtualbox. Now, some might say I’m crazy to run a VM inside a VM, but using containers is far more efficient (especially due to low RAM usage) than running real VMs. Considering OpenVZ was not included in Lucid, and LXC is by far not ready (read: I don’t have enough time to learn everything without proper documentation), Proxmox was an easy choice to make. I’m already using it in production and I’m really happy with how easy it is to setup and maintain.
• Ubuntu Lucid again, to host services (Apache, MySQL, couchdb, etc) inside OpenVZ containers. I absolutely love the minimal OpenVZ templates. The only reason I’m not going for Debian here is the fact that the releases don’t happen frequently enough for my liking. I may reconsider this down the road – but for now – Ubuntu works out for me better.

Problem 1. Proxmox didn’t like being inside VirtualBox

I downloaded the “bare metal installer” and tried to start it in a VM. All went well until the first reboot, and then it would just hang after detecting the (virtual) hard disks. Took me a couple of hours of scratching my head, until I installed pure Debian inside VirtualBox. Strangely, during installation, the hard drive was appearing as hda, but after finishing, would all of a sudden change to sda, which obviously made things go really sour.

Solution: change the IDE controller (VM properties -> Storage) from the default PIIX4 to ICH6. I have no clue what all of this means, but the resulting VM now boots fine.

Problem 2. fsck during every boot due to “last mount time in the future”

This one is simple – the VM has no access to the hardware clock, which by default is expected to be set to UTC, so your true time gets double-adjusted (once in the host, once in the guest). To fix edit /etc/default/rcS and make sure UTC=no.

Problem 3. MySQL won’t start inside Lucid inside OpenVZ

Considering that Lucid doesn’t really support being the host, or the guest of OpenVZ, this comes as no surprise and the bug is marked as “Won’t fix“. Luckily, there’s a smart guy, who has a workaround. Solution: edit /etc/init/mysql.conf to have it start on runlevel [2345], instead of the default method, which depends on networking.

I think, I now have all the ingredients to start working on the ??? part!

There is a small community that I am hosting – it has roughly 2000 members, who are pretty active. As the community does not accept any new members, the results reflect just the engagement based on page load speed. I did not really take measurements, and Webmaster Central page speed lab tool is unable to provide the numbers due to the closed nature of the community, I estimate that the average full page load time decreased from some 8-12s to 3-5s. The effect on pageviews? PLUS THIRTY FIVE PERCENT. There is no change in the number of visits (sessions), but the number of pageviews is up by a third instantly. Check out the graph:

There is one more statistically significant website that I had a chance to test. This time, the page load time decreased from 5s to 1.5s. Yet again – the pages per visit number is up by 12%. Now, here’s the best part of it all – the two websites are somewhat related (you may call them “affiliates” if you’d like). Since both of them had substantial speed improvements – the referral rate from one to the other has actually increased… threefold.

While I must say, that the actual time on site has not increased as much, the pageview count is what matters a lot if you’re participating in PPC. Funny thing, is that if you are actually participating in Google AdSense – that will be the bottleneck.

At the end of the day – the overall user experience improvement is quite immeasurable and the pleasure of having your visitors tell you “wow this is fast” is indescribable.

Worried about premature optimization? Well, it still holds true that you should only optimize where it hurts.

Results

1. Chris Heilmann’s YUI based approach (136ms)
2. Chris Heilmann’s DOM based approach (247ms)
3. Stuart Langridge’s generated-toc (258ms)
4. Josh Johnston’s solution with jQuery (781ms)
5. My own HTML5 Outliner (3099ms)
6. Chris Heilmann’s RegExp based approach (4440ms)
7. Diogo Vincenzi’s solution with jQuery (9334ms)

Methodology

The numbers above are based on an 1.5Mb file, which has some 200 headings to use for the TOC table. The actual file, was created out of HTML4 specification part on forms, to reflect a more natural usage. The results were a bit different, when I used my own generated file, which had a lot more headings, and a lot less text.

The test runner itself would create an iframe, load the test document inside, inject the required script and call it. The source is available on Google Code (though be aware, that you will need to procure and hack the dependencies yourself).

I ran it on a decent 2.2Ghz laptop, using a vanilla version of Portable Firefox 3.5. With some exceptions (see below), the results were comparable and not unexpected in other browsers.

Insights

• The RegExp based approach was a non-contender from the start, as it doesn’t really work under any browser, other than Firefox.
• Diogio’s solution scored so low because it’s querying the DOM twice inside every loop iteration (I think).
• I am impressed at how well YUI3 performed – on every browser (incl. IE8), except Opera. I seriously need to follow up on the Opera thing…
• Speaking of YUI3 – one needs to go through extra hoops to measure performance, due to YUI loader’s setTimeout(). And make sure that you have all dependencies in on file, to avoid calls to the Yahoo’s CDN.
• IE8 didn’t like 2Mb documents inside an iframe (hence 1.5Mb)
• I have plenty of space for improvement – it will be fun!

Summary

• ASP.NET MVC allows use of ASCX as “partial views”
• It correctly assumes, that uniqueness of ClientID should be preserved
• It incorrectly does not prepend an alpha-character to automatically generated GUID based IDs
• User agents and selector libraries may correctly ignore such invalid IDs
• Solution: override ViewUserControl.UniqueID

The problem with ASP.NET MVC

ASP.NET MVC allows you to return an ASCX control as a view. This allows using a very nice pattern, of loading only parts of the page using XHR, while still being able to use the same controls when the full page is generated.

If you’ve used ASP.NET enough, then ctl00_something_something must be familliar – it’s an automatically generated value for HTML id attributes. ASP.NET does a pretty good job in ensuring that the requirement of unique IDs is followed, however, that only really works for fully generated pages.

If you are returning a partial view to be injected into some page, the context has already been lost – i.e. the server no longer knows anything about the original counter of controls and unique IDs. To circumvent this problem, MVC uses a GUID as a prefix for the ClientID generation. While, this is an absolutely correct approach, which basically means that ID collision is practically impossible, when you inject your partials into the DOM, the actual implementation has a small bug – the HTML spec says:

ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens (“-”), underscores (“_”), colons (“:”), and periods (“.”).

However, as we all know, the GUIDs may start with a number. In fact, they do start with a number much more often than they do with a letter. Which means that your partial views start having situations where id="11fa1658-d453-42e0-86f1-e640c476f7ac_ctl02_something_something". Naturally, if your client side framework is standards aware, it may ignore the id attribute altogether and fail miserably.

The YUI (non)part of the problem

In general, the advice is to not use ID attributes as a base for your operations – be it selecting elements, or attaching events (use classes and wiser selectors instead). In our case, though, we still have a lot of legacy code, which does not follow this approach. There is also the case of Visual Studio sometimes inserting IDs automatically. Still, it doesn’t matter how IDs end up there – if you’re using YUI selector library, you will get some autogenerated IDs anyways.

The reasoning for that, is that querying the DOM using IDs is very cheap with getElementById(). If you’re supplying a parent element, from which your query should be run, YUI will either re-use the ID that already exists, or will create a new (unique) one for the purposes of expanding your query, i.e. YAHOO.util.Selector.query(".myClass", parentElement) will become "DIV#parentId .myClass" which in turn will be expanded into "DIV[id=parentId] [class=myClass]", which is still the very same selector, but is easier to parse and process.

Now, the only problem is the regex ('\\#(-?[_a-z]+[-\\w]*)': '[id=$1]') which does the expanding of ID and class selectors into the attribute based selectors – it does follow the standard, and only accepts valid values, which means that if your ID starts with a number – it will not be expanded and the whole query will fail.

Solution

While some may say, that YUI should be updated to be more lenient on such errors, I say that there should be no place on the web for invalid code. And there’s also a much simpler solution to the problem – override default behaviour of ViewUserControl.UniqueID:

public class MyViewUserControl : ViewUserControl
{
	public override string UniqueID
	{
		get
		{
			var retval = base.UniqueID;
			if(!string.IsNullOrEmpty(retval)
				&& char.IsDigit(retval[0]))
			{
				retval = "c" + retval;
			}
			return retval;
		}
	}
}

Now… where do I report bugs in ASP.NET MVC?..

It doesn’t do anything, it just sits there!

Now, normally I’m not a complete standards freak (unlike the guys working on Caja). But what does <a href="javascript:void(0)"> really mean? The answer is simple – nothing.

First of, it’s a hyperlink to a resource, which should be accessed over Javascript “protocol”. Here’s the problem – I don’t really feel that “javascript” is a protocol. And it can’t really handle resources. But lets ignore that. What is the actual resource?

The link tells “use javascript” to “retrieve”… void. Why would anyone in the world want to view void in their browser? If anyone ever wants to look at it – they’re much better off achieving that goal on YouTube…

Semantics apart – it’s not comprehensible

Lets suppose, you don’t really care about web standards and semantics. I’d probably agree with you – we’re quite far away from having a meaningful web (if ever). Still, having crap as the URL is no good – apparently, screen readers will read that URL out loud.

Can you imagine anyone discussing this over a pint: “You know, I found this great site at javascript colon void opening parenthesis zero closing parenthesis“? That kind of URL would not make any sense to regular folks.

Accessibility is NOT about screen readers, though

Such a link kills browsing experience for sighted users too. Have you ever tried what happens when you middle-click the void link? Or right-click and then select “Open in new tab”? Here – try it out (mileage may vary if you use a recent browser).

Exactly – you guessed it – nothing meaningful happens. Just as it should!

Solution 1: Use real URLs

There are several ways out of this. My favorite one is to provide a real URL. If you’re following progressive enhancement methodology in your work, you always want to provide alternative links to achieve (near full) functionality even when Javascript is disabled.

This means, that instead of having a <a href="javascript:void(0)">Delete</a> and attaching onclick handler to it, popping out a confirm dialog and then making a background call using XHR, you provide a link to e.g. /myResource?delete which brings up a form, with a real <button>.

The actual backend code doesn’t become that much trickier – you don’t really have to write up a new “delete” routine. By using a confirmation interstitial, you also provide a way to confirm the action, and you can still use a POST request, as this action has permanent effect.

Solution 2: don’t use anchor tag

The above solution doesn’t always work – if you have a really interactive application, you’re not always able to provide links. However, since you’re already using JS – why use the <a> tag where it doesn’t belong?

I did hear some advice, to use <button> for clickable things, which are not really links. You should investigate that, but anyone who has tried to style buttons, knows that it can very easily become a major pain.

Still, you can attach your onclick handlers on anything you want – div, span and so on. In such cases, you should also add tabindex to make elements focusable and make use of ARIA roles to provide guidelines on behaviour. It’s not really that hard, now, is it?

The only really painful thing here is providing :hover and :focus styles on IE6. But IE6 should also die, together with javascript:void(0).

1. I write, you read and comment
2. ???
3. PROFIT!

Oh, and yes, you’re right – now that I have a blog, I will not update it frequently.