[whatwg] Potential Danger with Canvas API in html5 #html5 #canvas

[Aryeh Gregor]

On Wed, Jun 9, 2010 at 2:29 PM, narendra sisodiya
<narendra at narendrasisodiya.com> wrote:
> Case 1 - Abode can make its flash-player inside canvas API. I know, it will
> not be 100% compatible. They can create a CanvasAPI based flash player.
> Their are already  2 client side run time engine in JavaScript - Smokescreen
> and Gordon - http://twitter.com/jdowdell/statuses/14985295733 , Biggest
> advantage with JS and client side is that you can see sourcecode. In order
> to hide the source code , Adobe can use server side. Some processing will be
> on server side and output will be streamed (in form of image) to client side
> and renders into CANVAS area with pixel. You can grab event from canvas area
> and send bacl to server. This way Developer may come up with a Server Side
> HTML5 toolkit which will reuse BAD standards like flash with Hiding Source
> code of a Web Application . Adobe or other companies can modify their
> products and generate server side HTML5 code which will render the
> application CANVAS API.
> A huge number of dummy developer use such non-standards tools and with this,
> they will be able to reuse skills by this and will not adopt a true spirit
> of HTML5.
>           So, This I do not like,,,--> ''designer/developers will be using
> non-standard server side code, generated from non-standards ToolKits, and
> pretend that we also use HTML5"

The goal of HTML5 is that all browsers and platforms should be able to
display all web pages, without dependence on any particular software
vendor.  If a company like Adobe writes a framework using
cross-browser, cross-platform, openly specified APIs, we're in a far
better situation than now.  It would really be no different from
jQuery.

Furthermore, it's not *possible* to prevent anyone from writing
toolkits that use HTML5 features.  Or do you have any suggestions to
stop it?