[whatwg] [selectors4] drag-and-drop pseudo-classes
rniwa at webkit.org
Tue Aug 14 12:13:09 PDT 2012
On Tue, Aug 14, 2012 at 11:04 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
> On Mon, Aug 13, 2012 at 11:55 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> > On Mon, Aug 13, 2012 at 9:19 PM, fantasai <fantasai.lists at inkedblade.net
> >> The CSSWG discussed drag-and-drop pseudo-classes today. The current
> >> proposal is to have three pseudo-classes:
> >> * One for the element representing the drop target that
> >> would receive the item if it were dropped.
> >> * One for all elements representing possible drop targets
> >> that could receive the item.
> > How do we find these elements? On one hand, if we're only supporting
> > dropzone attribute, then adding new pseudo element seems unnecessary. On
> > the other hand, I can't think of ways to detect whether an element could
> > return false or prevents the default action on dragover/dragenter events
> > without firing those events.
> Just using [dropzone], yes.
> We're not adding a pseudo-element, we're adding pseudo-classes.
> I'm not sure how we can possibly do these without pseudo-classes. Can
> you outline what you think it would be?
I'm asking how we're supposed to implement this pseudo-classes given that
the only way to know whether an element can receive the item is by firing
dragenter and/or dragover events. e.g.
The :valid-drop-target pseudo-class represents an element that is a
possible drop target for an item that is currently being dragged in a
How are we going to figure out whether a given element is a possible drop
target for an item, when the element can dynamically decide whether to
accept the item or not in dragenter/dragover events?
As well, the pseudo that matches "the drop target that will be used if
> you dropped right now" might not be expressible in pure CSS even given
> the above. It's probably equivalent to "when you :hover it", but
> there are applications that basically have this functionality that
> work differently - for example, I think that the built-in Windows
> solitaire game highlight the closest drop target to the current mouse
> pointer, even if you're nowhere near the actual drop zone.
Yeah, and that's not compatible with how drag and drop are implemented on
More information about the whatwg