The HTML5 drag and drop disaster

http://www.quirksmode.org/blog/archives/2009/09/the_html5_drag.html

by robin_reala • 17 years ago

90 38 17 years ago

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.

peoplerock2• 17 years ago

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• 17 years ago

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 ;)

dchest2• 17 years ago

Poorly written article with lots of F words.

ilyak• 17 years ago

Any comments on -ing content?

dchest2• 17 years ago

Not that I'm afraid of F words or anything, I just can't see the point of the rant (except that HTML5 drag and drop is a disaster) through "[...]" "-ing" pieces.

I'd be happy to read an article (or a comment here on HN) on this topic that points out the issues in a more readable manner. Any pointers?

robin_reala• 17 years ago

To be fair to ppk he’s not usually so wound up. I think the state of the subject matter has gotten to him.

heyitsnick• 17 years ago

I'm all for some well-placed swear-words, but this article was so hard to read that I had trouble working out exactly what is wrong with the spec.

Still, I can tell the author's pretty pissed off about it.

jpcx01• 17 years ago

With good reason I think. It sort of makes sense to me since I've looked into it previously and been similarly horrified at how dumb it worked. I can't see any sane person using this trash over existing js components.

jhancock• 17 years ago

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...

unalone• 17 years ago

Couldn't be arsed is an old expression.

StrawberryFrog3• 17 years ago

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

masklinn• 17 years ago

It wasn't an article but a rant. That was even specified in the introduction:

> What follows is a rant laced with profanity. No apologies. Drag and drop deserves no better.

tlrobinson• 17 years ago

Either way, when PPK is this pissed you should probably pay attention.

tolmasky2• 17 years ago

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...

Here's lookin at 2015.

peoplerock2• 17 years ago

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

pilif4• 17 years ago

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.

daleharvey2• 17 years ago

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.

pilif4• 17 years ago

that was exactly my point.

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

gamache• 17 years ago

The gripe is not that default behavior exists. The gripe is that, once you have made an element draggable, you need to override a few seemingly-unrelated default behaviors in order to implement the most obvious form of drag-and-drop. Or, more precisely: you need to turn off not one, but two "drag" defaults in order to react to "drop" events.

tolmasky2• 17 years ago

If only it were that easy. As it turns out, default behavior is sometimes to drag (as when you have already selected text). In my experiments this business of preventing default became quite frustrating, as sometimes you want to stop drags but not selection, or vice versa, but end up stopping both.

The correct way to do this is to allow the programmer to start a drag. As it stands, it is impossible to do things such as only allow vertical drags and not horizontal drags since the API is completely declarative and takes place on an element-by-element basis.

StrawberryFrog3• 17 years ago

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?

boucher3• 17 years ago

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.

StrawberryFrog3• 17 years ago

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.

tweksteen• 17 years ago

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

mitko• 17 years ago

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• 17 years ago

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.

boucher3• 17 years ago

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.

past• 17 years ago

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.

pbhjpbhj• 17 years ago

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]

tybris• 17 years ago

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

makecheck• 17 years ago

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.

spoondan• 17 years ago

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.

The HTML5 drag and drop disaster

Related Stories