Re: [csswg-drafts] [css-selectors] Add pseudo for active/valid file drop targets (#9205)

Hi @argyleink,

I **love** and share your desire to make drag and drop in browsers easier to work with for engineers. I think there is _so much_ that can and should be done to make the browser powered drag and drop easier for engineers to work with.

#### Initial thoughts on this proposal

- In your particular use case, you are working with a single leaf node element (a `<input type="file" />`), with a single drop target style, and in that case, the `:drop-target` selector is convienant
- In my experience, adding styling to elements (ie drop targets) is one of the _small_ challenges of working with the native drag and drop implementation, and you are generally able to achieve styling in a fairly straightforward and flexible way (you did it in a few lines of code)
- There is often a seperation between _logical_ drop targets (eg an element that can be dropped on which results in a paricular outcome), and _actual_ drop targets (the absolute inner most element that is being dragged over and has had  `"dragenter"` and `"dragover"` events cancelled). A _logical_ drop target might be a card, where as the _actual_ drop target might be a `<span>` inside the card.
- You may have multiple levels of logical "drop targets". For example: you are dragging over a card (a logical drop target), which is inside a column (a logical drop target)
- Given that "drop targets" are commonly not leaf elements, you would _need_ `:has()` to be widely accepted for `:drop-target` to be functional for any logical "drop target" that is not a leaf node
- Commonly the _actual_ drop target according to the browser, is not what you are using to determine logical drop targets ([example: stickiness](https://youtu.be/5SQkOyzZLHM?t=2126)). Given this is a fairly common pattern, `:drop-target` in those cases would be incorrect and misleading
- Often you want to do different styling to a (logical or actual) drop target dynamically. The appearance of your drop target might change based on a whole range of factors, such as: the entity is being dragged, where a user is over a drop target, authorization and permissions (eg you might want to display a red drop target saying that the user cannot drop here), how long they have been over the drop target, etc. These decisions can change during a drag as `async` calls are completed, or new data is recieved from the server. For these cases, you will _need_ to be doing your own styling on the `:drop-target` (eg toggling class names) anyway.
- Sometimes we need to cancel _all_ `"dragenter"` and `"dragover"` events (eg to prevent browser cancel animations when we are disabling native drag previews) and we rely on inspecting the events to activate logical drop targets (or no drop targets)

For simple use cases, `:drop-target` could be helpful. However, for medium to complex cases I don't see `:drop-target` being helpful, and it could actually be confusing and unhelpful

-- 
GitHub Notification of comment by alexreardon
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9205#issuecomment-1685177059 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 20 August 2023 05:01:42 UTC