Adobe quickly denied the charge, but not quickly enough for the open web evangelists to grab their pitchforks and take to blogs in anger. After all, it was a juicy turn of events — big company with a vested interest in its own tech (Flash, in this case) tries to block a competing technology on the free, open web. It all ended up sounding like some conspiratorial, back-room maneuvering worthy of an Oliver Stone film.

The truth is considerably more complex and, dare we say, kind of embarrassing. In fact, dig a bit into the internal workings, back-stabbing, petty snipping and politics of both the W3C and the WHAT WG, and you’ll quickly come to realize it’s nothing short of a miracle that HTML5 exists in any form at all.

This particular tempest in a teacup revolves around an e-mail from Larry Masinter, Principal Scientist at Adobe, questioning whether the Canvas 2D element, the RDFa specification and the Microdata spec were within the scope of the WHAT WG’s charter.

The answer to that is hashed out in some detail on the WHAT WG’s public mailing list. The short version seems to be that no, they probably aren’t, but WHAT WG decided to include them in the spec anyway.

As far as we can tell, no formal objection was ever lodged. Though it certainly sounds like Masinter is planning to file one when he writes:

If I need to use the word “formally” in there somewhere, or if there’s some “Formal Appeal Change Proposal” form I’m supposed to fill in, recapitulating all of the e-mail arguments made to date, suggesting the documents “change” by disappearing, and written in iambic hexameter, please let me know.

However, Masinter has since said that neither he nor Adobe has filed or intends to file any formal objections. Perhaps more importantly, even if Masinter were to do so, it’s hard to see how that would “block” HTML5. Masinter (and some others) merely object to HTML5, Canvas 2D and other specs all being lumped together, not to the specs themselves.

So how will all this hoopla impact HTML5 and the web that we mortals actually use? The answer is, it won’t.

Regardless of what the W3C ends up doing with the Canvas 2D spec and other sub-elements of HTML5, browsers are already supporting them. Certainly it would be good if these elements became an official part of the HTML5 spec, but whether or not they do will have very little impact on the web as we know it. After all the HTML5 spec won’t officially be finished until 2012, but HTML5 is already changing the web since all browsers but IE are supporting it.

The reality is that, for all their blustering and antics, neither the W3C nor the WHAT WG ultimately have much practical impact on HTML5′s adoption on web. For that, we rely on browsers and the various HTML5 elements they chose to support.

See Also:

• YouTube Embraces HTML5, But Stops Short of Open Web Video
• How HTML 5 Is Already Changing the Web
• HTML 5 Won’t Be Ready Until 2022. Yes, 2022.

He waited a few days to make his point, but Adobe’s head software honcho has thrown a bucket of water onto the “Death of Flash” fire.

In a blog post Tuesday, Adobe CTO Kevin Lynch responded to Apple’s recent criticisms of the Flash platform and warned that a switch to HTML5 would throw users and content creators “back to the dark ages of video on the web.” Lynch went on to cite many of the same shortcomings of HTML5 video that we outlined in our post on the topic Monday.

First, here’s Lynch on Apple’s failure to support Flash on the iPhone, iPod Touch and iPad:

We are ready to enable Flash in the browser on these devices if and when Apple chooses to allow that for its users, but to date we have not had the required cooperation from Apple to make this happen.

And later:

Engaging with ideas and information also means ensuring there is an open ecosystem and freedom to view and interact with the content and applications a user chooses. This model of open access has proven to be more effective in the long term than a walled approach, where a manufacturer tries to determine what users are able to see or approves and disapproves individual content and applications. We strongly believe the web should remain an open environment with consistent access to content and applications regardless of your viewing device.

These strong words are no no doubt directed at Apple, which is actively keeping Flash off of its newest devices.

As reported by Wired’s Epicenter blog, Steve Jobs laid into Adobe at an Apple employee meeting last week, calling the company “lazy” and deriding its Flash Player as buggy, saying Apple is refusing to support it in Mobile Safari for stability reasons.

To defend against that particular statement, Lynch also pointed out that Adobe has been busy enhancing Flash Player 10.1 (which will be released within a few months) to work better on Android, BlackBerry, Nokia and Palm devices — and not just phones, but tablets, netbooks and other so-called “transitional devices” where Flash has historically had a negative effect on performance.

