- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 14 Aug 2012 11:04:58 -0700
- To: Ryosuke Niwa <rniwa@webkit.org>
- Cc: whatwg@lists.whatwg.org, "www-style@w3.org" <www-style@w3.org>, fantasai <fantasai.lists@inkedblade.net>
On Mon, Aug 13, 2012 at 11:55 PM, Ryosuke Niwa <rniwa@webkit.org> wrote: > On Mon, Aug 13, 2012 at 9:19 PM, fantasai <fantasai.lists@inkedblade.net>wrote: >> 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? We have to (a) only trigger these pseudo-classes while a drag is happening, and (b) trigger the valid/invalid distinction based on what type was declared in JS or assumed by OS-level data for the dragged thing. 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. ~TJ
Received on Tuesday, 14 August 2012 18:05:53 UTC