- From: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
- Date: Tue, 27 Mar 2012 12:06:08 +0200
- To: public-webapps@w3.org
On 27.3.2012 11:43, Robert O'Callahan wrote: > On Tue, Feb 14, 2012 at 5:56 PM, Jonas Sicking <jonas@sicking.cc> wrote: > > On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson <ian@hixie.ch > <mailto:ian@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
Received on Tuesday, 27 March 2012 10:06:36 UTC