What does that mean? Isn't it the <img> that gets rendered?

Please be specific about the changes you want...

Yes, but when you drag the image you want the <picture> and <source>s to come along as well.

change:

[[
Otherwise, the element's draggable content attribute has the state auto. If the element is an img element, an object element that represents an image, or an a element with an href content attribute, the draggable IDL attribute must return true; otherwise, the draggable IDL attribute must return false.
]]

to

[[
Otherwise, the element's draggable content attribute has the state auto. If the element is an img element that does not have a picture parent element, a picture element, an object element that represents an image, or an a element with an href content attribute, the draggable IDL attribute must return true; otherwise, the draggable IDL attribute must return false.
]]

Uh, that won't do anything useful. Nothing will end up in the drag data store, for example. You sure that's what you want?

Hmm, nope! Let's see.

[[
setDragImage
]]

This seems fine without changes.

[[
If the list of dragged nodes is not empty, then extract the microdata from those nodes into a JSON form, and add one item to the drag data store item list, with its properties set as follows:
...
If the node is an img element with a src attribute
Add to urls the result of resolving the element's src content attribute relative to the element.
]]

Is this intentionally using <img src> as opposed to the last selected source? In either case, I want to tweak this for <picture> so that it uses the first <img> child's src or currentSrc (I think the latter is probably more useful).

[[
drag data store bitmap
]]

This should be populated with the <picture> element's first <img> child's image data, but I don't really follow where the spec does this for <img> right now.

If we're just trying to make it possible to drag a bitmap out of the page, why isn't it ok to just rely on the user dragging the actual rendered <img> element? I don't really understand what problem we're fixing here.

(That algorithm ignoring srcset="" was just an oversight, I agree that we should use the rendered image's URL and data if there is one.)

That would be OK if you're dragging to a different application or so, but I think it's bad if you want to move elements around within the page and just appendChild the dragged element in the dropzone. That would leave the <picture> behind, which results in an invalid document and breaks the association between the <img> and the <picture>.

I would also like to be able to drag <picture> around within contenteditable. I'm not sure if changing the drag and drop API also changes behavior for contenteditable though, I don't know if and where dragging in contenteditable is defined.

The DND API doesn't support the dragging of an element being mediated by author script.

For contentEditable it works only because the UA is mediating it and it includes secret stuff in the dataTransfer object to represent the element itself.

(This is exactly the kind of nonsense that multielement designs lead to, by the way. I'm really unhappy that you're leaking details all over the rest of the spec.)

You're right. This is probably more trouble than it solves. I've reverted the change in the picture spec. It's reasonably easy for authors to check the parent of the dragged element.

Let's just fix which URL is exposed. You can use "the img element's _current request_'s _current URL_" for that.

Will do.

Simon, we cannot change this as that would expose a URL that would otherwise be hidden. Any other ideas?

No, this wouldn't expose redirects.

https://github.com/whatwg/html/issues/4493