[css-selectors] Add pseudo for active/valid file drop targets

[argyleink]

Problem: JavaScript is required to change the style of a file input if you want to show feedback that the input is a valid drop target. Currently, authors must add multiple JS listeners to file type inputs to "do their best" to show the user the UI is expecting the file drop / is a valid drop location. Without this JS, users have to guess / assume / or notice that tiny subtle hover effect (which I never noticed until I watched the below demom video demo which is quite zoomed).

<input 
    type="file" 
    ondragenter="this.classList.add('dropping')" 
    ondragleave="this.classList.remove('dropping')" 
         ondrop="this.classList.remove('dropping')"
>

<style>
input[type=file].dropping {
  /* … */
}
</style>

would become ✨

<input type="file">

<style>
input[type=file]:drop-target {
  /* … */
}
</style>

https://github.com/w3c/csswg-drafts/assets/1134620/a5ff29fc-2aca-4555-901f-ff5a1ab7b175

Link to Codepen

Proposal: :drop-target Remove the JS requirement and expose the state the browser is keeping private.

input[type="file"] {
  /* … */

  &:drop-target {
    outline: 2px dashed Highlight;

    @media (prefers-reduced-motion: no-preference) {
      animation: drop-zone 1.5s ease-out infinite;
    }
  }
}

This selector would activate when the user's drag coordinates are intersecting with the elements bounds, and would deactivate when the user moves the file off of the element. This selector is up for discussion about whether it should work for all inputs/elements, or just the file input.

This could also be combined with :has() so forms and UIs can know if there is a drag event happening on a child element, and it can compliment the state by reducing noise (for example):

fieldset:has(:drop-target) :not(:drop-target) {
  opacity: .5;
}

Resources: https://www.w3.org/TR/selectors-4/

[romainmenke]

This selector would activate when the user's drag coordinates are intersecting with the elements bounds, and would deactivate when the user moves the file off of the element.

Maybe another state is needed to indicate all drop targets on a page when a user is dragging a file around.

If there is some time between seeing a file upload field and finding the file you need to upload, you might have forgotten where the actual file upload is. Highlighting all drop targets when the cursor intersects with the window might also be helpful.

[andrejsharapov]

I once observed the trend that most teach platforms strictly forbid the use of attributes in the html, such as onclick and onfocus, and advised to use js, but the code above breaks this view. 🧐

[tayfunerbilen]

Since :has() not fully ~supported~ by browsers, Instead of input If we can use :drop-target for parent, it would be more effective I guess.

[alexreardon]

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 convenient
• 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). 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). So we can end up with the actual drop target being whatever element the user currently over (usually actual drop targets are only a thing when "dragenter" and "dragover" is cancelled for specific elements). So what would end up happening is that :drop-target would be applied to potentially anything (whatever the innermost element is that the user is dragging over)

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.

---

I am super open to changing my mind on this! These are my initial thoughts 😊