Re: [whatwg] BWTP for WebSocket transfer protocol
Thanks for the heads-up. This comes at an auspicious time, because we're now starting on WebSocket implementation in WebKit, and the implementation seems likely to someday ship in Safari, Chrome and other WebKit-based browsers. For what it's worth, we are not absolutely wedded to the details of either the API or the protocol, but we feel pretty strongly about delivering the basic functionality. This proposal looks a bit more complicated than the WS protocol, so it may take a bit to digest. Regards, Maciej On Aug 6, 2009, at 5:59 PM, Greg Wilkins wrote: All, on the IETF Hybi mailing list there has been some discussion regarding the protocol that should carry WebSockets. There was considerable divided opinions about the style of protocol that would be most appropriate and what level of features should be supported etc. That conversation ground to a stale mate as I think considerably different view points were involved. So it was decided by some to prepare an alternate transport protocol proposal. At the very least, this proposal would serve better illustrate many of the concerns and ideas that are difficult to express in long email threads. Hopefully, this proposal may influence the eventual design of the websocket proposal, or it might grow to become a real contender as an alternative (which currently it is not - lacking vital elements such as working implementations and wide peer review). Anyway, I'd like to invite the participants of this list to give the BWTP proposal some consideration and review: http://bwtp.wikidot.com I suggest reading the rational page http://bwtp.wikidot.com/main:rational first before looking at the proposal: http://bwtp.wikidot.com/main:proposal regards
Re: [whatwg] File API features in HTML5
On Thu, Aug 6, 2009 at 4:43 PM, Ian Hickson wrote: > With Arun's announcement of a stable File API spec [1], I have now updated > HTML5 to handle the use cases listed below. > > [1] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html > > On Thu, 22 Jun 2006, ivan vadovic wrote: >> >> Is there any advanced DOM API planned for file upload? For example, how >> can a script find out how many files is the user about to submit? > > I've just added input.files to handle this case. For the record, this works in Firefox 3.5 already (I believe it also works in Firefox 3.0), so people can test out this API already. Feedback would be excellent. > On Mon, 30 Apr 2007, Ian McKellar wrote: >> On 4/25/07, David Hyatt wrote: >> > The use case of being able to drop images into a contenteditable >> > region and have them show up as elements at the appropriate >> > place and then get automatically uploaded somewhere is a really >> > compelling one. >> >> This is basically what we implemented in Flock. We also supported drag >> and drop to text areas, though that's a little tricker since it's hard >> for the user agent to work out how to embed images correctly. At the >> basic level there's HTML vs BBCode syntax, beyond that different sites >> filter different sets of tags and attributes in different fields (for >> example on Flickr img tags are allowed in some fields in your profile >> but not in others). > > I've added dataTransfer.files to the drag-and-drop interface. This is implemented in recent firefox nightlies. Please test this out and give feedback! > I'm not sure how to expose the presence of data during the drag, though. I think we currently list "application/x-moz-file" in the .types property. Obviously we'd like to use a better type than that. Could we simply use "application/file"? Do we need to register the type with IANA? I expect yes. Alternatively we could add mimetypes of the actual files (as returned my File.mediaType), however then it won't be possible to differentiate a "text/plain" file, from a string. There also more privacy issues with exposing the mimetypes of the files during "drag" events so I think i'd like to stay away from that for now. / Jonas
Re: [whatwg] An BinaryArchive API for HTML5?
On Tue, 4 Aug 2009, Gregg Tavares wrote: > > > > > > Do you have some suggestions for how the data could be transferred > > > most efficiently to the glBufferData call? As far as I know there is > > > no tag which could be used to refer to the binary file within the > > > archive. If there were then presumably it could provide its contents > > > as a CanvasFloatArray or other type. > > > > We are waiting for the File API specification to be stable, but one > > that exists, I would expect it to be used for this kind of thing: > > I'm a little confused? Are you saying the File API is part of HTML5 or > not? The File API is a separate spec: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml > Without archive support the File API is not sufficient for the above use > case because a typical WebGL app will need to download hundreds of these > types of files and it would want to download them compressed. Ah, indeed. Yeah, in that case you probably want an IETF-level spec like multipart/related, with a URL scheme to refer to subfiles within it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] BWTP for WebSocket transfer protocol
All, on the IETF Hybi mailing list there has been some discussion regarding the protocol that should carry WebSockets. There was considerable divided opinions about the style of protocol that would be most appropriate and what level of features should be supported etc. That conversation ground to a stale mate as I think considerably different view points were involved. So it was decided by some to prepare an alternate transport protocol proposal. At the very least, this proposal would serve better illustrate many of the concerns and ideas that are difficult to express in long email threads. Hopefully, this proposal may influence the eventual design of the websocket proposal, or it might grow to become a real contender as an alternative (which currently it is not - lacking vital elements such as working implementations and wide peer review). Anyway, I'd like to invite the participants of this list to give the BWTP proposal some consideration and review: http://bwtp.wikidot.com I suggest reading the rational page http://bwtp.wikidot.com/main:rational first before looking at the proposal: http://bwtp.wikidot.com/main:proposal regards
[whatwg] Possible typo in application cache section
6.9.4, paragraph 7 says, “applications caches never include fragment identifiers” and I think this should just be “application caches”. -- Darin
Re: [whatwg] scripts, defer, document.write and DOMContentLoaded
On Sat, 1 Aug 2009, Boris Zbarsky wrote: > > Ian Hickson wrote: > > I've changed the spec to do external deferred src=""ed scripts at the end of > > document load (blowing away the document as before), and inline deferred > > scripts as soon as innerHTML is set, if it is set, or else along with other > > deferred scripts at the end of document load. > > Another possible, less magic, option here is to simply not support defer on > inline scripts. Good idea. Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5 Script Tag
On Thu, Aug 6, 2009 at 6:52 PM, Aryeh Gregor wrote: > On Thu, Aug 6, 2009 at 7:46 PM, Tab Atkins Jr. wrote: >>
Re: [whatwg] HTML 5 Script Tag
On Fri, Aug 7, 2009 at 1:14 AM, Cready, James wrote: > You make a great point. But whether or not you use the XML/XHTML > or the HTML 4 doesn¹t matter much. Since like I showed in my > previous example: the instant you specify a src attribute on your opening > tag the browser will not execute anything inside the tags. You are quite missing the point: see this example:Hello World!
Unless you serve this as XHTML (with an XML mimetype), nothing will be shown on the browser. Let's see why: text/html triggers the browser's tag-soup parser, which fixes issues on the fly. The first issue it finds is the straneous trailing slash on the script, which it just ignores. Then, is probably taken as literal (as if you had typed </head>), because the can't be closed until the