Re: [whatwg] Potential Danger with Canvas API in html5 #html5 #canvas
On Wed, Jun 9, 2010 at 22:05, narendra sisodiya naren...@narendrasisodiya.com wrote: On Thu, Jun 10, 2010 at 12:20 AM, Peter Beverloo pe...@lvp-media.com wrote: On Wed, Jun 9, 2010 at 20:29, narendra sisodiya naren...@narendrasisodiya.com wrote: 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. Hello Narandra, Do you have any links or sources backing up that Adobe is working on the server-side? While your scenario certainly is possible, even with today's possibilities, I see a number of problems with it: No, i do not have any info. I am independent developer who enjoy making predictions - http://blog.narendrasisodiya.com/2010/06/how-and-why-browser-share-ratio-will-be.html 1) The number of simultaneous users in any web application will be severely limited by the available processing power of the server. Thinking of the current uses of Flash, a really large part of which are video players and games, it does not seem realistic. Extend this to Flash applications such as FarmVille on Facebook and server-side processing and rendering will be pretty close to impossible. Yes, you are correct at this points, 2) How exactly is this different from normal webpages? A lot of websites use scripting languages as their back end, such as PHP, delivering a certain flexibility which is not directly visible to the user. The same thing can be applied to achieve creating personalized Application Cache Manifests. PHP script generate HTML code along with JavaScript. It make our task easy. But, Lets imagine if we have a very good Tookkit which have everything for webdesign like buttions, menus, dropdown and final code renders everything in CANVAS. ToolKits may use altogether different higher level sytax to generate canvas based applications. further this toolkit has JavaScript unzip library. then you will be able to create a application in zipped format. Let me explain this more Designer/Developer will use drag and drop based Toolkit which has altogether different higher level sytax which generate CANVAS based application. Toolkit Or some JavaScript code will generate JavaScript code with all resource like image, htmlcode, source code and everything in application directory. Toolkit will zip the whole application and finally designer/developer will get a myfirstgame.wapp Now developer/designer need to write this much code script src=./js/wapp-engine.js/script div class='wapp-application' data-src='./myfirstgame.wapp' width='600' height='800' / This wapp-engine.js will be a wapp player which load myfirstgame.wapp using Ajax and unzip files. Create a dynamic canvas, and render the game in canvas area. So we are using HTML5 canvas but what are we doing Fast and GUI based development tools with a non-standards/proprietary ToolKit for generating a .wapp files which can be distributed and developed easily .wapp will be played in browser will be JS wapp player which render it inside CANVAS API with hiding images, text and everything under pixels which is the prime requirement of many website
Re: [whatwg] audio and video: volume and muted as content attributes?
On Thu, 2010-06-10 at 12:32 +1000, Silvia Pfeiffer wrote: On Thu, Jun 10, 2010 at 12:13 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Thu, 2010-06-10 at 12:03 +1000, Silvia Pfeiffer wrote: On Thu, Jun 10, 2010 at 11:55 AM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Thu, 2010-06-10 at 11:52 +1000, Silvia Pfeiffer wrote: I don't think that is possible in the way that the volume attribute is currently defined as a value between [0;1]. That is an orthogonal, but still important question about the volume attribute then. So, if you say 300%, I assume you mean 3 times louder than what the track is given as? I do wonder how to do that with the current volume attribute - right now the spec says that the default value set is 1.0 [1]. It seems that means we cannot amplify a quiet audio track but have to rely on the user to turn up the volume on their computer? I would actually prefer if the default setting was something like 0.5 and we could then turn the volume up or down in javascript or preferably event through a content attribute as mentioned. Cheers, Silvia. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-volume On Thu, Jun 10, 2010 at 10:05 AM, Kevin Marks kevinma...@gmail.com wrote: Setting volume above 1.0 can be very useful if the original is too quiet. For example, Quicktime allows a volume of 300% to amplify quiet tracks On May 31, 2010 11:30 PM, Philip Jägenstedt phil...@opera.com wrote: On Tue, 01 Jun 2010 14:17:03 +0800, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Tue, Ju... This would make volume even more special, as a float that reflects as an integer percentage. Just using the existing definition for reflecting a float would be simpler. So, I am neither in favor or against of reflecting volume and mute as content attributes. Im... I'd be fine with reflecting muted if many people think it would be useful. I'm not the one to make that judgment though. Volume isn't a huge problem, just not as trivial as one might suspect. Another thing to consider is that it is currently impossible to set volume to a value outside the range [0,1] via the DOM API. With a content attribute, volume=-1 and volume=1.1 would need to be handled too. I'd prefer it being ignored rather than being clamped. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflect Ch... -- Philip Jägenstedt Core Developer Opera Software Or you could just raise the volume of the audio track itself. I think being able to raise the volume like this (beyond 100% of what it is) with script just makes it something more likely to be abused (think how the TV adverts always seem twice as loud as the programs they surround) and so will end up getting blocked more often. That requires editing the resource. Think about it from a process point-of-view: you're a Web developer and have been given a set of media resources to put on a Website. As you put it all together, you notice that the volume of the different files is different and thus playing them back next to each other will create a very confusing user experience. Do you really want to shoot the files back to the production to adjust the volume settings so they are all similar? If you're under time pressure, you'd probably much prefer just
[whatwg] Prefetch issues
As described, the link prefetching capability seems to have some limitations that work counter to the performance of the page using it. It appears as though LINK elements are metadata elements and that these may only be supported inside the HEAD of the document. If so, then this is an issue in the real world, because at the time a web server flushes chunks containing the HEAD section of a document, the links we would want to prefetch are often not known. This is true for all the large sites I've analyzed or worked at. For example, many pages on a site will contain the same visual header, and we want to flush the HEAD and visual header content while the server is in the process of figuring out what the content of the page will be - which will contain the links we'd like to prefetch. Am I reading this correctly? Or is there a something that would allow the flushing scenario I describe above? One of the simplest approaches may be to add support for rel=prefetch to A and AREA's, but it's been explicitly excluded from those. Why? Another approach could be to allow LINK throughout the document. This would allow for prefetching content like images even if you didn't know them at HEAD rendering time. Any opinions?
Re: [whatwg] Prefetch issues
On Thu, Jun 10, 2010 at 17:01, Eric Schurman eri...@gmail.com wrote: As described, the link prefetching capability seems to have some limitations that work counter to the performance of the page using it. It appears as though LINK elements are metadata elements and that these may only be supported inside the HEAD of the document. If so, then this is an issue in the real world, because at the time a web server flushes chunks containing the HEAD section of a document, the links we would want to prefetch are often not known. This is true for all the large sites I've analyzed or worked at. For example, many pages on a site will contain the same visual header, and we want to flush the HEAD and visual header content while the server is in the process of figuring out what the content of the page will be - which will contain the links we'd like to prefetch. Am I reading this correctly? Or is there a something that would allow the flushing scenario I describe above? One of the simplest approaches may be to add support for rel=prefetch to A and AREA's, but it's been explicitly excluded from those. Why? Another approach could be to allow LINK throughout the document. This would allow for prefetching content like images even if you didn't know them at HEAD rendering time. Any opinions? While I have not found the original discussion about including the prefetch relation in area and anchor tags, my guess would be that it's a feature that would quite easily be abused by web authors. Adding @rel=prefetch to all anchors is a lot easier than putting them in the header, so why not just preload every page on the site? Again, someone else will probably have the answer you're looking for. Mozilla's Developer Center has a page about the attribute value[1] which already suggests that they might add the feature on normal anchor tags if there is sufficient interest in that. Their page also contains a chapter about how to implement prefetching using the Link HTTP header, which would be a solution if your website uses output buffering. Considering you're specifically talking about flushing the header before the links are known, however, I'm assuming that won't be a possibility either. The link tag is specifically used for metadata about the current document, so using that across the entire document doesn't sound like a good idea to me. Despite the possibility of abuse by authors, it seems to me that it's a fair use-case for including the attribute. Regards, Peter Beverloo [1] https://developer.mozilla.org/En/Link_prefetching_FAQ
Re: [whatwg] Prefetch issues
Like you do say, the link header doesn't work for exactly the same reason - we'd have already flushed. It does seem like adding rel=prefetch to A and AREA may be the best solution. On Thu, Jun 10, 2010 at 9:46 AM, Peter Beverloo pe...@lvp-media.com wrote: On Thu, Jun 10, 2010 at 17:01, Eric Schurman eri...@gmail.com wrote: As described, the link prefetching capability seems to have some limitations that work counter to the performance of the page using it. It appears as though LINK elements are metadata elements and that these may only be supported inside the HEAD of the document. If so, then this is an issue in the real world, because at the time a web server flushes chunks containing the HEAD section of a document, the links we would want to prefetch are often not known. This is true for all the large sites I've analyzed or worked at. For example, many pages on a site will contain the same visual header, and we want to flush the HEAD and visual header content while the server is in the process of figuring out what the content of the page will be - which will contain the links we'd like to prefetch. Am I reading this correctly? Or is there a something that would allow the flushing scenario I describe above? One of the simplest approaches may be to add support for rel=prefetch to A and AREA's, but it's been explicitly excluded from those. Why? Another approach could be to allow LINK throughout the document. This would allow for prefetching content like images even if you didn't know them at HEAD rendering time. Any opinions? While I have not found the original discussion about including the prefetch relation in area and anchor tags, my guess would be that it's a feature that would quite easily be abused by web authors. Adding @rel=prefetch to all anchors is a lot easier than putting them in the header, so why not just preload every page on the site? Again, someone else will probably have the answer you're looking for. Mozilla's Developer Center has a page about the attribute value[1] which already suggests that they might add the feature on normal anchor tags if there is sufficient interest in that. Their page also contains a chapter about how to implement prefetching using the Link HTTP header, which would be a solution if your website uses output buffering. Considering you're specifically talking about flushing the header before the links are known, however, I'm assuming that won't be a possibility either. The link tag is specifically used for metadata about the current document, so using that across the entire document doesn't sound like a good idea to me. Despite the possibility of abuse by authors, it seems to me that it's a fair use-case for including the attribute. Regards, Peter Beverloo [1] https://developer.mozilla.org/En/Link_prefetching_FAQ
Re: [whatwg] [hybi] WebSockets: UDP
On Thu, Jun 10, 2010 at 12:35 PM, Erik Möller emol...@opera.com wrote: Regarding the discussions on at what level the API of a UDP-WebSocket should be: One of the most important aspects to remember are that for this to be interesting to application developers we need all the browser vendors to support this feature in a compatible way. Therefore it doesn't seem reasonable to standardize and spec a higher level network API akin to RakNet / Torque Socket and hope all vendors will be willing to spend the (quite large amount of) resources required for their own implementation of TCP over UDP, bandwidth throttling etc. In our opinion we're much better off standardizing a minimal UDP-like socket. For most application developers it TorqueSocket is not in the same category as RakNet or OpenTNL -- the point of the TorqueSocket effort was to find the web equivalent of a minimal UDP'ish socket (understanding of course that it would be in the context of a connected packet stream). RakNet and OpenTNL provide higher level data guarantees, RPC, object state replication, etc. TorqueSocket is a simple send/recv packet protocol - it does no TCP over UDP or bandwidth throttling. As discussed the following features/limitations are suggested: -Same API as WebSockets with the possible addition of an attribute that allows the application developer to find the path MTU of a connected socket. -Max allowed send size is 65,507 bytes. I'd recommend doing some real-world testing for max packet size. Back when the original QuakeWorld came out it started by sending a large connect packet (could be ~8K) and a good number of routers would just drop those packets unconditionally. The solution (iirc) was to keep all packet sends below the Ethernet max of 1500 bytes. I haven't verified this lately to see if that's still the case, but it seems real-world functionality should be considered. Some additional points that were suggested on this list were: -Key exchange and encryption If you do want to have key exchange and encryption you really shouldn't reinvent the wheel but rather use a secure WebSocket connection in addition to the UDP-WebSocket. Adding key exchange and encryption to the UDP-WebSocket is discouraged. If WebSocket supports an encrypted and unencrypted mode, why would the real-time version not support data security and integrity? -Client puzzles to reduce connection depletion/CPU depletion attacks to the handshake. If the goal is to prevent DOS attacks on the accepting server this seems futile. Client puzzles only raises the bar ever so slightly for an attacker so this is also discouraged. Client puzzles allow the host to allocate zero resources for a pending connection until it knows that the source address of the client request is valid and that the client has done some work; you could still take a similar (though not client computationally expensive) approach by having the host hash the client identity (IP/port) with a server-generated secret. Any approach that allocates memory or does work on the host without verifying the client source address first is vulnerable to a super-trivial DOS attack (connection depletion before even any bandwidth overwhelm). -Packet delivery notification to be a part of the API. Again this is believed to be better left outside the UDP-WebSockets spec and implemented in javascript if the application developer requires it. I'd propose that doing this in the javascript level would result in unnecessary extra overhead (sequence numbering, acknowledgements) that could easily be a part of the underlying protocol. Having implemented multiple iterations of a high-level networking API, the notification function is a critical, low-overhead tool for making effective higher-level data guarantees possible. Regards, Mark
Re: [whatwg] [hybi] WebSockets: UDP
During the Opera Network Seminar held in Oslo this week I discussed the possible addition of a new wsd: URL scheme to WebSockets that would allow relaxing the packet resends and enable demanding real-time applications to be written. I'd like to summarize some of the conclusions a few of us came to when discussing this (informally). Regarding the discussions on at what level the API of a UDP-WebSocket should be: One of the most important aspects to remember are that for this to be interesting to application developers we need all the browser vendors to support this feature in a compatible way. Therefore it doesn't seem reasonable to standardize and spec a higher level network API akin to RakNet / Torque Socket and hope all vendors will be willing to spend the (quite large amount of) resources required for their own implementation of TCP over UDP, bandwidth throttling etc. In our opinion we're much better off standardizing a minimal UDP-like socket. For most application developers it seems likely they will be able to work with a mix of XMLHttpRequest, WebSockets and this new UDP-WebSocket to achieve the same functionality provided by those higher level APIs. If deemed necessary for an application the higher level network API can be written in JavaScript and work on-top of the much smaller hopefully cross-browser compatible UDP-WebSocket API. As discussed the following features/limitations are suggested: -Same API as WebSockets with the possible addition of an attribute that allows the application developer to find the path MTU of a connected socket. -Max allowed send size is 65,507 bytes. -Socket is bound to one remote address at creation and stays connected to that host for the duration of its lifetime. -IP Broadcast/Multicast addresses are not valid remote addresses and only a set range of ports are valid. -Reliable handshake with origin info (Connection timeout will trigger close event.) -Automatic keep-alives (to detect force close at remote host and keep NAT traversal active) -Reliable close handshake -Sockets open sequentially (like current DOS protection in WebSockets) or perhaps have a limit of one socket per remote host. -Cap on number of open sockets per host and global user-agent limit. Some additional points that were suggested on this list were: -Key exchange and encryption If you do want to have key exchange and encryption you really shouldn't reinvent the wheel but rather use a secure WebSocket connection in addition to the UDP-WebSocket. Adding key exchange and encryption to the UDP-WebSocket is discouraged. -Client puzzles to reduce connection depletion/CPU depletion attacks to the handshake. If the goal is to prevent DOS attacks on the accepting server this seems futile. Client puzzles only raises the bar ever so slightly for an attacker so this is also discouraged. -Packet delivery notification to be a part of the API. Again this is believed to be better left outside the UDP-WebSockets spec and implemented in javascript if the application developer requires it. Best Regards, -- Erik Möller Core Developer Opera Software
[whatwg] Revisiting MIDI - device and audio
Hello All, Thought I'd review the topic of supporting MIDI devices in HTML 5. My initial post about MIDI treated the format as a text stream: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/026524.html Let's start looking at the device tag. a MIDI device, is, quite surely, a device. http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#devices I'd warn, that while MIDI is typically thought of as a media device, it's actually just a plain old Event Source. It seems that Stream is appropriate (enough), to enable MIDI support in the browser. It's a light event source. It also seems that the peer-2-peer section allows for multiple device streams; whereas the simple device section allows only one media device (a webcam). MIDI does require the ability to handle multiple event sources, for live-use. -Charles
Re: [whatwg] IDL attribute reflecting enumerated attributes not limited to only know values
On 6/8/10 5:26 PM, Mounir Lamouri wrote: Hi, According to the HTML5 specification, an IDL attribute reflecting an enumerated attribute will have the default reflecting behavior (ie. return the content attribute on getting and setting it on setting) except if the attribute is limited to only known values [1]. There are three attributes limited to only known values in the current state of the specs: @dir, @shape (area element) and @keytype (keygen element). In other words, that means if @toto is an enumerated attribute with foo and bar states/keywords and foo as a default missing value, if @toto is set to foobar, .toto will return foobar. To have .toto returning foo, the attribute has to be limited to only known value. Having .toto returning foo in this situation seems to be what we should expect because the content attribute is already accessible with @toto. An example where this behavior seems buggy: - input.type and button.type: every browser makes it return text if @type isn't set to a known value. If we follow the specifications, .type should return the current value of @type. Examples where having another behavior would help: - method, formmethod, enctype and formenctype have a list of keywords/states with a default missing value. It would be great to have the IDL attribute returning the current state instead of the content. So, scripts wouldn't have to look at the content, checking for values they know and falling-back to the default value to know the current state. - input.autocomplete: at the moment, it is returning the content but it could return the resulting autocompletion state which is maybe a bit more than just being limited to only known values but still in the same spirit. Maybe, instead of having some attributes limited to only known values we could have some attributes not limited to only known values, thus inverting the default reflecting behavior for enumerated attriutes ? Yeah, this sound ok to me. The current enumerate attribute handling is weird and at least in some cases just buggy. -Olli [1] http://dev.w3.org/html5/spec/Overview.html#limited-to-only-known-values Thanks, -- Mounir
