[css-pseudo] Pseudo-element for dragged element

[SebastianZ]

There should be a way to style the "drag image" on a drag and drop action.

While dragging an element, normally a drag image is shown (which can be changed via DataTransfer.setDragImage()). UAs display this element semi-transparently or with a radial gradient and the cursor turns into a "forbidden" icon, but there doesn't seem to be a way to influence this styling.

This seems to be an obvious use case to me and I'm pretty sure this must have been discussed earlier, though I couldn't find a discussion related to this here or on www-style.

So, my suggestion is to add a ::drag-image (name to be bikeshedded) pseudo-element, that allows to change the UA styles of the drag image.

My use case is to allow moving elements within a container and while dragging I'd like to display them opaque.

Example:

::drag-image {
  opacity: 1;
  mask: none;
}

Sebastian

[tabatkins]

I think these drag images are displayed by the operating system. I'm unclear what level of control the browsers have of this.

[SebastianZ]

From my testing, Firefox, Chrome and Edge all differ somewhat in their display of the drag images, so I believe this must be controlled by the browser.

Sebastian

[fantasai]

(tagging a bunch of specs because it's not clear to me what this falls under)

[css-meeting-bot]

The CSS Working Group just discussed [css-pseudo] Pseudo-element for dragged element.

The full IRC log of that discussion

<myles> Topic: [css-pseudo] Pseudo-element for dragged element
<myles> GitHub: https://github.com//issues/1703
<myles> fantasai: Do we want to do this or not? If we do, I can try to spec something up. If we don't care, I will defer the issue, I will defer to a future level of the spec.
<myles> Rossen: Has anyone had a chance to look this over and form an an opinion?
<myles> gregwhitworth: I did. I didn't ask what's in there. I'll go in there and ask. I wanted more concrete use cases. I can guess them, but b/c HTML drag'n'drop exists, i'm trying to figure out what they want beyond that.
<myles> gregwhitworth: I can go on there and ask them.
<myles> gregwhitworth: To answer fantasai's question: I wouldn't spend time on it until I got concrete gaps.
<myles> Rossen: Proposal: gregwhitworth to engage with sebastian, then come back
<myles> chrishtr: I'll check difficulty of implementation
<tantek> +1
<myles> Rossen: perfect. great.

[gregwhitworth]

@SebastianZ can you provide the concrete use case you're wanting to adjust the styles of that image specifically? Because I would expect that to be possible with HTML5 drag and drop with eventing. Is that not possible?

[progers]

There is some precedent in :-webkit-drag which appears supported in chromium and webkit:

<style>
  #mydrag {
    width: 100px;
    height: 100px;
    background: blue;
  }
  #mydrag:-webkit-drag {
    background: red;
  }
</style>
<div id="mydrag" draggable="true"></div>

This is a pseudo class rather than a pseudo element. Would specifying this behavior work for the usecase?

There are some pretty bad interop issues in this area. To generate the drag image, all implementations do a proprietary paint of a subtree. This can be seen in the following example:

<style>
  body {
    background: lightgreen;
  }
  #ancestor {
    width: 150px;
    height: 50px;
    background: lightblue;
    overflow: hidden;
  }
  #draggable {
    width: 100px;
    height: 100px;
    border-radius: 20px;
    background: white;
    color: black;
  }
</style>
<div id="ancestor">
  <div id="draggable" draggable="true">
    <br><br>drag me
  </div>
</div>

Firefox: #draggable excluding ancestor clips.
Chromium: the drag image starts at the nearest stacking context and includes ancestor clips.
Safari: #draggable including ancestor clips.

Maybe ::drag-image could improve this? For example, one interop issue would be fixed if the user-agent style sheet defined the dragged element as creating a stacking context. Resolving whether ancestor effects apply to the drag image seems important for this to be useful.

[SebastianZ]

Concrete use cases for this are dragging the cards from one column into another in a tasks board like Trello, reordering a list of items like the tabs in a browser or a priority or todo list, dragging files from the file system into the UA, etc.

For all those use cases you currently have to suppress the default image provided by the UA for the dragging action and actually move the element itself or a temporary one. This is quite cumbersome and requires a lot of JavaScript code in order to track the mouse position and reposition the element.

I'd expect most such cases could be handled via the suggested pseudo-element. The pseudo-class @progers mentioned has some downsides, though, because the element is still forcibly made semi-transparent by the browser and cannot be changed and because you cannot choose to display some text or other content in it. Therefore I think the best solution would be a pseudo-element.

In order to get a copy of the element an example rule could look like this

::drag-image {
  content: element(#element); /* there might also be a keyword be added to element() that refers to the dragged element */
  display: block;
  width: 100px;
  height: auto;
}

Sebastian

[gregwhitworth]

Concrete use cases for this are dragging the cards from one column into another in a tasks board like Trello, reordering a list of items like the tabs in a browser or a priority or todo list

Are the drag events not sufficient for these to adjust the necessary styles especially since you'll need to handle the dropping logic there too?

dragging files from the file system into the UA, etc.

This one intrigues me and isn't covered by the above API set (that I'm aware of). Wouldn't it make more sense to fill this gap in that API instead? That would then allow necessary styling assuming we ensure to spec that they should be styleable and how. I could then see a discussion around pseudo classes that map to said events and it would work beyond just images. I'm personally not a fan of having the above pseudo-element since it seems like it's primarily targeted at a single usecase and could possibly be filled via a different API that aligns with the same behavior. I wouldn't strongly oppose it though either.

