- From: Philip Rogers via GitHub <sysbot+gh@w3.org>
- Date: Tue, 09 Feb 2021 19:05:06 +0000
- To: public-css-archive@w3.org
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.
--
GitHub Notification of comment by progers
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1703#issuecomment-776169588 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 9 February 2021 19:05:08 UTC