The fix was simple, replace the current four line inclusion code with:

Code block
   
<script type="text/javascript">
	var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
	var script = document.createElement("script");
	script.src = gaJsHost + "google-analytics.com/ga.js";
	script.type = "text/javascript";
	document.getElementsByTagName("head")[0].appendChild(script);
</script>

This will work fine, unless of course you have no head tag.  In which case you should replace getElementsByTagName(“head”) with getElementsByTagName(“html”).

On my website, Google Voice for Outlook I use the <video> tag to show a demonstration of the system working.  I don’t currently have a way to encode in ogg, and/or am too lazy too, so I decided that if the web browser didn’t support h264 video, it’d fall back to the YouTube video.  The expected result (from me, of course) was that if it can’t display the video, it’d display the YouTube.  Apparently though, in FireFox it does not fall back to the YouTube video and instead just displays a gray box, and the fault this time doesn’t lie with FireFox, but with the standard:

Content may be provided inside the video element. User agents should not show this content to the user; it is intended for older Web browsers which do not support video, so that legacy video plugins can be tried, or to show text to the users of these older browsers informing them of how to access the video contents.

Ugh!  This means that if you want to use <video> on any website, ever, properly, you’re going to have to encode it in both h264 and Theora until the industry decides on a set standard.

Purely Atrocious.

By this of course, I’m referring to <meta http-equiv="" />.

Currently, people wanting to relocate their web pages rely on an older value to this tag that seems to have been originally designed for moving one person from one page to another in a set increment of time:

<meta http-equiv="refresh" content="0;URL=http://domain.tld/location" />

This doesn’t appear to be what this value should be used for, and has very negative consequences for search engines and parsers.  Instead, don’t you think we should be using http-equiv to its full potential?

To this, I propose the addition of <meta http-equiv="location" />, to properly match the HTTP Header for redirection.

I think there should be two ways to use this:

<meta http-equiv="location" content="http://domain.tld/location" /> and

<meta http-equiv="location" content="301;http://domain.tld/location" />.

Obviously, the second example gives us both a *three digit* HTTP Code, and the URL for redirection.  Since HTTP codes are only three numbers (though in the future may be greater digits) there still should not be any problem.