In other words, Lynch says Adobe is working on making Flash perform better on everyone else’s tablets and phones, just not Apple’s.

And here’s Lynch on the notion that HTML5 will threaten Flash’s dominance:

Some point to HTML as eventually supplanting the need for Flash, particularly with the more-recent developments coming in HTML with version 5. I don’t see this as one replacing the other, certainly not today nor even in the foreseeable future. Adobe supports HTML and its evolution, and we look forward to adding more capabilities to our software around HTML as it evolves. If HTML could reliably do everything Flash does, that would certainly save us a lot of effort, but that does not appear to be coming to pass.

He pointed to inconsistencies in browsers as the main hindrance on HTML5′s video capability, adding that, “users and content creators would be thrown back to the dark ages of video on the web with incompatibility issues.” For this reason and a few other ones cited by Lynch, Flash will be sticking around — at the very least, as a stopgap solution — for years to come.

What is left largely unsaid is the future of Flash as a development environment.

Flash Professional and Adobe Creative Suite are some of the most well-loved and powerful tools for creating rich apps on the web, especially when building apps to run on multiple devices.

Right now, a lot of people are building that stuff in Flash. In the future, they will likely be using the same software to do it in HTML5.

Adobe will react to the market, following developers where they go. If developers are making a broad switch to HTML5 — which the most forward-thinking ones already are — expect tools like Flash (via export add-ons) and Dreamweaver to get better at outputting content in HTML5, CSS3, JavaScript and other web standards.

Lynch touched on it a little bit here:

We support whatever technologies and formats that best enable our customers to accomplish these goals, and work to drive technology forward where there are gaps that we can fill.

Photo: Laurence Olivier as Hamlet

See also:

• Why Flash Isn’t Going Anywhere, iPad Be Damned
• Photoshop’s Top Dog Replies to ‘Flash Is Dead’ Meme
• YouTube Embraces HTML5, But Stops Short of Open Web Video
• A Brave New Web Will Be Here Soon, But Browsers Must Improve
• W3C Drops Audio and Video Codec Requirements From HTML 5
• How Firefox Is Pushing Open Video Onto the Web

But while HTML5 video is here, it isn’t quite ready for prime time. There are the codec issues, but even without considering those, the unfortunate fact is that even just watching HTML5 video isn’t as nice as it is with Flash. Full-screen support isn’t universal, some browsers autoplay video while some don’t, and the players themselves lack features you’ll find in most Flash video players.

In short, the experience of HTML5 video hasn’t quite caught up to the promise. That’s where SublimeVideo hopes to come in and sharpen the picture. SublimeVideo is a software product from Swiss startup Jilion. The company wants to create a uniform, cross-browser, multiple-codec compatible, HTML5 video-embedding solution.

As we mentioned in our Flash-isn’t-dead-yet piece, smart web developers are going to use both HTML5 and Flash for some time and that’s exactly what SublimeVideo plans to do.

SublimeVideo’s working demo movie currently only supports WebKit browsers (Safari, Chrome and IE with Chrome Frame), but before the public release arrives, SublimeVideo’s developers plan to add support for Firefox (via .ogg videos), Opera and a way to fall back to Flash video in older browsers and IE8.

At the moment, SublimeVideo supports basic features like live resizing, keyboard shortcuts for play/pause, advanced buffering and full-screen mode (full screen only works if you’re using a nightly build of WebKit). Obviously, it’s no match for a Flash video player, but it’s an impressive start and much nicer than the native video controls in most browsers. Unfortunately, the reality is a bit more of a mixed bag.

The player worked just fine in the latest version of Safari, though load times were bit slow particularly when jumping around in the timeline. Only the developer version of Chrome for Mac supports HTML5 video and it has quite a few bugs, making SublimeVideo’s demo video a jittery, stuttering affair (not SublimeVideo’s fault).

If SublimeVideo is able to deliver on all its goals, the end results just might make for a very slick HTML5 video solution — deliver web-standards video where you can and fall back to Flash where you can’t. Solutions like this are what the web needs in the short term.

It’s unclear from the limited information available, but it would be nice to see SublimeVideo fall back in the opposite direction as well. In other words, sites that use features HTML5 video doesn’t support — for example, in-video queue points, like user comments — start with the Flash video embed and then fall back to HTML5 for mobile devices that don’t support Flash.

