Re: [whatwg] Event handlers - Pointer Devices
This kind of discussion should happen in W3C WebApps WG, using DOM mailing list (www-...@w3.org). There as been some discussion about this subject and I hope there would be a draft spec somewhat soon. (This all may depend on patent nonsense.) -Olli On 2/26/10 12:37 AM, dpenk...@gmail.com wrote: This is a timely call for interest. Additionally I would like to sollicit thoughts on the ideal level of abstraction such event API's should provide. Some random examples for illustration. Low level: TouchDown(...) onTouchMove() onTouchUp() with each reporting and tracking pressure and position of multiple fingers so that gesture recognition can be done in the script Mid Level: onTap(), onDoubleTap(), onLongTouch(), onDrag(), onPinch()position but no pressure reported High Level: onRotate(), onScroll(), onResize()gesture reported The complexity and number of problems to overcome to produce a clean API is much greater for higher levels of abstraction. On a related note it would be useful for tablets and smartphones to also handle other sensors such as accelerometers onShake(), onOrientationChange() I believe Palm has done some stuff to support this. At a lower level you can get raw accelerometer data too. -dave On Feb 25, 2010 10:00pm, Charles Pritchard ch...@jumis.com wrote: Hi All; I'd like to know if there's room or any work has been done to set aside a standard for an extended set of pointer-device events. With touch screens and touch sensitivity becoming quite main-stream, I'd like to see this popular functionality supported by the HTML 5 standard. We see, in the iPhone, an ontouchstart and ongesturestart, and company. Gesture is a nice way of saying multiple inputs, and it works well. While many people would like to wrap the ontouch events into onmouse events -- they do have some different semantics. And, I believe that ontouch would be a good place to add in pressure sensitivity indexes. So, I thought I'd solicit feedback here. I'd like a common API to support touch screens and pressure/angle sensitive touch devices. I believe that both Apple and Wacom have thrown their hats into the ring, and we can easily integrate their achievements. -Charles
Re: [whatwg] HTML Cookie API
What about something like:
document.pushCookies(function () {
// cookies have been pushed to the js process
var x = document.getCookie(x);
// whatever...
});
This seems similar to Adam's proposed document.getAllCookies.
-Darin
No. pushCookies would be a way of pushing cookies to the current js and
then you could call getCookie several times without defining a callback.
It would be almost like:
document.observe(cookieload, myAppLoad)
Re: [whatwg] Drag-and-drop feedback
On Mon, Feb 22, 2010 at 6:06 PM, Daniel Cheng dch...@google.com wrote: Several questions about the proposal: How does DataTransferItems interact with the original DataTransfer object? I'm assuming changes in one should be reflected in the other. If that's the case, what should happen if I do this: dataTransfer.items.add(fileData); dataTransfer.getData(mimeTypeForFile); Unless there is a specific reason to think different, there is only one set of items backing DataTransfer object - today the files and 'other items' are represented separtely, the proposed items list is simply a merged version of the same. In your example you should be able to getData. How come there's no DataTransferItems.get(type) method? There can be multiple items of that type (dragging several image files). Would it return another items list? What is the use case for this? Also, some items may have empty type (a file with unknown extension). DataTransferItem provides richer metadata than is available through the native drag-and-drop interface on most platforms. When dragging data from a non-DOM application, how do you extrapolate the metadata to fill in the type/binary fields? 'type' can be inferred in many cases from file extension, native clipboard format or other means. It can be done w/o content sniffing and disk IO. I understand 'binary' as indicator of whether or not the item can be read as a text string. I'm not sure why item.kind == string is not the same. If the intent is to also cover some files that can be read as string and as Blob, then it might be buggy because the only way to establish if the file can be converted into JS string is to actually read the bytes and try to convert to Unicode. There can be invalid character sequences or the encoding info may be missing. Perhaps we should remove 'binary' and assume that items that item.kind == string can use getTextData(callback) to pull the string. On a separate note, I think items.add(dataTransferItem) is not useful w/o a way to create a new DataTransferItem separately from the DataTransferItems list. Daniel On Mon, Feb 22, 2010 at 3:51 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 4 Feb 2010, Ian Hickson wrote: On Sat, 23 Jan 2010, Eduard Pascual wrote: Would it be possible to provide a list of drag items (to call them somehow) instead of, or in addition to, the current info provided by the DataTransfer object? That's a pretty good idea. I think we should probably do this when we add more types to the DataTransfer object. Some engineers at Google discussed this a bit and came up with the following proposal: dataTransfer.items = DataTransferItems DataTransferItems.length .getItem(n) = DataTransferItem .add(stringData, type) .add(blobData) .add(fileData) .add(dataTransferItem) .clear() DataTransferItem.kind = 'string', 'file', 'blob', ... .type = MIME type .binary = boolean .getTextData(function callback (data)) - throws if binary is true .getBlob() - returns File or Blob When we add promises later, this can easily be extended to support that as well (basically, just by adding a new add() method for the promise case). I've put this into the comment in the spec, but haven't specced it. If any browser vendors want to try implementing this or something like it, any reports of implementation experience would be very useful. Please prefix the items attribute with some unique string like webkitItems or geckoItems so that it doesn't clash with the spec when we do add something like this! Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding FormData support to form
On Fri, Feb 19, 2010 at 8:52 AM, Dmitry Titov dim...@google.com wrote: On Thu, Feb 18, 2010 at 8:45 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 17, 2010, at 3:15 PM, Jonas Sicking wrote: The reason this is a function rather than a read-only attribute is to allow the return FormData to be further modified. I.e. the following should be allowed: fd = myFormElement.getFormData(); fd.append(foo, bar); xhr.send(fd); If it was a property I would be worried about people expecting the following to work: myFormElement.formData.append(foo, bar); xhr.send(myFormElement.formData); However I don't think there is a good way to make the above work. Thus my suggestion to use a function instead. I'm writing a prototype implementation over in [2] People could imagine that this should work: myFormElement.getFormData().append(foo, bar); xhr.send(myFormElement.getFormData()); In either case, it seems that once they see it doesn't work, they will no longer expect it to work. Sure, but a better name could help a bit. For example, this produces a 'shared' object: document.getElementById(foo) while this creates a new one: myFormElement.getFormData() It might be ok, but it is a bit inconsistent. Why not: formData = new FormData(); formData = new FormData(myFormElement); ah... +1 the ctor Regards, Maciej
Re: [whatwg] HTML Cookie API
On Fri, Feb 26, 2010 at 10:56 AM, Diogo Resende drese...@thinkdigital.ptwrote:
What about something like:
document.pushCookies(function () {
// cookies have been pushed to the js process
var x = document.getCookie(x);
// whatever...
});
This seems similar to Adam's proposed document.getAllCookies.
-Darin
No. pushCookies would be a way of pushing cookies to the current js and
then you could call getCookie several times without defining a callback.
It would be almost like:
document.observe(cookieload, myAppLoad)
Right. My point was that you could implement pushCookies on top of Adam's
API.
-Darin
Re: [whatwg] HTML Cookie API
No. pushCookies would be a way of pushing cookies to the current js and then you could call getCookie several times without defining a callback. It would be almost like: document.observe(cookieload, myAppLoad) Right. My point was that you could implement pushCookies on top of Adam's API. -Darin Agree. Just like you could implement Adam's API on top of current browsers cookies spec :P
Re: [whatwg] HTML Cookie API
On Fri, Feb 26, 2010 at 12:04 PM, Diogo Resende drese...@thinkdigital.ptwrote: No. pushCookies would be a way of pushing cookies to the current js and then you could call getCookie several times without defining a callback. It would be almost like: document.observe(cookieload, myAppLoad) Right. My point was that you could implement pushCookies on top of Adam's API. -Darin Agree. Just like you could implement Adam's API on top of current browsers cookies spec :P No, I don't think that is possible. Adam's spec reveals a lot of extra information that document.cookie does not return. For example, it exposes domain and expiry information. But, I think your point was that it would be possible to simulate an asynchronous API on top of a synchronous one. I agree that is possible, but it would not perform very well. Regards, -Darin
Re: [whatwg] Adding FormData support to form
On Feb 26, 2010, at 11:37 AM, Michael Nordman wrote: Sure, but a better name could help a bit. For example, this produces a 'shared' object: document.getElementById(foo) while this creates a new one: myFormElement.getFormData() It might be ok, but it is a bit inconsistent. Why not: formData = new FormData(); formData = new FormData(myFormElement); ah... +1 the ctor Indeed, constructor syntax makes it very clear that you are getting a new object. I like. - Maciej
Re: [whatwg] HTML Cookie API
On Fri, Feb 26, 2010 at 12:20 PM, Darin Fisher da...@chromium.org wrote: On Fri, Feb 26, 2010 at 12:04 PM, Diogo Resende drese...@thinkdigital.pt wrote: No. pushCookies would be a way of pushing cookies to the current js and then you could call getCookie several times without defining a callback. It would be almost like: document.observe(cookieload, myAppLoad) Right. My point was that you could implement pushCookies on top of Adam's API. -Darin Agree. Just like you could implement Adam's API on top of current browsers cookies spec :P No, I don't think that is possible. Adam's spec reveals a lot of extra information that document.cookie does not return. For example, it exposes domain and expiry information. But, I think your point was that it would be possible to simulate an asynchronous API on top of a synchronous one. I agree that is possible, but it would not perform very well. Another problem is that some current browsers do not implement document.cookie in a non-racy way. So while you could implement Adams API, you couldn't guarantee that it wouldn't be racy. However implementations should be able to implement Adams asynch API with no race problems. / Jonas
Re: [whatwg] Adding FormData support to form
On Fri, 26 Feb 2010 23:28:12 +0100, Maciej Stachowiak m...@apple.com wrote: On Feb 26, 2010, at 11:37 AM, Michael Nordman wrote: Sure, but a better name could help a bit. For example, this produces a 'shared' object: document.getElementById(foo) while this creates a new one: myFormElement.getFormData() It might be ok, but it is a bit inconsistent. Why not: formData = new FormData(); formData = new FormData(myFormElement); ah... +1 the ctor Indeed, constructor syntax makes it very clear that you are getting a new object. I like. I could add this to XMLHttpRequest Level 2. -- Anne van Kesteren http://annevankesteren.nl/
