On 27.3.2012 11:43, Robert O'Callahan wrote:
On Tue, Feb 14, 2012 at 5:56 PM, Jonas Sicking <jo...@sicking.cc> wrote:
On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson <i...@hixie.ch
<mailto:i...@hixie.ch>> wrote:
> Anything's possible, but I think the pain here would far
outweigh the
> benefits. There would be some really hard questions to answer,
too (e.g.
> what would innerHTML return? If you copied such an image from a
> contentEditable section and pasted it lower down the same
section, would
> it still have the image?).
We could define that it returns an empty src attribute, which would
break the copy/paste example. That's the same behavior you'd get with
someone revoking the URL upon load anyway.
That's what I want to do when assigning a MediaStream to a media
element's "src" DOM attribute.
https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html
It seems to me to be the least bad option.
Having DOM state that's not reflected in the serialized DOM (or copied
by cloneNode()) is not good, but it's not new either. Form elements,
canvases, and media elements already have similar issues.
Which does not mean, that it does not matter... And the issue is
different here, because all canvases behave the same, all forms behave
the same, but here some images copies would produce actual image
(http://) some would not (blob://).
It would be much better to actually copy the Blob URL in src attribute
and let it be dereferenced (it would either be succesfull or not, but
it's based on programmer's design)
Brona