SublimeVideo has not announced a release date beyond “soon,” but does say the code will be available for free so long as it’s for noncommercial use.

See Also:

• Why Flash Isn’t Going Anywhere, iPad Be Damned
• Photoshop’s Top Dog Replies to ‘Flash Is Dead’ Meme
• YouTube Embraces HTML5, But Stops Short of Open Web Video
• A Brave New Web Will Be Here Soon, But Browsers Must Improve
• W3C Drops Audio and Video Codec Requirements From HTML 5
• How Firefox Is Pushing Open Video Onto the Web

The view is based largely on the fact that the iPad, like the iPhone, will likely not support Adobe’s plug-in, but it’s also a result of the enthusiasm surrounding the current momentum of HTML5. The emerging web standard, which is quickly being adopted by browser manufacturers and developers, offers native video playback and animation tools that don’t require Adobe’s Flash plug-in. Google recently added its significant weight to the HTML5 camp when it announced HTML5 video support for YouTube. That Apple appears to have again shunned Flash is simply more fuel for the anti-Flash fire.

At this point, however, the demise of Flash is anything but assured. Even if it does eventually fade away, Flash will still be with us for quite some time because there’s currently nothing to replace it with.

While some proponents of the open web would have you believe that a viable replacement for Flash is already here — in the form of HTML5 –that’s not exactly the case. The HTML5 video tag does indeed allow you to embed videos in web pages without Flash, but it’s up to the browser to actually play that video. And that’s where the problem arises — what video codec should the browser use? Apple, with the iPad, iPhone and its desktop apps, is pushing the H.264 codec. But the H.264 video codec has licensing requirements and is not free in any sense of the word. Moving from the Flash plug-in to the H.264 codec is like moving backward — from Flash to a more expensive Flash.

The iPad then, even if it does hasten Flash’s demise, isn’t helping to bring about an open web, it’s just moving from one controlling body (Adobe) to another (MPEG LA, which controls the H.264 codec and is not, for the record, affiliated in any way with the MPEG standards organization). The iPad delivers Apple’s vision of the web, which currently happens to not include Flash. But the iPad isn’t some giant leap for the open web, no matter what Steve Jobs would have you believe.

Mozilla has already said that Firefox will not support H.264. Google’s Chrome browser does support H.264, but the company also recently moved to acquire On2, makers of another, competing video codec which means, if nothing else, Google isn’t completely satisfied with H.264 either.

Ogg Theora, which Mozilla has elected to support, is an alternative set of video codecs which might overcome some of the problems with H.264. But while Ogg is open source and free, there is some possibility that elements of it may be encumbered by patents. Apple has long cited these so-called “submarine patent” concerns among its reasons for not supporting Ogg. Critics dismiss these fears as misplaced. However, part of the reason Google acquired On2 may be to obtain these potential patents, and what Google does with them when the sale is completed — keep them or release them under an open source license — will have a significant impact on Ogg’s future.

So there’s no agreement on an open web video codec yet. This means no matter which option you chose — HTML5 with H.264 or HTML5 with Ogg Theora — the best case scenario is that 20 to 25 percent of the web sees your video without needing a plug-in.

Obviously that’s not ideal.

Adobe likes to say that if you use Flash, around 99 percent of the web will see your video. But throw in the iPhone, the iPad and other mobile devices without Flash capability and that number drops significantly. But even if Adobe’s penetration is lower than it claims, Flash still has a much deeper reach than any of the myriad other options.

So which option are developers going to chose?

Well, smart developers are going to chose all of the above. And indeed, they already have. YouTube has not abandoned Flash. The site is offering both Flash and H.264 video. We expect YouTube will add even more file formats to the mix before it’s done.

So if Flash’s dominance is slipping, then eventually it will just disappear right? Sure, just like IE 6 disappeared quickly as soon as something better showed up?

Flash isn’t going to disappear overnight, and probably won’t even fade significantly any time soon. Dion Almaer, who works at Mozilla and is editor of Ajaxian.com, put it best when he wrote about this in a blog post Monday:

HTML5 is slowly going to put a dent into [Flash] if we ever get some of the use cases just right (e.g. video), but Adobe has a good penetration and can move at the speed of a dictatorship… There is still much more work to be done. Flash and browser plug-ins have had a long history at forging new paths, and the web can come in behind them and standardize.

