

The HTML5 drag and drop disaster - robin_reala
http://www.quirksmode.org/blog/archives/2009/09/the_html5_drag.html

======
pilif
one of the gripes about the specification was the fact that you had to turn
off default behaviour of some events.

While I agree that this might sound strange at first, if the default behaviour
was to allow drag per default, how exactly would you select content in a
webpage?

There needs to be some kind of toggle to enable or disable the beginning of a
dragging operation. While there is this attribute in Mozilla (and a CSS style
in Safari), right now, the formalized way to enable dragging is to disable the
default operation (which is starting the text selection process).

I don't think this is such a problem.

Maybe I'll come back later and comment on other parts of this rant.

~~~
daleharvey
it seems sensible that "text selection" is default behaviour which is
overridden when you add a drag event, as opposed to having to manually disable
things.

I wish the text selection tools were more powerful in css/js as well, its
reasonably problematic to make text unselectable.

~~~
pilif
that was _exactly_ my point.

If these events had "permit the drag & drop operation" as their default
action, selecting text would be impossible.

~~~
daleharvey
thats a different point, being able to drag something (currently disabling
text select events) doesnt mean text isnt selectable, if you drag over and
entire page the text is still selected. its especially annoying if you have to
support shift + arrow keyboard shortcuts.

~~~
pilif
if the default action of these drag & drop events was to enable drag & drop,
then you would not be able to select anything on the page (using the mouse
that is), because, wherever you push the button down and move the mouse, you
will initiate a drag operation and not a select operation.

This is why drag & drop is disabled by default and the method in which it is
disabled is by making the events fire but have their default action to not
allow drag & drop which then leads to the selection action being used.

~~~
wvenable
Isn't this solved by the "draggable" attribute? Why work at the events-level
at all for this.

~~~
pilif
from an architecture standpoint, the solution using events is actually
cleaner: Instead of having a flag that toggles some events default action, you
have override the event default action where you need it changed.

If you need the attribute (or even a class="draggable" to achieve your goal
without changing the standard), you can use libraries like jQuery.

What I'm saying is:

* I disagree with the author of the articles assumption that the default event action is wrongly set. If it was the other way around, selection of page elements would not be possible.

* The events is what we have in the standard. I would probably prefer the flag aswell, but from a architecture standpoint, using the events is probably much easier to implement.

* If I want to have that attribute, I can easily add it to my sites script code using one or two lines of jQuery-code.

------
tolmasky
I'm glad I'm not the only one ripping my hair out over this.

I wouldn't expect much to be done about this however. Of the concerns I listed
in my blog post, I chose the absolute most conservative one, which could be
added in a completely backwards compatible way such that no existing browser
implementation would break, and I was basically told to wait for HTML 6.

For the curious: [http://www.mail-
archive.com/whatwg@lists.whatwg.org/msg18003...](http://www.mail-
archive.com/whatwg@lists.whatwg.org/msg18003.html)

Here's lookin at 2015.

~~~
peoplerock
It sounds like W3C has been listening to usability critics about as
sympathetically as MS did with IE6. [pops antidepressants]

------
spoondan
The HTML5 Working Group needs to reassess their rationale for choosing this
API. The justification remains that this API originated with IE and is already
implemented in both IE and Safari. Yet, between missing features and rampant
bugs, the extant implementations are nowhere near the specified behavior.
While specifying the correct behavior can help vendors fix their bugs, it's
unclear why any vendor should invest their time and money into an API that is
this complex, that no one likes, and that is missing required functionality.

In general, I think the HTML5 Working Group needs to be more aware of how
standardization of deficient solutions can hurt the web. In this case, many
people were blissfully ignorant of IE's awful drag and drop implementation
until HTML5 threw a spotlight on it. It seems to me that the Working Group,
then, has significantly raised the chances of this horrible API becoming
further ingrained, rather than merely allowing it to die in deserved
obscurity.

------
StrawberryFrog
that looks like it's modelled on how drag and drop works in desktop windows
apps. Which is not a straightforward as it can be, but the "opt-in" nature of
drag-drop is, I think, important. Even more so in a browser where the Ui is
mostly selectable text and graphics anyway.I'm quite happy to have to specify
that an element is dragable, and that elements can't be dragged otherwise.

It also makes sense that when you drag it over a potential target, that target
gets to decide if you can drop that particular item or not. At least, that's
what I'm used to. What's the alternative - having to turn off dropping on all
other elements that might not want it?

~~~
boucher
The point here is that the current API is basically a double negative.

