- From: <bugzilla@jessica.w3.org>
- Date: Fri, 08 Oct 2010 00:33:08 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10712 Tab Atkins Jr. <jackalmage@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jackalmage@gmail.com --- Comment #6 from Tab Atkins Jr. <jackalmage@gmail.com> 2010-10-08 00:33:07 UTC --- I agree with Gez that it's useful to be able to identify the elements that can accept a drop. This can help assistive technologies, but it can also help authors make it easy for users to figure out D&D, by highlighting the valid dropzones with some style. I don't quite like several of the suggestions in the responses, though. Here's my suggestion: Per the current spec, whenever you start a dragevent and add data, the first argument to setData() is a datatype, used in the drop handler to help discriminate between types of data to see if the element wants to accept the drop. Items from outside the web page, or selections of text, come with their own default types when dragged as well, for the same purpose. We can use this. Add a new global attribute, @dropzone. @dropzone accepts a space-separated list of strings, representing datatypes that the element will accept. Whenever the user begins dragging something, the page will find all the elements with a @dropzone specifying the datatype of the thing being dragged, and give them a pseudoclass of :dropzone. This pseudoclass can then be used for various things. An author can use it to style dropzones specially to help the user figure out where to drop. An accessibility tool can use it in querySelectorAll() to find all the dropzones, and report this to the user. This does not affect the operation of dragging in general - all the same events get sent in the exact same way regardless of whether or not there are any matching @dropzones. This just helps the author and other tools tell the user where drops are allowed. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Friday, 8 October 2010 00:33:10 UTC