Opera moves to WebKit and V8

It also doesn't help that in some projects, comments and documentation strings are seen as superfluous fluff, meaning that one has to get into the exact mindset of the developers to first of all discover what they were trying to do, and only then to figure out what they meant to do.

Standards can be fairly awful things that are mostly exercises of formalising various vendor implementations, and I perceive Opera Software to be yet another vendor in this respect, even though the various Web standards involved have been fairly comprehensive and coherent. But they do serve a genuine purpose.

But in reality Java works pretty fine across all supported platforms. People routinely use Windows to develop and debug Java software that is later deployed on Linux (or earlier on Solaris).

That said, Opera has been in full strategic retreat from what the company was (and still is) known for, hence the emphasis on services and things like Opera Mini. I just interpret this news to be a continuation of that retreat.

An alternative nirvana would be to have a single reference browser and for all current and future browsers to promise compatibility with that. Then you could test with the reference engine only. But that is no more realistic than the single-browser scenario.

In the real world, of course you have to program to some pathological subset of the language which is supported on all browsers. You said as much yourself; you end up writing compatibility code for older IE versions. I would not advocate testing on additional browsers just to narrow that subset even further, but to flag up possible problems with the dialect you are using. You may inadvertently rely on a behaviour which happens to work one way at the moment, but was never specified anywhere (formally or informally), and might even be considered buggy and changed in future browser versions. You may make assumptions which look fine when rendered on a standard screen today, but will cause the site to break with very small or very large screens tomorrow - this was certainly the case a few years back with sites that had only been 'tested' on typical PC monitors. If you consciously decide to rely on these implementation details, that's fine. You may judge it is a better use of your time to write something that happens to work for 99% of users today, rather than agonize over whether it strictly complies with all possible standard-conforming browsers in the future. But it is surely better to make an informed choice.

People seem to forget that observations about the readability of wide columns of text are accompanied by recommendations that do not simply end with "restrict the width to ten words". Such recommendations came about through centuries of experience with the printed word and included other measures such as increasing the line spacing or "leading", or using shorter paragraphs (a general trend in mainstream writing, particularly in electronic media).

I do agree that CSS is a fairly poor tool for dealing with flexible layout and thus delivering multiple columns without a lot of extra work, however.

A model that worked like that over multicast IP, plus a relatively smaller number of unicast streams for 'catch up' services, should be more bandwidth efficient than unicasting to everyone.

There actually seems to be a fairly large market for live-streamed video, like Twitch and Ustream, or YouTube's live option. However, I don't think any services like this actually try to multicast over the internet; it's unicast all the way[0].

So I guess the answer is 'no' - it's not really worth the effort, even when live video broadcast to tens of thousands of destinations is your principle business; possibly once it scales up to millions is where things start to look different, but at that volume you can invest in the infrastructure to avoid having to send it over the internet.

[0] Last year's edition of TCP/IP Illustrated still describes multicasting over the internet as "ongoing effort...for more than a decade", which seems to correlate with the general consensus I got from Google of "don't even try"

A practical example of this is where you have multicast IPTV traffic arriving from a ISP network into a home/office network. You generally have to filter that out and direct it over a separate network of some kind to every IPTV device, because if you just forward it directly onto the local subnet, inexpensive switches will broadcast everything to every port, which is a problem.

Does anyone really want to run a separate network to their set top boxes simply because link layer multicast is synonymous with link layer broadcast? It makes it difficult to watch television on ordinary desktops because they are connected to the wrong network, for example. Perhaps inexpensive Ethernet switches will implement IGMP snooping in the future for this reason. It isn't common yet though.