This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It would be helpful to have an attribute that identifies drop targets for the drag and drop mechanism in HTML5. This would make it easier for user agents to enumerate possible drop targets for assistive technologies.
Would this attribute's presence essentially change the dragover and dragenter events to always seem canceled? It would be useful to have implementor feedback on this feature. Is this something implementors would be interested in supporting?
Opera is. (Besides a win for accessibility this would be a big win for authors too. They do not really seem to appreciate the way dragover/dragenter work.)
(In reply to comment #0) > It would be helpful to have an attribute that identifies drop targets Yes quite possible. Gez, can you provide some simple markup so I'm clear what you have in mind?
(In reply to comment #1) > Would this attribute's presence essentially change the dragover and dragenter > events to always seem canceled? > > It would be useful to have implementor feedback on this feature. Is this > something implementors would be interested in supporting? In my opinion the presence of this attribute should not cancel the events. It is not important where the events are being caught. It is important to have a mechanism by which user agents can innumerate sections of a document that are intended as drop targets. In order for drag and drop to be made accessible to keyboard only users it is necessary to be able to present users with a list of regions of a document that the author intends as drop targets. It is not necessary for the drop targets to process the events them selves, this can be performed further up the tree. However, without a mechanism to identify which elements are targets for receiving a drop user agents will only be able to innumerate those elements which have drop listeners, which may, in many cases, bear little resemblance to the actual elements that are intended as targets for a drop. @David @droptarget="true" Any element with its droptarget attribute set to true will be innumerated by a user agent as a droppable region for purposes of making drag and drop accessible to keyboard only users.
(In reply to comment #4) > @David > > @droptarget="true" > > Any element with its droptarget attribute set to true will be innumerated by a > user agent as a droppable region for purposes of making drag and drop > accessible to keyboard only users. I'm with you. I'm assuming this is easier than setting @droptargets="id1 id2 id3..." on the node being dragged?
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.
How would the attribute's value distinguish between text types and file types?
(In reply to comment #7) > How would the attribute's value distinguish between text types and file types? Why do you need to do so? Unrelated: Perhaps it would be nice to auto-cancel dragenter and dragover events, or rather just auto-prevent the default action for them (which is to ignore the element and keep dragging), since @dropzone already expresses that you want files of the given type (the only drag item-specific info you get during those events). However, you'd still want some ability to ignore a drag, as you may base the acceptance on other, global information (for example, if the element is supposed to be "disabled"). I'm not sure how you would do this, though - it seems like right now there are only two possibilities - either the event does its default action, which means ignoring the dropzone, or the event is cancelled, which means the dropzone is ready to accept the drop. There's no way to manually trigger the default action, so you can't just change what the default action is, or auto-cancel it. So, shrug.
To make this make sense I think I'm going to drag in the API proposals we've had before, so that this attribute can be defined in terms of that saner model rather than the current patchwork.
(In reply to comment #9) > To make this make sense I think I'm going to drag in the API proposals we've > had before, so that this attribute can be defined in terms of that saner model > rather than the current patchwork. Hard to understand what your intent is from your comment. Can you provide more details? What does "drag in" mean, and which API proposals?
(In reply to comment #10) > (In reply to comment #9) > > To make this make sense I think I'm going to drag in the API proposals we've > > had before, so that this attribute can be defined in terms of that saner model > > rather than the current patchwork. > > Hard to understand what your intent is from your comment. Can you provide more > details? What does "drag in" mean, and which API proposals? I think Ian is referring to a proposed more comprehensive redesign of the drag & drop API. The DnD API has been criticized in the past for being overly arcane and hard to author with, though compatible with what is implemented in Trident and WebKit at least. The existing API is useful for legacy content, but in the long run, it may be desirable to have a cleaner API for new content. As I understand it, Ian suggests that if we enhance DnD to add a way to declare drop targets, we may as well do a more thorough overhaul. I have no strong opinion on the merits of proceeding that way.
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > To make this make sense I think I'm going to drag in the API proposals we've > > > had before, so that this attribute can be defined in terms of that saner model > > > rather than the current patchwork. > > > > Hard to understand what your intent is from your comment. Can you provide more > > details? What does "drag in" mean, and which API proposals? > > I think Ian is referring to a proposed more comprehensive redesign of the drag > & drop API. The DnD API has been criticized in the past for being overly arcane > and hard to author with, though compatible with what is implemented in Trident > and WebKit at least. The existing API is useful for legacy content, but in the > long run, it may be desirable to have a cleaner API for new content. > > As I understand it, Ian suggests that if we enhance DnD to add a way to declare > drop targets, we may as well do a more thorough overhaul. I have no strong > opinion on the merits of proceeding that way. Is it essential to completely re-design drag and drop to incorporate this change? If not, then it's more appropriate to focus on the requested change associated with this bug. Taking drag and drop back to ground zero when the spec is supposed to be in the final stages of refinement is not a good idea. Whatever happens is likely to be rushed. What might be a better idea is to remove drag and drop from HTML5, and into its own spec. We have precedent with other smaller, topic specific specs. Then it won't be as influenced by the aggressive timeline now in effect for HTML5. This also then allows the accessibility community to work with the browser companies and web application developers, to create an approach that all can be comfortable with. Whether people hate it or not, drag and drop _is_ one of the things that has been implemented, at least in some browsers. If you're going to change what's been implemented, you need to make sure that what you put in its place is rock solid; if you don't get it right the second time, the effort is going to lose a lot of credibility. If you do keep it in HTML5, and you do decide to go the revolutionary approach, I strongly suggest you have a good in-depth discussion on this with all the players (web developers, browser makers, accessibility) in the HTML WG email list. The original bug doesn't necessarily encompass this broad a possible change. Just a suggestion.
PS I didn't have problems with the original design of drag and drop. I understood the reasoning that went into the design. I thought the modification Gez has suggested was a good one. I've enjoyed the discussion and the ideas. At the same time, I'm not adverse to a re-design if the original design really is a problem, and adding what's needed for accessibility is going to be too much of a challenge with the original design. Whatever happens, it's going to break what we have. So, let's do it once, and do it right. Not rushed, not haphazard, and with appropriate community input.
Checked in as WHATWG revision r5645. Check-in comment: dropzone 0/4: placeholder http://html5.org/tools/web-apps-tracker?from=5644&to=5645
Checked in as WHATWG revision r5646. Check-in comment: dropzone 1/5: the new model http://html5.org/tools/web-apps-tracker?from=5645&to=5646
(In reply to comment #15) > Checked in as WHATWG revision r5646. > Check-in comment: dropzone 1/5: the new model > http://html5.org/tools/web-apps-tracker?from=5645&to=5646 *frantically waves hand* Hellooooo! Anyone hear me? Seriously, I'm trying to piece together what's happening here. Was the new model discussed in an email list somewhere?
Checked in as WHATWG revision r5647. Check-in comment: dropzone 2/5 and 3/5: Update the spec to use the new DND model. In theory, this makes no normative difference, but I'm sure I made some mistakes... let me know if you spot any. http://html5.org/tools/web-apps-tracker?from=5646&to=5647
Checked in as WHATWG revision r5650. Check-in comment: dropzone 4/5, part 1: DataTransferItems (WIP); also contains some WebIDL terminology fixes. http://html5.org/tools/web-apps-tracker?from=5649&to=5650
(In reply to comment #18) > Checked in as WHATWG revision r5650. > Check-in comment: dropzone 4/5, part 1: DataTransferItems (WIP); also contains > some WebIDL terminology fixes. > http://html5.org/tools/web-apps-tracker?from=5649&to=5650 Rather than do this piecemeal, working the issue through on IRC[1], which is not accessible to those using a screen reader (and I know that someone interested in this bill is using a screen reader), could you please outline your strategy and proposed API on the HTML WG email list? That way all interested parties can participate, which should increase the likelihood of consensus. If someone is a member of the HTML WG, can you please bring this issue to the attention of the HTML WG co-chairs? [1] http://krijnhoetmer.nl/irc-logs/whatwg/20101029#l-39
Checked in as WHATWG revision r5651. Check-in comment: dropzone 4/5, part 2/2: DataTransferItem. http://html5.org/tools/web-apps-tracker?from=5650&to=5651
Checked in as WHATWG revision r5652. Check-in comment: dropzone 4/5, part, um, 3/2: some bits I somehow missed in the previous checkin. Oops. http://html5.org/tools/web-apps-tracker?from=5651&to=5652
Checked in as WHATWG revision r5658. Check-in comment: dropzone 5/5, part 1: skeleton of dropzone='' section; update DND processing model; enumerate where sections that need updating. http://html5.org/tools/web-apps-tracker?from=5657&to=5658
r5659: dropzone 5/5, part 2: flesh out the authoring conformance requirements, ready the skeleton for the UA requirements http://html5.org/tools/web-apps-tracker?from=5658&to=5659 r5660: dropzone 5/5, part 3: flesh out the UA requirements for dropzone=''. http://html5.org/tools/web-apps-tracker?from=5659&to=5660
Checked in as WHATWG revision r5661. Check-in comment: dropzone 5/5, part 4/4: finishing touches for dropzone='': add it to the indexes and IDL; add an example. http://html5.org/tools/web-apps-tracker?from=5660&to=5661
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diffs given above Rationale: Concurred with reporter's comments.
Created attachment 932 [details] mahu menang main poker hihihi.....can give me some 1 item...pliiissss...
(In reply to comment #25) > EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are > satisfied with this response, please change the state of this bug to CLOSED. If > you have additional information and would like the editor to reconsider, please > reopen this bug. If you would like to escalate the issue to the full HTML > Working Group, please add the TrackerRequest keyword to this bug, and suggest > title and text for the tracker issue; or you may create a tracker issue > yourself, if you are able to do so. For more details, see this document: > http://dev.w3.org/html5/decision-policy/decision-policy.html > > Status: Accepted > Change Description: see diffs given above > Rationale: Concurred with reporter's comments. I see the changes in the WhatWG HTML5 document, but not the W3C version yet. When does the change get moved over to the W3C document? Wasn't sure of the re-build timing.
Created attachment 933 [details] only me got give won play game...only me got chips ppl...