Flash will continue to exist because for many it will continue to be the best tool for the job. And let us not forget that while Flash has its problems — namely performance — it’s also been an incredible innovator for the web. All that Ajax and amazing desktop-like stuff we all love about today’s web? Many of the tools used create those interfaces were written specifically to catch up with Flash.

Instead of dancing prematurely on Flash’s grave, we ought to be hoping Adobe can turn it around and release something so innovative, so fast, so amazing — and so open — that even Steve Jobs has to smile.

Update 02-02-10: Adobe CTO Kevin Lynch weighed in on the debate over Flash and HTML5 video on the web in a blog post Tuesday morning. He expresses many of the same concerns about support and user experience inconsistencies across browsers, and offers comments about Flash’s ongoing future as a development environment.

See Also:

• Photoshop’s Top Dog Replies to ‘Flash Is Dead’ Meme
• YouTube Embraces HTML5, But Stops Short of Open Web Video
• A Brave New Web Will Be Here Soon, But Browsers Must Improve
• W3C Drops Audio and Video Codec Requirements From HTML 5
• How Firefox Is Pushing Open Video Onto the Web

In response to Apple’s iPad product announcement Wednesday, Adobe has posted a message to its Flash Platform blog assuring developers they’ll be able to use Adobe’s Flash authoring tools to build iPad apps.

Developers are currently able to publish almost any project built using ActionScript 3 into a native iPhone or iPod Touch application using a cross-compiler called Packager for iPhone. Adobe is tweaking Packager for iPhone, which will ship as part of Flash Professional Creative Suite 5, to work with the iPad SDK and support behaviors specific to the new device.

The biggest change is the difference in screen size. Adobe says it will first concentrate on getting ActionScript 3 apps to translate to the iPad properly, then build in support for the device’s larger screen size.

Keep in mind, this does not mean that Flash apps, AIR apps or the Flash Player are going to work on the iPad. There seems to be some confusion about this — probably because Adobe’s communications are purposely vague about this fact, and bloggers are unclear as to what Packager for iPhone actually does. When you export a Flash app to the iPhone, you’re not getting a Flash app, you’re getting an app that was built in Adobe’s ActionScript 3 programming language using the Flash authoring tool, then translated into iPhone-native code.

Flash and AIR apps don’t work on the iPhone or the iPod Touch and they won’t work on the iPad. Apple’s mobiles currently use hardware-embedded decoders to render YouTube videos, but we can expect that scenario to change soon, now that YouTube is moving towards HTML5 video playback using h.264, which Apple devices use as their native video codec.

In fact, during Steve Jobs’ announcement Wednesday morning, many attendees (including our own Gadget Lab team) noticed when a “plug-in missing” icon popped up on the New York Times homepage as Jobs was demonstrating the iPad’s Safari web browser.

Adobe was going to release a full beta of Flash Professional CS5, but the company decided against it so it could get the final app out more quickly.

Photo: Jon Snyder/Wired.com

See Also:

• Adobe Debuts New Flash Tools for Building and Tracking Social Apps
• Adobe’s New Flash Tools Ease the Pain for Both Designers and Coders
• Flash Player 10: Dazzling Effects, Better Performance, Runs on Linux
• Adobe Announces Flash Lite 3.0

A blog post from Mozilla’s Mike Connor, one of the company’s key browser developers, made waves Saturday and Sunday in the Firefox world for suggesting that scenario. While Connor didn’t explicitly say it would happen, his words led many readers to assume the company was considering abandoning the current Firefox add-on ecosystem in favor of JetPack-based add-ons

We asked Mozilla about this possibility and the representative we spoke to insists it’s certainly not the case. Connor’s post has been updated and much of the hubbub has settled down, but the post did spark an important discussion about browser add-ons and the relationships users have with them.

Connor’s post outlined a few lines of thought that have been going on behind the scenes among Firefox developers, as they have been strategizing about the browser’s future.

