On Thu, Feb 4, 2010 at 5:28 PM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, 4 Feb 2010, Daniel Cheng wrote:<br>
> ><br>
> > Webkit and Firefox are case-sensitive. IE only does "TEXT" and "URL",<br>
> > but case-insensitively (at least for Text, I didn't test URL). Chrome<br>
> > is case-insensitive for everything.<br>
> ><br>
> > Tough call. I guess we'll go with just converting everything to<br>
> > lowercase, so that it's case-insensitive.<br>
> ><br>
> > BTW I noticed Chrome includes "Text" and "URL" in the .types list.<br>
> > That's incorrect according to the spec.<br>
><br>
> If event.dataTransfer converts everything to lowercase, that means there<br>
> are native formats that will always be impossible to access.<br>
<br>
</div>The spec requires that the UA lowercase all the native types as well (and<br>
that they be converted to MIME types).<br>
<br>
Could you elaborate on which types would be a problem, and on what<br>
platforms?<br></blockquote><div><br></div><div>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?</div>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
<br>
> Since "text" and "url" are already special, maybe case should only be<br>
> ignored for those two. All other formats, even if they are actually MIME<br>
> type strings, should be handled in a case-sensitive manner.<br>
<br>
</div>In your previous e-mail, you were arguing they should be<br>
case-insensitive... I think your earlier arguments are more persuasive.<br>
The MIME type specs do say they're case-insensitive.<br></blockquote><div><br></div><div>True, but I think the problems with making all strings lowercase outweigh the benefits.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div></div><div class="h5"><br>
--<br>
Ian Hickson               U+1047E                )\._.,--....,'``.    fL<br>
<a href="http://ln.hixie.ch/" target="_blank">http://ln.hixie.ch/</a>       U+263A                /,   _.. \   _\  ;`._ ,.<br>
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'<br>
</div></div></blockquote></div><br>