Adobe and HTML5's Canvas

I had an epiphany and I hope somebody at Adobe has been paying attention to the HTML5 developments. Adobe is well positioned to take advantage of emerging browser features, most specifically canvas.

As great as canvas is, having a visual tool to assist in taking advantage of that would be ideal. Such a tool would smooth out the rough spots of cross-browser issues and could provide a set of pre-designed widgets and interactions that could be quickly dropped into any project.

Flash developers would likely find it an easy transition to building canvas-based tools. It'd be easier because of their knowledge of animation and because of the similarities between ActionScript and JavaScript.

Adobe is also well positioned to integrate a solution across existing applications such as allowing "Export as Canvas" from Flash, or the ability to build a canvas editor for Dreamweaver.

This isn't a Canvas vs. Flash issue. There are still advantages to both. Building a tool such as this doesn't sabotage their Flash marketshare any more than Dreamweaver does. In fact, having a tool such as this would further entrench Adobe as the de facto provider for web design tools.

Published July 07, 2009
Categorized as Opinion
Short URL: https://snook.ca/s/950

Conversation

16 Comments · RSS feed
Henry said on July 07, 2009

Interesting thoughts. I just hope the start making this "movement" soon by major browsers. I love the idea of HTML 5, but at this point its like using CSS3.

Jeff Schiller said on July 07, 2009

If the idea that they make money from authoring tools without requiring lock-in actually holds water, they would support SVG directly within Flash.

John Dowdell said on July 07, 2009

I've been following CANVAS for about five years now:
http://weblogs.macromedia.com/jd/archives/2004/07/safari_html_ext.html

Adobe CEO this month: "To the extent that an improved HTML standard accelerates innovation and consistent reach for web content, we’re very supportive and clearly from the perspective of our tools, we will support the creation and management of HTML content to the level that they want."
http://blogs.adobe.com/jd/2009/06/adobe_on_html5.html

But before tooling comes consumer support. Making faster workflows to create drawings is predicated on consumers being able to view those drawings. There's still quite a way to go.