Exactly what Connor intended to say is still a little unclear. The initial post used phrases like “deprecating the old systems” and suggested that Mozilla would be “discriminating against the old systems” — that is, the current Firefox add-on ecosystem we all know and love — as it moves forward with its software releases.It certainly sounded like somebody at Mozilla was talking about killing off add-ons as we know them and replacing them with the still-beta JetPack add-on system and the Personas theming system. JetPack is Mozilla’s platform for creating simple add-ons that manipulate web page elements and UI elements within the browser’s skin, much like Greasemonkey scripts or the type of DOM-futzing that Chrome’s extension system allows. Personas, Mozilla’s theme manager, allows users to alter the look of the browser by installing a visual theme with one click.

Once a rather vocal community began reacting to the post (read the comments) Conner added an update that backpedaled a bit, but still concluded that, while the plan might be not be “set in stone,” Mozilla does intend to move in that direction. When he said that Mozilla was “discriminating against the old systems,” and added “I am personally at peace with that,” Conner was essentially throwing down the geek gauntlet, whether he meant to or not.

To understand why those statements caused an uproar, you must first understand that, as it stands, JetPack is full-fledged Firefox add-ons what Mini Me is to Dr. Evil — a cute but much less powerful sidekick.

JetPack makes it simple to build simple things, but in its current incarnation it could hardly produce a NoScript, an AdBlock Plus or any of the other popular, powerful Firefox extensions.

Presumably, long before Mozilla makes an attempt to officially migrate from the current system to the JetPack system, the company isn’t likely to turn its back on the over 5,000 add-ons currently shipping for Firefox.

But Conner’s post had an element of immediacy to it and that quickly brought out the die-hard Firefox add-on fans writing “over my dead body” and threatening to abandon Firefox in favor of Google Chrome (ironically, when we recently critiqued Chrome’s current add-on plan, we did so because it fails to offer developers exactly the tools that Conner is suggesting Mozilla might eventually take away).

Why would Mozilla want to limit developers? Well, the truth is that’s not at all what JetPack is aiming to do.

In fact, the JetPack program is an attempt to make developers’ lives easier. JetPack offers niceties like stable APIs (so new versions of Firefox won’t break all your add-ons), automatic updates, sandboxed add-ons for a more secure browser and process isolation so add-ons won’t crash Firefox.

But of course simplicity comes with a price, and this is where Conner runs afoul of the nerds.

To many, the power of Firefox is precisely in its infinite extensibility. Does infinite power bring infinite possibilities for problems? Yes, but the tradeoff is worth it, so say Firefox’s die-hard add-on users.

It’s precisely the fact that users can do whatever they want within the browser that has elevated Firefox to where it is today. Outside developers have been able to push the envelope the web browser’s capabilities, extending it to do things that even the founders of Mozilla would likely never have imagined.

The real issue might simply be whether or not Mozilla recognizes this. Writing about the reasons why Mozilla wants to eventually switch to JetPack-based add-ons Conner talks about updates and problems with add-ons. “We already know from our users,” he writes, “that incompatible add-ons are a significant factor in opting out of updates.”

The message here is not that the add-on system needs to be changed so that people will have a cleaner upgrade path for their browser, but that the browser is irrelevant and the add-ons are what matter.

Firefox, Chrome and Safari routinely swap the top spot in speed tests, and the browsers match each other pretty closely in feature breakdowns, including Firefox’s once-unique core strength — support for the latest web standards.

But there is one huge difference that sets Firefox apart — the ability to infinitely extend it through add-ons. Take away the full power of add-ons and Firefox is just another browser. It might be easier to keep up-to-date since you wouldn’t have to worry about compatibility, but there wouldn’t be anything too special about it, functionality wise.

However, despite some perhaps poor wording in Conner’s post, Mozilla is not about to abandon traditional add-ons. Will many developers chose to port their add-ons to the JetPack system? We hope so. It makes it much easier to develop and maintain simple add-ons. But for the more powerful add-ons, Mozilla will likely leave existing frameworks in place for some time.

See Also:

• Firefox 3.6 Enters the Home Stretch, Release Candidate Arrives
• Mozilla’s JetPack Prepares to Take On Chrome Extensions
• Chrome Extensions Are Cool, But They Can’t Match Firefox

