<div>What are the use cases for wanting to store data beyond strings (and what can be serialized into strings) in LocalStorage? I can't think of any that outweigh the negatives:</div><div><br></div><div>1) From previous threads, I think it's fair to say that we can all agreed that LocalStorage is a regrettable API (mainly due to its synchronous nature). If so, it seems that making it more powerful and thus more attractive to developers is just asking for trouble. After all, the more people use it, the more lock contention there'll be, and the more browser UI jank users will be sure to experience. This will also be worse because it'll be easier for developers to store large objects in LoaclStorage.</div>
<div><br></div><div>2) As far as I can tell, there's no where else in the spec where you have to serialize structured clone(able) data to disk. Given that LocalStorage is supposed to throw an exception if any ImageData is contained and since File and FileData objects are legal, it seems as though making LocalStorage handle structured clone data has a fairly high cost to implementors. Not to mention that disallowing ImageData in only this one case is not intuitive.</div>
<div><br></div><div>I think allowing structured clone(able) data in LocalStorage is a big mistake. Enough so that, if SessionStorage and LocalStorage can't diverge on this issue, it'd be worth taking the power away from SessionStorage.</div>
<div><br></div><div>J</div>