W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2010

[whatwg] Drag-and-drop feedback

From: Daniel Cheng <dcheng@google.com>
Date: Thu, 4 Feb 2010 18:24:05 -0800
Message-ID: <cdc844f71002041824n1eb32eb4p811d88ee363071bc@mail.gmail.com>
On Thu, Feb 4, 2010 at 5:28 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 4 Feb 2010, Daniel Cheng wrote:
> > >
> > > Webkit and Firefox are case-sensitive. IE only does "TEXT" and "URL",
> > > but case-insensitively (at least for Text, I didn't test URL). Chrome
> > > is case-insensitive for everything.
> > >
> > > Tough call. I guess we'll go with just converting everything to
> > > lowercase, so that it's case-insensitive.
> > >
> > > BTW I noticed Chrome includes "Text" and "URL" in the .types list.
> > > That's incorrect according to the spec.
> >
> > If event.dataTransfer converts everything to lowercase, that means there
> > are native formats that will always be impossible to access.
>
> The spec requires that the UA lowercase all the native types as well (and
> that they be converted to MIME types).
>
> Could you elaborate on which types would be a problem, and on what
> platforms?
>

Forcing UA to lowercase all formats has a high implementation cost. Most
DataTransfer implementations now can directly interact with the native
system data object, whatever form that takes. With this change, the UA has
to enumerate (with possible string conversions involved, depending on the
platform) and lower case all formats currently in the drag and
drop/clipboard operation with every call to getData()/setData()/clearData().
Furthermore, what happens if there are collisions after lowercasing?

Also, suppose some Windows app XYZ uses the data format "My Awesome
Clipboard Format". If a page wants to set drag and drop (or clipboard data;
presumably, the interfaces to transfer data are going to remain somewhat
similar), it will be unable to set data in the correct format unless the UA
happens to internally map a MIME type to that data format. Some common MIME
types should definitely be mapped to native data formats, but the interface
shouldn't prevent someone from interfacing with any arbitrary app they want.


>
>
> > Since "text" and "url" are already special, maybe case should only be
> > ignored for those two. All other formats, even if they are actually MIME
> > type strings, should be handled in a case-sensitive manner.
>
> In your previous e-mail, you were arguing they should be
> case-insensitive... I think your earlier arguments are more persuasive.
> The MIME type specs do say they're case-insensitive.
>

True, but I think the problems with making all strings lowercase outweigh
the benefits.


>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100204/dce7113a/attachment-0001.htm>
Received on Thursday, 4 February 2010 18:24:05 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:20 UTC