The HTML5 drag and drop disaster | Hacker News Reader

The HTML5 drag and drop disaster

quirksmode.org

90 pointsrobin_reala38 comments

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.

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.

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.

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.

that was exactly my point.

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

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.

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.

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

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.

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.

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

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.

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?

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.

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.

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.

Poorly written article with lots of F words.

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

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.

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.

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.

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

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

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

Couldn't be arsed is an old expression.

Any comments on -ing content?

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?

Yeah, Francisco's post is linked at the bottom. But don't mistake this rant for useless. Francisco's thoughtful post was largely ignored. PPK has some pull in the community, and being pissed off may have an impact that rational conversation would not. Note that the HTML 5 editor was the first comment on the post.

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]

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!

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.

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.

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

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.

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.

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.

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

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

Reply on news.ycombinator.com