Re: [FileAPI] createObjectURL isReusable proposal

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> 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.

Rob
-- 
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]

Received on Tuesday, 27 March 2012 09:43:38 UTC