Re: [whatwg] history.back()
On Jan 21, 2010, at 8:37 PM, Darin Fisher wrote: On Thu, Jan 21, 2010 at 7:15 PM, Maciej Stachowiak m...@apple.com wrote: I asked Brady (the Safari/WebKit engineer who implemented pushState()) about this, and he told me he found that in the pushState case it sometimes made things easier from the authoring side for history.back() to be synchronous. But I don't have the details. Brady and I have been discussing this too. I'm not convinced that synchronous history.back() makes things significantly better for content authors. Indeed, I'm concerned that it makes things worse. Here's what I mean: If history.go() sometimes results in the history traversal completing synchronously (hash change) and sometimes not (navigation required), then there is a loss of predictability for the programmer. They have to deal with event dispatch sometimes happening in a re-entrant manner, but other times not. A consistent model seems better to me. I don't really have strong feelings about this at present. But I think the most important deciding factor should be what is the best behavior for authors. It seems like the implementation details are something that can be worked out either way, so implementation challenge should be a tiebreaker at best. You are correct that consistency is good. However, whether a navigation to a different document is asynchronous can barely be observed - it's not like any code from the current document will run after the navigation anyway. For within-document navigations, I could imagine synchronous behavior might make some things easier to code - you could call history.back() to pop the state stack, and your code running afterwards could assume you'd successfully traversed to the new state. On the other hand, I could also imagine it's harder. And history.back is probably not used all that much in modern Web apps anyway. That's why I don't have a very good picture of which approach is better. Regards, MAciej
Re: [whatwg] history.back()
On Thu, 21 Jan 2010, Darin Fisher wrote: In WebKit, history.back() is currently implemented asynchronously. It's not clear to me what you mean by asynchronously. Do you mean that the events fire asynchronously? That the Location object is updated asynchronously? That the decision about whether the call is a noop or not is fired asynchronously? That the navigation, if one is necessary, is done asynchronously? Are we talking about same-frame, or cross-frame? Same-origin, or cross-origin? Traversal from one entry in one document to another entry in the same document, or in another document? I made some demos to test this out, and it seems that IE8 behaves differently whether it's cross-frame or same-frame. I'd really rather we define this in a way that is consistent for all ways of invoking the API. It does the Location changes synchronously if invoked in-page, and asynchronously if the traversal affects another page. For simple cases, Firefox consistently does the Location change synchronously. Opera (10.x on Windows), Safari (4 for Windows), and Chrome do it async. But complicated cases make these descriptions simplistic. http://www.hixie.ch/tests/adhoc/dom/level0/history/sync-vs-async/ IE however appears to implement history.back() asynchronously in all cases just like newer versions of WebKit. That doesn't appear to be completely accurate. From a web compat perspective, it seems wise to match the behavior of IE. It also has other benefits. Can we change the spec? Yes, but that won't make it async if the goal is to match IE. On Thu, 21 Jan 2010, Jonas Sicking wrote: Sounds good to me. Having all navigation be asynchronous I suspect would have implementations benefits in Gecko too. It would be a reasonably minor change to the spec. I'm happy to go either way on this. The problem is I don't know exactly what async vs sync really means in this context, since the algorithms are quite complicated. On Thu, 21 Jan 2010, Olli Pettay wrote: And still one thing to test and specify; if history.back()/forward() is asynchronous, does that mean that loading start asynchronously, or that entries are added asynchronously to session history? What should happen if a page calls: history.back(); history.forward(); What if the page calls: history.back(); history.go(-2); Indeed. There are the kinds of questions I am curious about. Another is what should happen if a page goes back() past its fragment identifier entries, and then modifies the document or alerts the location? What location should it get? Which document should it mutate? (test 007) How about: location.hash = 'a'; /* spin event loop */ history.back(); location.hash = 'b'; history.forward(); alert(location.hash); /* spin event loop */ alert(location.hash); What does this alert? (test 008) How about: location.hash = 'x'; location.hash = 'a'; /* spin event loop */ history.back(); /* spin event loop */ history.forward(); location.hash = 'b'; /* spin event loop */ history.back(); /* spin event loop */ alert(location.hash); What does this alert? (test 010) And btw, some of the session history handling is anyway synchronous. Per the current HTML5 draft calling document.open() adds a new entry to session history immediately (IIRC, webkit is the only one which doesn't support this). Another example is navigating to a fragment identifier, which in all browsers I tested changes the Location object immediately also. As I see it these are the criteria that we have to consider here in making a decision, in order of importance: * Compatibility. It seems that browsers are quite inconsistent here, and so it's likely that we have some room to maneuver. Nobody has mentioned any particular bugs in sites caused by implementing this one way or another. I am not convinced that compatibility is a factor at this point. * Consistency for authors I think whatever solution we come up with we should make sure it is sane for authors. In this case, however, pretty much any model works, so this doesn't really help decide what is best, so long as we are consistent in how we specify and implement it. * Implementation concerns This may be the deciding factor, in particular due to the multiprocess session history issues Darin raised. * Specification sanity I think we can probably make any model work in the spec, without even much of a rewrite being needed. It's just a matter of saying when things happen, for which the spec now has considerable infrastructure. Does anyone have any opinions on how the examples above should work? How should document.open() and location's setter interact with history.back()? Should navigation to fragment identifiers asynchronously set Location? Should Location be set synchronously but with the session history actually being updated asynchronously using a task, so
Re: [whatwg] Web-sockets + Web-workers to produce a P2P website or application
On 22/01/2010, at 07:08, Ivan Žužak izu...@gmail.com wrote: On Fri, Jan 22, 2010 at 03:33, Andrew de Andrade and...@deandrade.com.br wrote: comments inline - A naive P2P implementation won't provide good throughput or latency because you might end up downloading files from a mobile phone on the other side of the world rather than a high performance CDN node inside your local ISP. That sucks for users and also sucks for your ISP who will probably find their transit links suddenly saturated and their nice cheap peering links with content providers sitting idle. Any ideas on how this could be resolved? I figure if the application is popular enough, the peers could be geographically tagged using the GPS functionality of HTML5. Clients would automatically get better connections and throughput and preference if they choose to make their location available to the torrent server so that peers can look up peers nearby. Good idea. Also, not all content would be declared to be served by clients. E.g. the index page of a web application could be served by the origin server, while some other content (scripts? images?) linked to from the index page could be fetched from nearby clients (e.g. when the client requests the index page from the server, the server could also point to nearby clients serving images). Ivan All these complementary features of HTML5 are one reason I figured that this may be an interesting idea to suggest here instead of the IETF, however it's entirely possible that this idea should be implemented at both the browser and the web application level. Clearly it doesn't make sense to make every web app developer implement a lot of the heavy p2p work at the application layer, on the other hand features like geolocation, manifests, etc may be complementary features to make this idea more robust and performatic. another idea maybe to have the web app's bittorrent file added as a server side include in the index.html file just like CSS files are, thus giving the browser an option on how to best handle the page. Andrew de Andrade @andrewdeandrade
Re: [whatwg] Web-sockets + Web-workers to produce a P2P website or application
My 2c (as of talking to myself trying to figure out how to do a prototype of this)... I'm not sure where such service would belong, but it would suffer the same problem that early VoIP systems suffered behind a firewall... While one would be able to open a socket and serve data, there would have to be some kind of uPnP or NAT integration to make it visible to the web (or a tunneling solution as those old http-tunnel stuff). Apart from that, I think it would be something like embedding a webserver (or better yet embedding node.js [http://nodejs.org/]) in the same level as the javascript API is implemented and allow pure or pre-arranged sockets to be open. AFAIK, using websockets, the browser initiates a connection with the server, which will proceed upgrading the connection type and opening a two way communication with the server and from now on the application defines the line protocol. At least is what I gathered when doing this: http://github.com/gleicon/txwebsockets That way, apart from the browser doing this 2-way connection, it could open a standard tcp socket, or better, a kind of special server and register itself on a DHT or tracker (that I think would need to be an obligatory step). The p2p like mesh network is a great idea, but I think it would take some security heads thinking around on what socket/server models it would be safe to let a browser start, a framework for the tracker registering and a sandbox akin to crossdomain.xml to protect it from turning to a giant botnet. I think this kind of thinking would be great with w3c behind it (and a wide open discussion on security issues), as I think the node.js approach could be quicker to implement browser-wise... gm On Fri, Jan 22, 2010 at 6:58 AM, Ivan Žužak izu...@gmail.com wrote: On Fri, Jan 22, 2010 at 03:03, Andrew de Andrade and...@deandrade.com.br wrote: comments inline On Thu, Jan 21, 2010 at 5:44 PM, Ivan Žužak izu...@gmail.com wrote: As your Google friend noted, I'm wondering why you'd want to implement this on the HTML5 level, not on the browser (C++) level. Implementing such a protocol within the browser would probably be faster, more secure and a better design choice since the functionality is basically the same for every web application. I'm guessing the reason is that you do not want to achieve this by changing/extending the browser but rather by using new HTML5 technologies instead. Am I right? While I realize that this is best implemented at the browser level, my concern is if it will be an idea that would be broadly adopted by all browser vendors if it is implemented at that level. It's an idea that really has value once you've reached critical mass. For example, this would be an extremely potent idea if the two most popular browsers have implemented this by 2014 to 2015 or so. HTML5 is a web technology spec. I imagine that putting it in the spec would greatly increase the chances of browsers supporting this functionality. However, I am not familiar with the politics that govern whether or not browser product managers implement these features at the browser level? Being pragmatic, do you think it's possible to get widespread adoption quickly for a feature like this as the browser level or do you agree that this would be more likely to be adopted quickly if it was part of a W3C spec? I think there are two separate issues here. First, if this idea is to be widely adopted and implemented - I believe there must be an open specification of it. And there are basically two ways of doing this - by having it proposed by a specific browser vendor or by having it proposed by a standardization organisation like the W3C or IETF. And yes, you're right - having something proposed by W3C versus a specific browser vendor - I'd say it's more likely to catch on if the W3C puts it foot behind it. Second, there is a difference between a) implementing the idea in the browser engine versus b) implementing it as a part of the application executing on the browser engine. The same functionality can be achieved by defining a protocol which browsers would implement as a part their engine (e.g. using some other available protocol instead of WebSockets (e.g. plan old HTTP or SPDY) and threads instead of WebWorkers) or by creating web applications where each application would implement this protocol itself using application level technologies (i.e. the proposed WebSockets and WebWorkers tech). In essence, it doesn't matter which technology you use to implement it as long as it implements the protocol you define. So, since technologies used for implementation are open and available, why would the W3C wan't this implemented at the application level versus the browser level? Both scenarios require changes to both the server of an application and the browser. If so, then a major problem is that the browser is not a network server, rather only a client. In order for
Re: [whatwg] Web-sockets + Web-workers to produce a P2P website or application
On Fri, Jan 22, 2010 at 6:58 AM, Ivan Žužak izu...@gmail.com wrote: I think there are two separate issues here. First, if this idea is to be widely adopted and implemented - I believe there must be an open specification of it. And there are basically two ways of doing this - by having it proposed by a specific browser vendor or by having it proposed by a standardization organisation like the W3C or IETF. And yes, you're right - having something proposed by W3C versus a specific browser vendor - I'd say it's more likely to catch on if the W3C puts it foot behind it. I'm wondering if anyone from either webkit, mozilla, opera, the W3C or IETF can chime in here and shed light on what the correct process would be to present this idea for consideration either as a standard (W3C or IETF) or for browser adoption as open code (Webkit, Mozilla, Opera, etc.) Second, there is a difference between a) implementing the idea in the browser engine versus b) implementing it as a part of the application executing on the browser engine. The same functionality can be achieved by defining a protocol which browsers would implement as a part their engine (e.g. using some other available protocol instead of WebSockets (e.g. plan old HTTP or SPDY) and threads instead of WebWorkers) or by creating web applications where each application would implement this protocol itself using application level technologies (i.e. the proposed WebSockets and WebWorkers tech). In essence, it doesn't matter which technology you use to implement it as long as it implements the protocol you define. So, since technologies used for implementation are open and available, why would the W3C wan't this implemented at the application level versus the browser level? Both scenarios require changes to both the server of an application and the browser. It appears to me that implementing it at the application level would create a richer development environment for web app devs to exploit the underlying features more directly. Anyone have any other ideas as to the pros and cons of implementing this at the browser level or the web app level? I'm not familiar with NAT traversal or what other novelties IPv6 introduces other than a broader address space, so I may be wrong when saying this but - only by switching from IPv4 to IPv6 will not solve this problem. The browser would still be a client initiating connections to other network entities, not a server accepting connections from those clients. Or as Mike put it: WebSockets doesn't let you open arbitrary ports and listen on them. I'm not getting into how hard this is to do, I'm just saying that it's something which is necessary. The only familiarity I have with IPv6 are my Apple Airport routers at home. I know there are different options like node or tunnel in the settings page. It sounds like that if your computer is connected as a node, your router is connected as a tunnel and your provider supports IPv6, then this should all work with IPv6 without lots of complications. Given the time it would take to coordinate and execute and idea like this, I figure that it may be best to develop the idea with IPv6 as the primary layer 2 protocol. Someone please correct me if I am mistaken. I believe Todd from HighScalability will like the idea. It's a direction in which lots of people see the Internet/WWW going. I hope you didn't get me wrong with my comments - I like your idea of distributing the load towards clients. I sent a message to Todd alerting him of this thread, so that he can take a look and consider blogging about it if it seems interesting to him. I didn't get you wrong on the comments. There's tons of brilliant people participating in the WHAT-WG mailing lists and as I only have an idea and I don't have the technical knowledge, I figured this would be the best place to get comments, criticisms and feedback. The more critical people are about the idea the better. Discussion leads to better developed ideas.
Re: [whatwg] history.back()
On 1/22/10 4:13 AM, Maciej Stachowiak wrote: However, whether a navigation to a different document is asynchronous can barely be observed - it's not like any code from the current document will run after the navigation anyway. If the script is navigating its own document, yes. If it's navigating a subframe or popup window, it's pretty easy to observe whether the navigation is synchronous. -Boris
Re: [whatwg] history.back()
On Fri, Jan 22, 2010 at 1:13 AM, Maciej Stachowiak m...@apple.com wrote: On Jan 21, 2010, at 8:37 PM, Darin Fisher wrote: On Thu, Jan 21, 2010 at 7:15 PM, Maciej Stachowiak m...@apple.com wrote: I asked Brady (the Safari/WebKit engineer who implemented pushState()) about this, and he told me he found that in the pushState case it sometimes made things easier from the authoring side for history.back() to be synchronous. But I don't have the details. Brady and I have been discussing this too. I'm not convinced that synchronous history.back() makes things significantly better for content authors. Indeed, I'm concerned that it makes things worse. Here's what I mean: If history.go() sometimes results in the history traversal completing synchronously (hash change) and sometimes not (navigation required), then there is a loss of predictability for the programmer. They have to deal with event dispatch sometimes happening in a re-entrant manner, but other times not. A consistent model seems better to me. I don't really have strong feelings about this at present. But I think the most important deciding factor should be what is the best behavior for authors. It seems like the implementation details are something that can be worked out either way, so implementation challenge should be a tiebreaker at best. That's fair, and I completely agree in principle. The reality of the situation of course is that implementation challenges matter a lot. If implementation costs are high and the benefits of modifying the code are relatively low, then we are likely to end up with browsers having inconsistent behavior for some time. You are correct that consistency is good. However, whether a navigation to a different document is asynchronous can barely be observed - it's not like any code from the current document will run after the navigation anyway. For within-document navigations, I could imagine synchronous behavior might make some things easier to code - you could call history.back() to pop the state stack, and your code running afterwards could assume you'd successfully traversed to the new state. On the other hand, I could also imagine it's harder. And history.back is probably not used all that much in modern Web apps anyway. That's why I don't have a very good picture of which approach is better. Isn't this what popstate and hashchange notifications are for? Afterall, the user could also press the back button, and the developer would probably be concerned with that case too. -Darin Regards, MAciej
Re: [whatwg] history.back()
On Fri, Jan 22, 2010 at 2:08 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 21 Jan 2010, Darin Fisher wrote:
In WebKit, history.back() is currently implemented asynchronously.
It's not clear to me what you mean by asynchronously.
Do you mean that the events fire asynchronously? That the Location object
is updated asynchronously? That the decision about whether the call is a
noop or not is fired asynchronously? That the navigation, if one is
necessary, is done asynchronously? Are we talking about same-frame, or
cross-frame? Same-origin, or cross-origin? Traversal from one entry in one
document to another entry in the same document, or in another document?
To clarify:
history.{back,forward,go} begin by scheduling a task on the current thread
to run later. From that task, the history traversal algorithm is executed.
I made some demos to test this out, and it seems that IE8 behaves
differently whether it's cross-frame or same-frame. I'd really rather we
define this in a way that is consistent for all ways of invoking the API.
It does the Location changes synchronously if invoked in-page, and
asynchronously if the traversal affects another page.
That's very interesting.
For simple cases, Firefox consistently does the Location change
synchronously. Opera (10.x on Windows), Safari (4 for Windows), and Chrome
do it async. But complicated cases make these descriptions simplistic.
http://www.hixie.ch/tests/adhoc/dom/level0/history/sync-vs-async/
IE however appears to implement history.back() asynchronously in all
cases just like newer versions of WebKit.
That doesn't appear to be completely accurate.
I was only testing the cross frame case. Thank you for testing more
thoroughly.
From a web compat perspective, it seems wise to match the behavior of
IE. It also has other benefits.
Can we change the spec?
Yes, but that won't make it async if the goal is to match IE.
On Thu, 21 Jan 2010, Jonas Sicking wrote:
Sounds good to me. Having all navigation be asynchronous I suspect would
have implementations benefits in Gecko too.
It would be a reasonably minor change to the spec. I'm happy to go either
way on this. The problem is I don't know exactly what async vs sync
really means in this context, since the algorithms are quite complicated.
On Thu, 21 Jan 2010, Olli Pettay wrote:
And still one thing to test and specify;
if history.back()/forward() is asynchronous,
does that mean that loading start asynchronously,
or that entries are added asynchronously to session history?
What should happen if a page calls:
history.back();
history.forward();
What if the page calls:
history.back();
history.go(-2);
Indeed. There are the kinds of questions I am curious about.
Another is what should happen if a page goes back() past its fragment
identifier entries, and then modifies the document or alerts the location?
What location should it get? Which document should it mutate? (test 007)
How about:
location.hash = 'a';
/* spin event loop */
history.back();
location.hash = 'b';
history.forward();
alert(location.hash);
/* spin event loop */
alert(location.hash);
It would be nice if the navigation and history traversal algorithms did not
proceed while the page is blocked on a modal alert.
What does this alert? (test 008)
How about:
location.hash = 'x';
location.hash = 'a';
/* spin event loop */
history.back();
/* spin event loop */
history.forward();
location.hash = 'b';
/* spin event loop */
history.back();
/* spin event loop */
alert(location.hash);
What does this alert? (test 010)
And btw, some of the session history handling is anyway synchronous. Per
the current HTML5 draft calling document.open() adds a new entry to
session history immediately (IIRC, webkit is the only one which doesn't
support this).
Another example is navigating to a fragment identifier, which in all
browsers I tested changes the Location object immediately also.
As I see it these are the criteria that we have to consider here in making
a decision, in order of importance:
* Compatibility.
It seems that browsers are quite inconsistent here, and so it's likely
that we have some room to maneuver. Nobody has mentioned any
particular bugs in sites caused by implementing this one way or
another. I am not convinced that compatibility is a factor at this
point.
* Consistency for authors
I think whatever solution we come up with we should make sure it is
sane for authors. In this case, however, pretty much any model works,
so this doesn't really help decide what is best, so long as we are
consistent in how we specify and implement it.
* Implementation concerns
This may be the deciding factor, in particular due to the multiprocess
session history issues Darin raised.
* Specification sanity
I think we can probably make any model work
Re: [whatwg] Web-sockets + Web-workers to produce a P2P website or application
On Fri, 22 Jan 2010, Andrew de Andrade wrote: I'm wondering if anyone from either webkit, mozilla, opera, the W3C or IETF can chime in here and shed light on what the correct process would be to present this idea for consideration either as a standard (W3C or IETF) or for browser adoption as open code (Webkit, Mozilla, Opera, etc.) I can't speak for the W3C or IETF, but for the WHATWG, the process is described in the FAQ: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Authoring feedback on datalist
On Thu, Jan 21, 2010 at 10:12 PM, Maciej Stachowiak m...@apple.com wrote: I haven't reviewed that proposal closely, but I would expect input type=text list=... on Mac to use the standard Mac combobox control: Likewise on Windows it should show the standard combobox instead of what is pictured there. I would expect input type=search list=... to not show any extra buttons, but simply use the list much the way search suggestions work in the Safari built-in search field. That works for me. It doesn't cover the case where you want to take over suggestions for something other than search, but I don't know of anyone doing that. Then again, I didn't even know what a combobox was until this week, so I'm probably not the best to ask about that. :) It's not clear to me that suggest=... is needed. Well, a simple JS API would be useful independent of UI issues. It's a pain to have to create a datalist, make up an arbitrary id for it, associate it with the input, and loop through your list to add option children. I'd expect to be able to do that in one line, if search suggest is a major intended use case here.
Re: [whatwg] HTML5 cut/copy
Two more questions about implementation details: Cut/copy: Does it make sense to fire a drag event at all? The spec says that drag events should be fired at the source node every 350ms (presumably to allow the source node to cancel a drag after it started), but a cut/copy takes place instantaneously. If drag events should be fired during cut/copy, should the clipboard be restored to its original state if the drag event is cancelled? It would make sense, but might make implementations more complicated. Paste: It seems like there is no time a dragleave event would ever fire. A paste essentially goes through the drag and drop loop once; the only possible transition is for the current target element to go from null to non-null. Daniel On Tue, Jan 12, 2010 at 5:38 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 12 Jan 2010, Daniel Cheng wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#copy-to-clipboard The current spec says that drop events should be fired while handling copy/cut operations. Is this intended? The clipboard is not a DOM element; it seems like it'd make sense only to fire the drop event for pastes. Oops. Fixed. It should have been dragstart, drag, and dragend. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 cut/copy
On Jan 22, 2010, at 1:38 PM, Daniel Cheng wrote: Two more questions about implementation details: Cut/copy: Does it make sense to fire a drag event at all? The spec says that drag events should be fired at the source node every 350ms (presumably to allow the source node to cancel a drag after it started), but a cut/copy takes place instantaneously. If drag events should be fired during cut/copy, should the clipboard be restored to its original state if the drag event is cancelled? It would make sense, but might make implementations more complicated. Paste: It seems like there is no time a dragleave event would ever fire. A paste essentially goes through the drag and drop loop once; the only possible transition is for the current target element to go from null to non-null. I don't think it makes sense to have cut/copy/paste use drag events. 1) Browsers already have specific events for cut/copy/paste - those three plus beforepaste are used in content, including in major sites, so they must be implemented for Web compatibility regardless of anything else. It seems unwise for HTML5 to document a brand new untested way to do events for cut/copy/paste, but not document the existing way that is needed for Web compatibility. Thus, even if cut/copy/paste operations continue to fire the drag events, the pre-existing events should be documented. 2) In native UI, it is not always the case that drag-and-drop is possible whenever cut/copy/paste is. For example, in Preview on Mac OS X, if you select a rectangular piece of an image, you can cut or copy it, but you can't drag it. 3) In native UI, even when cut/copy/paste and drag are both possible, they do not always have the same effect. For example, it's common that in reorderable lists you can drag to reorder, but on the Mac at least they rarely allow reordering via cut/copy/paste. Instead there are specific key bindings for reordering (often including up or down arrows with modifiers). Drag and drop also has positional information that is lacking for cut/copy/paste. When dragging files in a file manager's icon view, you can drop the icon at the exact position of your choice, but cut/copy/paste often inserts in a position based on the current arrangement. This requires an actual distinction between operations. 4) In native UI, it is not always the case that cut/copy/paste is possible whenever drag-and-drop is. For example, bookmarks in Safari's Bookmarks Bar can be dragged to reorder, but cannot be cut and pasted. The keyboard-accessible interface for reordering the bookmarks bar is via the bookmarks manager. 5) The drag and drop event sequence is way too complicated to use for the simple case of customizing copy/paste behavior. Many of its fiddly details are simply not applicable. Filed as http://www.w3.org/Bugs/Public/show_bug.cgi?id=8800. Regards, Maciej Daniel On Tue, Jan 12, 2010 at 5:38 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 12 Jan 2010, Daniel Cheng wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#copy-to-clipboard The current spec says that drop events should be fired while handling copy/cut operations. Is this intended? The clipboard is not a DOM element; it seems like it'd make sense only to fire the drop event for pastes. Oops. Fixed. It should have been dragstart, drag, and dragend. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