Thanks for circling back on the usecases.

[SebastianZ]

Concrete use cases for this are dragging the cards from one column into another in a tasks board like Trello, reordering a list of items like the tabs in a browser or a priority or todo list

Are the drag events not sufficient for these to adjust the necessary styles especially since you'll need to handle the dropping logic there too?

The last time I tried it myself (about two or three years ago, I think) the drag events didn't provide a proper way to style the dragged element. They only allow to fully style the drop targets via the target property and the related CSSOM APIs.

See the examples here:
https://developer.mozilla.org/en-US/docs/Web/API/Document/dragend_event
https://stackoverflow.com/questions/11169554/how-to-style-dragged-element
https://www.kryogenix.org/code/browser/custom-drag-image.html
https://flaviocopes.com/drag-and-drop/

There is a DataTransfer.setDragImage() method, though it only allows to set an image instead of the element, though it doesn't allow to style that image, and especially no way to get rid of the transparency effect added by UAs.

And this doesn't only apply to dragged elements, also dragging selected text shows a similar effect.

dragging files from the file system into the UA, etc.

This one intrigues me and isn't covered by the above API set (that I'm aware of). Wouldn't it make more sense to fill this gap in that API instead? That would then allow necessary styling assuming we ensure to spec that they should be styleable and how. I could then see a discussion around pseudo classes that map to said events and it would work beyond just images. I'm personally not a fan of having the above pseudo-element since it seems like it's primarily targeted at a single usecase and could possibly be filled via a different API that aligns with the same behavior. I wouldn't strongly oppose it though either.

Yes, dragging files into the UA is a special case, as they come from outside the UA and their dragged image is generally controlled by the OS. I'm not sure to what extent UAs are allowed to influence the style of it.
I'd say, the most important use cases are the ones that are UA internal, though, i.e. dragging DOM elements.

Note that Selectors Level 4 already had pseudo-classes related to drop events, which were dropped (pun intended 😄) in #2257.

While I agree with you that there should be pseudo-classes related to those elements, this issue focuses specifically on the thing that is shown while dragging (and the pseudo-classes for drag source and drop targets be discussed separately). And as of now, this is currently an image, which defaults to a copy of the element being dragged but can be changed to some other image or be hidden. And the element that is dragged actually stays where it is.

While I still think that styling this dragged copy could best be solved via a pseudo-element, there might be another approach by changing the APIs instead. I.e. there could be an option added to control whether you are only dragging a copy of the element or the actual element itself. Then I'd definitely be for a pseudo-class like :dragged that allows to apply styles to the dragged element.

Sebastian

[megangardner]

For Safari, we can control most of the opacity for a drag image, but when they are handed to the system which handles all of our drags, a small amount of opacity is added, even if we generate the image with no alpha. This is the case for Mac and for iOS.

[css-meeting-bot]

The CSS Working Group just discussed Pseudo-element for dragged element, and agreed to the following:

• RESOLVED: closing this issue as defered

The full IRC log of that discussion

<fremy> Topic: Pseudo-element for dragged element
<astearns> github: https://github.com//issues/1703
<emilio> q+
<fremy> fantasai: are we interested in styling elements while they are being dragged?
<astearns> acl emilio
<astearns> ack emilio
<fremy> fantasai: or is this something we don't want to control further
<fremy> emilio: I don't think a pseudo-element isn't that great
<fremy> emilio: because we can only set an image
<fremy> emilio: we could reuse `content`
<fremy> emilio: with only an image allowed but that isn't great
<fremy> iank_: we should also consider the thread model
<fantasai> s/thread/threat
<fremy> fantasai: based on this feedback, should we close this as won't fix
<fremy> astearns: any objection to close a deferred?
<fremy> RESOLVED: closing this issue as defered
<fremy> astearns: it's better to give honest feedback

[SebastianZ]

I am a bit confused - and honestly also a bit dissatisfied - due to the short meeting discussion and quick resolution.

Is this now disregarded because @emilio thinks a pseudo-element is not the right way to solve the use cases? Or is it deferred to a future spec.? It seems that he and formerly @gregwhitworth at least acknowledged that styling dragged elements is worthwhile.

After a previous meeting I was asked to provide use cases which I did. In the same comment I also explained why I believe a pseudo-element is the right approach to this rather than a pseudo-class (like the existing :-webkit-drag mentioned earlier by @progers).

emilio: we could reuse content
emilio: with only an image allowed but that isn't great

Reusing content was the idea, yes. I wouldn't restrict this to images, though, as there are use cases (like dragging a text selection) for the other values supported for it.

iank_: we should also consider the thread model
s/thread/threat

If this means security and privacy issues, then I agree that those need to be considered. Though so far I cannot think of any.

So how can I further help to get this considered?

Sebastian

[astearns]

The impression I got from the discussion is that the OS APIs that browsers pass the drag image to are different, and what could be done with the image would be weirdly limited by those differences. My understanding is that dragging a text selection still requires the browser to generate an image to pass to those APIs. So we would need to fully specify how to convert a subtree with pseudo-element styling applied into an image.There was not any implementer interest on the call to experiment with what could be done given those difficulties.

I think the best path would be to get at least one implementer interested in experimenting in this area, but I unfortunately do not have advice for you on how best to spark that interest.

[mangelozzi]

Related to this topic, like :hover, why not have a :drag pseudo selector for when a DOM/Shadow DOM element is being dragged? Currently one has to add and remove class names, which is pretty much required almost every time one create a drag/drop operation