(The Adobe Flash CS4 authoring tool isn't a general-purpose drawing tool. It focuses on various ways of creating SWF. Fireworks, Illustrator, even Dreamweaver are a little closer in scope to HTML construction.)

jd/adobe

Jonathan Snook said on July 07, 2009

John: While other tools are certainly closer in scope for HTML construction, I still feel that Flash is closer in scope to addressing the scripting and animation that one would generally need for canvas development. IE is really the holding point here, because of its lack of canvas support but if IE9 is rumoured to have it, how long does Adobe wait before getting that tool our there?

Zachary Johnson said on July 07, 2009

I really wish you'd stop adding to the HTML5 buzz machine by calling it the "HTML5 Canvas." Canvas works just fine with HTML4 and XHTML1.x. The functionality is not exclusive to HTML5. And it would have worked just as well with XHTML2.

Though, I suppose there's not much point in defending the better standard at this point since the XHTML2 people have thrown in the towel.

Also, somebody is currently working on a tool that will take vector images like SVG from a desktop design application and automatically port them to the Canvas. http://ajaxian.com/archives/svgburst

The Burst tool is timeline based, but it doesn't have GUI yet.

I'm pretty sure somebody has made a GUI animation tool for jQuery effects. Can't recall the name of it.

I don't expect Adobe to jump into this market because they'd be putting further nails into Flash's coffin.

Jonathan Snook said on July 07, 2009

Canvas works just fine in HTML and XHTML, sure. Browsers are cool like that. But the Canvas spec falls under the umbrella of HTML5. That's not taking advantage of the "HTML5 buzz machine." That's fact.

As for a GUI animation tool for jQuery effects, take a look at Glimmer. Not quite the same thing as what you're probably thinking.

Zachary Johnson said on July 07, 2009

No... that's true. Canvas did make its way from a proprietary Apple extension to the HTML5 spec. I'll take you at your word that you weren't buzzing for the sake of buzzing.

Andy Kant said on July 07, 2009

I really doubt that Adobe would ever implement that mechanism (not to say that a third party won't). Canvas is a direct competitor to Flash, it may not be as powerful, but there's no doubting that it could support most use cases.

If Microsoft ever bothered implementing Canvas, I could see them integrating some level of interoperability between Silverlight and Canvas since Silverlight is poised not only as Flash replacement but a method for progressively enhancing web apps (see Office Live which has a Silverlight enhanced version).

Matt May said on July 07, 2009

(Disclaimer: I work for Adobe, but wouldn't have any introspection into whether we could or would build something like you're asking about.)

I seem to remember Corel making a tool called RAVE that could output SVG or SWF. The main problem that I recall was that the animation models were different (Flash used frame-based animation; SVG is time-based). Anyway, people making really complex animations couldn't make it work on those two disparate systems, and the idea flopped.

I think now the issue is the disparity in the richness of the toolkits. From what I've seen of canvas, its feature set is about on par with Flash 5. Which is pretty good for a 1.0, honestly. Flash 5 wasn't that bad. But that also means no 3D, no HW acceleration, no component model or base set of components, and no API for direct accessibility. At this point, at least, canvas is a subset of Flash, which means any attempt to cross-compile from Flash to canvas would be constrained by what canvas is capable of.

Still, it would be up to the people buying the Flash authoring tool(s) whether this is something they require, and whether they're willing to live with those limitations. I think what we've seen over the lifespan of the web is that they want the right tool for their format, and that would lead me to believe more people will want canvas-centric authoring tools than retrofits of Flash authoring. But that's just my 2c.

Patrick H. Lauke said on July 07, 2009

Just had a flashback to one of the early versions of Dreamweaver when I played around like crazy with its built-in DHTML animation stuff. And, wouldn't you know, I just found it again in the current version, lurking under Windows > Timelines ... a relic, but probably quite close already (I seem to remember it generates oodles of javascript for its animation stuff).

Matthew Fabb said on July 07, 2009

Note that Adobe AIR renders content with WebKit, so it's very likely that a future version of AIR will support the HTML5 canvas tag. Once that happens Adobe will like want some sort of tooling to support that, rather than developers rely on other tool to create Adobe AIR content that uses the canvas tag.

I definitely think that Dreamweaver would be more of the tool for this job than the Flash authoring tool. Developers who work with Dreamweaver will be looking for some sort of canvas support anyways, meanwhile I'm not sure how many Flash developers will be looking to output their content to canvas.

Plus as Matt May mentions points out the capabilities of the HTML5 canvas still don't compared to what is capable in Flash. Outputting canvas content from the Flash authoring tool would require turning off a lot of functionality and then there would still be issues of how content in Flash is handled so differently from canvas. It's just way too much of trying to smash a round square peg into round whole.

Perhaps, something better would be a Flash-like animation tool that followed the canvas model and HTML DOM rather than the Flash model of movieclips with it's different DOM. Once again, I imagine Dreamweaver would be a better fit for this kind of tool and audience.

John Dowdell said on July 07, 2009

re: #4: "how long does Adobe wait before getting that tool our there?"

Creative Suite cycles are usually in the 18-24 month range. Work on CS5 has already been underway for quite awhile.

More practical and immediate may be third-party converters, in the same vein as clipboard-to-SVG converters or Illustrator export plugins:
http://www.svgfactory.com/
http://www.mikeswanson.com/xamlexport/

Me, I'd prioritize authoring-tool improvements for Text Layout Framework more highly -- offers real innovation to customers, and is already supported by 90% of consumer browsers -- but I'm not a direct decision-maker on tooling priorities:
http://labs.adobe.com/technologies/textlayout/

(Matt had the blast-from-the-past with R.A.V.E.. Corel had some other projects in similar vein, with native formats as well, if memory serves... came in too late to reap same network effects as the innovator, though.)

jd/adobe

Jonathan Snook said on February 01, 2010

Some time has passed since this post but I also wanted to point people to something I had heard on Sitepoint podcast #44 where Bruce Lawson makes reference to a demo from Adobe of someone pasting Illustrator into Dreamweaver and generating canvas.

Chat Clussman said on February 01, 2010

Flash CS5 is supposed to be able to compile into native iPhone (and presumably iPad) apps too. So adding support for other formats doesn't seem like too big of a stretch.

Personally, I'd be happy if Adobe focused more on releasing stable code than anything else. Illustrator CS3 had a nifty little bug for about six months where about 50% of the time using a gradient or layer transparency would completely crash my MBP.

Optimization settings in Acrobat Pro CS3 still create documents that don't render or print properly from Apple Preview. I had assumed that was a bug on Apple's end but then CS4 came out and the optimization settings are even buggier. Now I have PDFs that also don't print properly from Acrobat Reader on PCs.

But yeah, support for Canvas wouldn't be a bad thing either and it would be the smart thing for them to do. Sometimes a species can hit an evolutionary dead-end not because of a weakness in itself but because of greater strengths in a competitive species. When that happens the first species either adapts or becomes extinct.

That's not to say Adobe, with a de facto monopoly on creation tools, is going anywhere anytime soon, but it is to say that the de facto monopoly of Flash for rich media on the web and web-enabled devices like the iPhone/iPad *is* about to come to an end.

Brendon Smith said on February 07, 2010

This would be easy for them and actually anyone using flash should checkout haXe http://haxe.org/ and take notice of what it is capable of http://drawlogic.com/2009/07/16/haxe-sandy-able-to-generate-a-3d-javascript-engine-port-of-sandy-for-canvas/ -cool

Jonathan Snook said on March 08, 2011

And Adobe has now released Wallaby, a Flash to HTML exporter (mostly SVG and CSS, not Canvas).

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.

Want to learn about scaling CSS for large projects?

I'm available for full and half-day workshops on scalable CSS architecture. I can provide on-site training for your team. Interested?
Get in touch.