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