This has always been a problem with bittorrent of course; ISPs using traffic shaping to throttle bittorrent traffic, even if the torrents involved link to legally distributable material. The ISPs simply have no way of knowing and so those who throttle bittorrent traffic do so indiscriminately under the excuse that the protocol is too heavy and hurting other users.

The problem takes on another dimension when said throttling policy limits the CBC directly in performing its mandate:

> ...the programming provided by the Corporation should: [...] be made available throughout Canada by the most appropriate and efficient means and as resources become available for the purpose

(emphasis mine)

Now what will happen? My hope is that CBC will take this further. The old argument of "only crooks use bittorrent" is -- if it wasn't earlier -- now gone.

I promised I would post something about my experiences with using Wordpress as a CMS. Well, the site I was working on, a portfolio site for my wife, is now online.

The site, I'm happy to report, gets by using mostly standard Wordpress features -- posts, categories, pages, comments -- and where I had to step outside the standard I found the theme/template system relatively easy to work with. I've structured the site into categories (some with sub-categories) and pages. Portfolio entries are stored as blog posts and appears under the category they're assigned to. Easy-peasy.

Each entry is displayed as a thumbnail picture. On uploading images, I've set up the Flexible Upload plugin to resize all images to the standard size as well as a thumbnail copy with a certain name. When the posts are listed, I pick out the first image url of the post (each portfolio entry can contain several images) and display the thumbnail version of that image.

When you're on a category page, such as the Illustration page, each portfolio entry is fetched using Ajax on click and displayed with a nice fade out - spinner - fade in effect using Mootools. Wordpress has a template called "single.php" that holds the block content for a single blog post, and I've added a switch to this template so when my Ajax request gives it an extra variable I know not to print all the container tags -- on an Ajax request only the actual post contents are printed.

The top level menu is hardcoded in a template include, as it contains links to both categories and pages.

Editable texts around the site are also saved as Pages and given names that correspond to the header the text appears under. This works perfectly for a relatively simple site like this where there's not much ambiguity as to where the text appears. Had the site been more complex I probably would have considered looking into inline editing links.

It was nice to see Wordpress concepts plug so readily into a normal site, and I'll probably use it again. The concept of "The_Loop" takes a little to get into, it's both a normal loop of posts and a kind of context in which functions can be called and automatically refer to the current post. I would have preferred this implemented as a loop with the post as a simple value object, but it works ok when you get your head around it.

Sour grapes from Mozilla Corp's Rob Sayre today as news spreads that the latest nightly build of Safari gets 100/100 on Acid 3. There are still 3 timing warnings, meaning the animation isn't as smooth as it's supposed to be. Animation smoothness is also part of the test specification, so this can't be referred to as a complete pass yet. I'm surprised that the timing part hasn't been included as one of the 100 tests, it would make for a less ambiguous result if it was.

To get back to Rob Sayre, I have no doubts that the Firefox team is as dedicated to web standards as Opera and Safari, so why not take this opportunity to show it off?

Says Rob: > Besides, commitment to standards is strong at Mozilla, where we don’t constantly seek to rubber stamp our own implementation.

While the grandstanding aspect is part of what Sayre complains about, I see that as one of the most important components of the Acid tests, giving browser developers a kick in the ass to push for a more complete supports of the standards and giving publicity to the standards cause itself. In that respect, the quality of the tests - of which I know too little to comment - is secondary.

And, if the tests themselves were a load of irrelevant rubbish I suspect we would have heard something sooner than the day on which the first two browsers more or less pass the test. Sour grapes and sore losers indeed.

There's one thing Rob points out that is worth investigating. This commit showing that Safari tests for a specific font and turns off font smoothing for that font - specifically to pass Acid 3. That, I believe, goes against the spirit of the test and I think the Safari team would do well to put that into the open if it isn't what it looks like - a hack simply to pass the test. A Slashdot comment offers some insight:

> It's not the outrageous hack you think it is. Ahem is a dummy font that needs to have specific sizing in order for Acid3 to give accurate results. If Ahem doesn't have the specific size assumed by the Acid3 test, that means Acid3 can't give accurate results, not that Acid3 failed. So the Webkit developers disabled font smoothing for that specific font so that Acid3 could give accurate results, not to cheat. This isn't cheating because Acid3 isn't testing the font size, it's assuming the font size. It doesn't make sense to test the font size because that's volatile in real world conditions anyway.

But it's still not conclusive evidence that this hack is a valid pass. Alas, another ambiguity to the Acid 3 test, leaving passes open to judgement of whether or not they follow the spirit of the test.

