- 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