Rather than saying "I want to be a drag source" and "I want to be a drop
target" you are saying "I don't want to not be a drag source" and "I don't
want to not be a drop target".

It's bad design.

~~~
StrawberryFrog
Negative flags are almost always a bad choice for a name. I'd rather see

if (obj.IsFoo) { ... }

than

if (! obj.IsNotFoo) { ... }

Still, changing a name is minor as far as design goes.

------
makecheck
I guess I'm surprised that so much hand-holding is required. Ideally, web
pages don't even have to _think_ about mouse events (which would also pave the
way for concepts like assisted-devices that let drags be achieved without a
mouse).

I suppose my ideal setup would be to have most events handled _entirely_ by
the web browser. The page then only has to define the corner cases of
interest, namely:

\- A single JavaScript event for drags, to retrieve the promised data.

\- A single JavaScript event for drops, where one of the arguments is the
specific type of data (pulled from the property of the source).

\- A _single_ element property to indicate that the entire element is
draggable. This property's value is a "type" (perhaps based on Apple's UTIs,
e.g. "public.jpeg" or "public.xml") to indicate what kind of data is
represented, e.g. <div id="abc" dragtypes="public.xml" ondrag="...">...</div>.

\- An element property to indicate that the entire element _accepts_ drops of
one or more types, e.g. <div id="foo" droptypes="public.jpeg public.png"
ondrop="...">...</div>.

\- New CSS classes, similar to :hover, to define presentation for the drag-
and-drop cases, such as ":drag-source", ":drop-pending" and ":drop-
disallowed". This allows elements to _automatically_ change appearance,
without any JavaScript at all, as drags occur.

Not having implemented a web browser, I don't understand all the nuances, but
I'm not sure why it can't be as simple as the above. I know that the above is
what I would _want_ to have.

------
dchest
Poorly written article with lots of F words.

~~~
jhancock
This one threw me: "couldn’t be arsed to specify"

That's an entirely new way of using arse for me, not that as an American, I
ever use it much, but...

~~~
StrawberryFrog
It's more common in British English. Substitute "bothered" or "bothered to get
off my arse" for "arsed".

------
pbhjpbhj
I'm pretty much of the opinion that anything PPK says about web development is
likely to be of importance.

I like _"This is a strange inconsistency, especially since the spec is
supposed to be based on the IE implementation."_

That kinda explains why it's counter-logical then, it's based on some voodoo
from IE6 (!).

Thankfully when PPK works it all out he usually makes some lovely examples up
and posts them to quirksmode, press on my friend, press on. [I guess that
should be drag on]

------
mitko
_In fact, it’s so outrageously bad that I’ve gone on strike. I refuse to do
any more research on drag and drop. Go do it yourself. Or don’t bother.
Whatever. I don’t care._

Well, writing such an article shows he does care. Also, a good rule of thumb
is: if you are not proposing something better you do not have the right to
criticize!

~~~
olavk
It is probably not that difficult to propose something better. The problem is
that the current solution is implemented in IE, Mozilla and Webkit. A new
solution, however much better, stands the risk of never being implemented in
IE. And even if it is implemented, it will take years bere it is reliably
supported.

This is the dilemma the HTML5 people have to deal with.

~~~
boucher
I think that is a particularly cowardly approach. 99% of the proposed spec is
not implemented in IE. Has no plans to be implemented in IE even. To say, "Oh,
but we'll look ineffectual if we don't have at least one thing that works in
IE" is to say that you'd much rather appear to be a useful spec than to
actually be a useful spec. Something that sucks this bad has no place being
encouraged.

If the spec had been sane from the start, Firefox and Safari would probably
already implement the sane version.

------
tybris
I'd follow ppk to hell, but it seems he's already there.

------
past
I think Thomas Broyer's comments in the post are a good rebuttal. It's also
important to note that even ppk appears in a comment to consider writing a
more constructive post, after further reflection.

------
onreact-com
I coded my first drag & drop in 1999 using DHTML. It worked on both major
browsers, NS4 and IE5. It's sad to see that 10 years later it still is a
problem to use drag & drop in web development.

~~~
peoplerock
I just hope that when PPK unwinds a bit that he presents the issues he
experienced to appropriate W3C feedback channel... written in a more factual
style. We _really need_ them to hear this.

~~~
halo
Considering how popular PPK's site is and that the first person to reply is
Hixie, the author of the HTML5 spec, I think they'll already know his feelings
by now ;)

------
tweksteen
The author seems to be pissed off but nowadays web developers are more
focusing on compatibility than on real design or user interface ...