After not responding to inquires, Craigslist CEO Jim Buckmaster eventually posted a terse message on the company’s blog saying that Yahoo Pipes mashups were using “a disproportionate amount of server/bandwidth resources.”Now it would seem that Craigslist has ended its ban of Yahoo Pipes, but for developers we imagine the damage has been done. For its part, the startup Flippity, which was the first to notice its Yahoo Pipe had been blocked, says it has moved on to friendlier sources, rewriting Flippity to use the eBay API.

It wasn’t the first time Craigslist has shutdown outsiders trying to improve on the site’s famously antiquated tools — the site previous blocked ListPic, a tool designed to help Craigslist users browse by images, and a tool to search all the Craigslist sites at once.

As we said in our initial report on this debacle, if you’re a developer looking for data to use in a mashup, think twice about Craigslist. The site has a wealth of data, but it guards it jealously and has no qualms about blocking even major players like Yahoo.

See Also:

• Craigslist to Developers: Look Elsewhere For Mashup Data
• Craigslist Blocks ListPic, Considers Adding Visual Browsing
• Craigslist Users Crack Down on IPhone Unlockers
• Why Craigslist Is Such a Mess

Craigslist has a long history of being openly hostile to outside developers, but the site took its walled garden mentality to new levels with a recent decision to block Yahoo’s popular Pipes tool from accessing the site’s data.

According to developer Romy Maxwell, Craigslist has blocked Yahoo Pipes primarily to stop his mapping mashup, Flippity. The Flippity mashup was using Yahoo Pipes to gather Craigslist posts from its public RSS feeds and plot them on a map. This apparently rubbed Craiglist the wrong way, but rather than just block the offending Pipe, Craigslist decided to block the whole service — effectively killing thousands of Yahoo Pipes-based mashups.

This isn’t the first time Craigslist has shutdown outsiders trying to improve on the site’s famously antiquated tools — the site previous blocked ListPic, a tool designed to help Craigslist users browse by images and a tool to search all the Craigslist sites at once.

However, unlike ListPic, which Craigslist claimed was using resources excessively, the latest ban doesn’t seem to be about traffic.

In his blog post, Maxwell claims his application complies with Craigslist’s terms of service and doesn’t use excessive bandwidth. In fact, according his post, the Yahoo Pipe in question is private and only runs once every fifteen minutes. Couple that with the fact that Yahoo Pipes caches the data it scrapes, and one could conclude that bandwidth concerns should not be a factor in the shutdown.

As Wired magazine reported in its cover story about Craigslist earlier this year, the company has been quick to ban third-party search services which “[subvert] Craigslist’s mission to enable local, face-to-face transactions” or services which “increase the risk of scams and can be exploited to snatch up bargains, giving technically sophisticated users an advantage over casual browsers.” Flippity doesn’t appear to have been introducing any feature that would enable such behavior.