UPDATE: Mozilla Chief Evangelist Mike Shaver makes a few more comments about the Acid 3 test on his blog, and feels that Acid 3 is a missed opportunity in the series, an opportunity to establish a base level functionality that's good for the web that, in his opinion, turned into a race to expose irrelevant browser bugs. More insight from Acid 3 author Ian Hickson in the comments.

Obviously not wishing to be beat reaching 100 in the Acid 3 test, Dave Hyatt's Safari team has closed a couple more test cases, putting their current build at 98/100. That, in my book, puts them in a clear first place, their nightly currently passes 97 of the tests and the 98 code is checked in for whoever is curious enough to build it themselves, until tomorrow's nightly comes up for download.

Speaking of Safari, 3.1 is quite the browser on Windows, it's really shaping up to be a serious and very fast contender to other Windows browsers. I agree somewhat with this Arstechnica review in that respect.

But please let me keep my OS X font smoothing - it's the only thing keeping my sanity in an otherwise all-Windows day.

I was kind of waiting for this - Alpha builds of Opera now provide some competition to Safari's lead so far in the ACID 3 game. Safari is currently at 96/100 while Opera's build, though not yet released, is said to achieve 98/100.

Word is the current build of Firefox is at 71/100.

Following NRK's recent P2P experiences and the great quote I hereby coin the NRK Beta Doctrine :

The only way to control your content is to be the best provider of it.

comes news that Canada's CBC are attempting a P2P project of their own.

And not only that, all episodes of South Park are now available for watching online, even with clips indexed so you can search and view specific scenes, such as Richard Dawkins getting poo flung at him. Exciting times!

I've moved this blog from Movable Type to Chyrp. My apologies for the RSS repeat posts you've probably received if you subscribe.

My main reason for the move is a more open and compact platform. I have a couple ideas for plugins that I want to develop and for a side project I just didn't have the time to get properly familiar with Movable Type plugins. Chyrp looks like an exciting platform, with a Ruby on Rails port coming, has a quick templating system, has what I need for posting and formatting posts (coming plugins aside) and is all round a more transparent engine.

Movable Type's tendency to throw a 500 Server Error on Dreamhost in FastCGI mode didn't help to keep it around either.

Since my last post I found another piece in the IE 8 puzzle. Turns out it's even easier than I said to test for earlier versions of IE now. As discussed in this IE 8 Developer Tools Whitepaper, you can open the developer tools that come with IE 8 and change the compatibility mode from the view menu there. The options are Quirks (IE 5), Strict (IE 7) and Standards (IE 8). Confusing naming aside, this is a quicker way to change the modes and doesn't require a restart of the browser. My question still remains then, what else changes between the IE 7/8 restart that the toolbar button requires?

The developer tools themselves looks underwhelming considering what else is available; Firebug for pretty much everything and Drosera for its very intuitive dom and object browser as well as style editing, but at least it's a step past javascript popup error - do you want to debug - yes - wait for Visual Studio to start. I know of Companion.JS and DebugBar but experience have taught me they're not that reliable.

<img alt="Satyricon" src="http://farm3.static.flickr.com/2150/2317666726_ff26383110.jpg" /> I've praised NRK, the Norwegian state broadcaster, before - and then they go and do another incredibly awesome thing: the radio channel NRK P3 has a ton of images available on Flickr and most of them are Creative Commons licensed, free for non-commercial use. The images are from festivals, contests and sessions, of a wide variety of artists.

Go NRK!

I never thought I'd be singing the praises of the insane X-UA-Compatible header of IE 8 - application version targeting on the web seems like an idea incredibly counter to web standards whichever way I look at it.

Today though, I found a use for it: Testing in various versions of IE. I have Multiple IE installed and regularily open 6 and 7 - and now 8 - to test styles and scripts. I noticed today that the IE 8 had apparently killed IE 6, input elements weren't working anymore. So I got the idea of using the X-UA-Compatible header, like so:

I'm not sure why I was surprised that it worked, but I was - and it did. It renders a page I was having problems with exactly like the proper IE 6 does.

I can't find anywhere which versions are accepted, but 6 and 7 seems to render exactly like the proper versions so far, with the notable difference of png transparencies actually working when using "IE=6", as opposed to in the real browser.

So, for now Multiple IE is replaced with a simple meta tag for me. I remain a little suspicious: the toolbar button included in IE 8 to change to IE 7 mode requires a restart of the browser while this meta tag is picked up on only a page refresh; what else is being done in that restart? One thing that changes is the User Agent string, it is being reported as IE8 until the 7 compatibility restart is done, regardless of the meta version target setting. After the restart it reports IE7. MooTools reports trident5 (IE7) regardless, which likely means the change is just cosmetic - the javascript engine running is still IE8's.

This is not to say I like version targeting at all still, but I'm happy Microsoft has helped a little to make tests in different browser versions easier. At least as far as style is concerned.