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

Canvas API is just great and I love it, You will also love it , if not, just
see Canvas demos - http://www.canvasdemos.com

But we have potential danger to misuse it also for the sake of
non-standards.

<prediction>
*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"

We urgently need HTML5 authoring tool. we urgently needs SVG authoring
tools.


</prediction>

I *guess*, with the advance of html5, Adobe has been working hard to run
flash on canvas from server inorder to save its presence.


.
-- 
???????????????????????????
?    Narendra Sisodiya
?    http://narendrasisodiya.com
???????????????????????????
Yet another HTML5 Developer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100609/ac5a9424/attachment.htm>

Received on Wednesday, 9 June 2010 11:29:01 UTC