So, perhaps Flippty was in violation of the TOS? Maxwell asked founder Craig Newmark about the app and Newmark told him, “as a rule of thumb, [it's] okay to use RSS feeds for noncommercial purposes.”

If it’s unlikely to be about bandwidth and there’s no overt violation of the TOS, why ban Yahoo Pipes?

Frankly, we’re not sure. Craigslist isn’t talking — we’ve contacted the company and asked for an explanation, but as of this writing, nobody has gotten back to us, nor has any public statement been issued.

One thing that is clear though, if you’re thinking of adding Craigslist data to your application, think again.

For its part, Maxwell says Flippity will continue, but plans to use data from developer-friendly sites like eBay and Oodle.

See Also:

• Craigslist Blocks ListPic, Considers Adding Visual Browsing
• Craigslist Users Crack Down on IPhone Unlockers
• Why Craigslist Is Such a Mess

His e-mail:

In his mail describing why he created a separate Canvas 2D API specification, Doug Schepers wrote [1]:

> There is a chance that currently Canvas could be a blocker on progress

> for the HTML5 spec, and at this point, Canvas is so widely implemented

> that I don’t think it’s at risk, so I hope this isn’t disruptive. I am

> available to help with any editing that needs doing, but I hope that

> others will also work with this draft, and step into the editor role.

At Microsoft, we agree with the sentiments expressed by Doug, Maciej [2], and others about creating a separate Canvas 2D API specification. [3] We are prepared to offer editorial resources to aid in the completion of this separate specification. We have looked over Doug’s initial document, made some editorial enhancements, and are prepared to follow through in taking feedback and maintaining the specification.

We believe that some sort of accessibility API functionality is needed in the canvas element. However, the exact nature and depth of that functionality presents a dilemma that may block progress on the HTML5 spec. We also think that the Canvas 2D API may be a desirable feature used in other technologies such as SVG.

Starting with Doug Schepers’ initial draft, we made changes to get the document to adhere to the W3C PubRules [4], enhance readability, and improve logical flow of the document. In addition, we foresee adding sample code throughout the specification, where appropriate. No normative changes have been made. As with all drafts, the Canvas 2D API specification is still a work in progress. We would like to solicit feedback about the changes that were made (see below TODO) and about further changes that the working group would like to see.

Our updated version is published at http://dev.w3.org/html5/canvas-api/canvas-2d-api.html.

[1] http://lists.w3.org/Archives/Public/public-canvas-api/2009JulSep/0002.html

[2] http://lists.w3.org/Archives/Public/public-canvas-api/2009JulSep/0007.html

[3] http://lists.w3.org/Archives/Public/public-html/2009Aug/0628.html

[3] http://www.w3.org/2005/07/pubrules

[...]

Microsoft Internet Explorer is the only modern browser with no plans to support Canvas — Firefox, Chrome, Safari and Opera all do. Redmond’s opposition makes sense, as the animation capabilities Canvas provides would conflict with Microsoft’s plans to speed adoption of its Silverlight platform, which affords web authors many of the same capabilities using a proprietary plug-in and commercial development software.

Several list members pointed out that if Microsoft has the resources to author the spec independent of HTML5, those resources could be better spent building support for Canvas into the browser.

A follow-up response from Ian Hickson, a Google employee who is the primary editor of the HTML5 spec, points out a few clear problems with this strategy and stresses that it doesn’t seem list a good idea:

IF we’re going to split out the 2D API — and I’m not really sure if at this point that’s something we should do, frankly — then I would much rather we do it based on the text in the HTML5 spec now, and would much rather we have an editor who is able to give this the full-time attention that it needs.

However, I’m really not sure at this point that it even makes sense to extract the API anymore. The API intergrates pretty tightly with the rest of HTML, for example it refers to HTMLVideoElements, the HTML5 “structured clone” feature is defined in terms of canvas interfaces, and so on. There would have to be a two-way reference, which would be a maintenance nightmare, and which would just delay the progress of both documents.

What are the problems that we are trying to solve by splitting out the API at this point?

The whole thread, which is still growing, can be viewed here.

What do you think? What’s Microsoft up to?

Andy Baio, a prominent blogger and creator of Upcoming.org, has released a Greasemonkey script to visualize the perceived political bias of linked content on the political news aggregation site Memeorandum. If a site tends to link to more left-leaning stories, it’s colored blue. Right-leaning linkers are red.

With the help of Delicious founder Joshua Schachter, Baio used a recommendation algorithm to analyze the last three months of linking behavior for each news source. With that data stored in a Google Spreadsheet, Baio used the Ajax support in Greasemonkey to grab a JSON feed and colorize the links. Those with Firefox’s Greasemonkey extension and Baio’s script installed will see the colorized links when viewing Memeorandum. Baio also released a full-fledged extension that does not require Greasemonkey.

This is a great example of how Greasemonkey can be used to change the way you view a page. In Baio’s case, he wanted to see the perceived bias of a site at a glance so he could choose a balanced view. The code from this project is available under the free and open-source GPL license. You could use it to create other ways of visualizing data on the web.

If you’re brand new to Greasemonkey, be sure to read my new Greasemonkey tutorial on the versatile Firefox extension. If you’ve ever written JavaScript before, you’ll quickly learn the ways of Greasemonkey, which essentially gives you the ability to insert your code anywhere in someone else’s site, but only for your own use on your local machine.

You don’t need to bite off as much as Baio, who admits this is his first Greasemonkey script. One of the biggest benefits I’ve found is that I can write code to pull out the important stuff already in the page. My tutorial shows a simple example of that, where I create a floating menu of all <h2> tags on the page. It turns out this is useful for long Wikipedia entries… and Webmonkey tutorials.

See also:

• Andy Baio: Step Away from the Computer
• GMail Adds Official Greasemonkey Support
• Run Greasemonkey Scripts in Google’s Chrome Browser