Consider implementing http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#the-dropzone-attribute.
FWIW, WebKit has webkitdropzone that matches the latest spec.
Yes, we should implement it after reviewing the spec, and get the spec possibly fixed.
(Last time I read the spec, it was still bad.)
Can you specify "bad".
This is the W3C doc: http://dev.w3.org/html5/spec/dnd.html#the-dropzone-attribute
Olli - can you say more about what the issues with the spec are?
(Use whatwg spec for implementation http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#the-dropzone-attribute)
Hmm, it was long ago when I was looking at this.
It is that the API is kind of packed into one attribute, and there is no easy
way to change just certain parts of the attribute value. Sure it is DOMSettableTokenList, but
one needs to iterate through all the values to change them.
Also, it is [PutForwards=value] readonly attribute DOMSettableTokenList dropzone; and
PutForwards is always quite horrible API.
But in general, whenever implementing something from a spec you'll find bugs in the spec.
I basically think that PutForwards is generally always a bad API which should be restricted to legacy behavior.
The spec generally seemed like a good approach. But I haven't reviewed any details.
Olli: What do you mean by that you have to iterate through all attributes of a DOMSettableTokenList. The API was designed specifically so that you can add/remove/flip values without having to do that.
I mean it is too hard to know which all string: or file: types are supported.
One needs to either check each thinkable value with
dropzone.contains("file:" + type)
or iterate the list and cut file: and string: values from the actual values.
It is use of string: and file: prefixes which makes the API somewhat ugly.
(In reply to Olli Pettay [:smaug] from comment #8)
> I mean it is too hard to know which all string: or file: types are supported.
> One needs to either check each thinkable value with
> dropzone.contains("file:" + type)
> or iterate the list and cut file: and string: values from the actual values.
> It is use of string: and file: prefixes which makes the API somewhat ugly.
I don't think the spec will change much on that regard. So either, it should be implemented as specced, or you may want to propose a better solution on the WHATWG mailing list.