Adobe’s John Nack defends Flash
5

Adobe’s John Nack defends Flash

I like to beat up on Flash a lot, but there’s no way to argue that it hasn’t delivered a ton of value over the years. Here’s Adobe’s John Nack arguing making the argument:

But let’s also be honest and say that Flash is the reason we all have fast, reliable, ubiquitous online video today. It’s the reason that YouTube took off & video consumption exploded four years ago. It’s the reason we have Hulu, Vimeo, and all the rest–and the reason that people now watch billions of videos per day (and nearly 10 hours apiece per month) online. Without it, we’d all still be bumbling along.

Read the whole thing. (Via Webmonkey.)

The philosophical argument against Flash
3

The philosophical argument against Flash

At the core, because Flash is the only de facto web standard based on a proprietary technology. There are numerous proprietary web content plugins — including Apple’s QuickTime — but Flash is the only one that’s so ubiquitous that it’s a de facto standard. Flash is the way video is delivered over the web, and Adobe completely controls Flash. No other aspect of the web works like this. HTML, CSS, and JavaScript are all open standards, with numerous implementations, including several that are open source.

The simplest argument in favor of Flash support on the iPhone (and The Tablet, and everywhere) is that Flash is, by dint of its popularity and ubiquity, part of the web. But the best argument against Flash support is that it is harmful to the web as a whole to have something as important as video be in the hands of a single company, and the only way that’s going to change is if an open alternative becomes a compelling target for web publishers.

John Gruber on why it’s worth resisting Flash.

The implications of IE8
3

The implications of IE8

Microsoft’s Monday announcement of the new browser compatibility features in Internet Explorer 8 has set of a torrent of commentary. They described their new approach to markup versioning in an article at A List Apart and on the Internet Explorer blog.

The basic idea is that Internet Explorer 8 will enable you to specify which rendering engine you want IE to use in a meta tag on your page. So you can tell it your markup is IE7 compatible, IE8 compatible, or bleeding edge compatible, in which case it will use whatever the latest and greatest rendering engine is. We can assume that IE9 will retain all of those modes and include a new IE9 mode as well, assuming that Microsoft doesn’t decide it’s too much trouble to maintain all of the different rendering modes and toss some of them out by then. If you don’t include the special meta tag to turn on IE8 rendering mode, IE8 will default to using the IE7 rendering engine.

I appreciate that Microsoft is trying to solve a tough problem here — not breaking the sites of people who have included hacks for specific versions of Internet Explorer while at the same time giving themselves the opportunity to fix bugs and add new features in the browser. I don’t know if it’s an elegant solution, but it is a solution to that specific problem. What I wonder, though, is what this means for Web developers. I imagine the question most developers are asking is, “What’s the most sensible way to write markup, CSS, and JavaScript in the coming browser ecosystem?”

Sam Ruby points out that any DOCTYPE that’s unknown to IE will be rendered with the IE8 rendering engine. So if you want to bank on the improved standards support in IE and avoid using the new meta tag, just pick a DOCTYPE that is correct but that IE doesn’t do anything special with. I have a feeling that’s the approach most standards oriented Web developers will wind up taking.

Those developers whose depends on specific quirks of IE7 will be able to force IE8 to render pages in that mode, and developers who code to standards can pick a DOCTYPE that IE will use to render pages in its newest, most standards compliant mode. That strikes me as a pretty reasonable workaround for the meta tag business, which I don’t see any real need for anyone to use.

The other question I have is how the other browser makers will react. Firefox and Safari seem content to keep improving the standards support in their browsers without dithering over breakage of older pages, but their situation is different than Microsoft’s. For one thing, they have always been significantly more standards compliant than IE, so they don’t inflict severe breakage on people when they change. Secondly, people rarely include Safari and Firefox hacks on their pages. They code to the standards supported by Firefox and Safari, and then include whatever hacks they need to in order to make their pages look right in IE6 and IE7. The developers of WebKit are not going to be adopting the versioned rendering engines approach IE is taking, and really there’s no reason to do so. I expect the Mozilla folks will say the same thing.

The specific bit of good news here is that it should free developers from adding yet one more browser-specific style sheet for IE8. Lots of people these days are using hackish workarounds to make sure their pages look right in both IE6 and IE7. When IE8 is released, you won’t have to do anything to make sure your IE7-specific code doesn’t cause breakage, the way IE6 code did in IE7. And it looks like there is a path to using the latest and greatest features without any of this meta tag foolishness. So I think it’s going to be alright.

There is a whole lot more on this topic just about everywhere, so much so that I’m going to punt on linking to all of the reaction. You’ve probably read it all anyway.