Thanks for bringing this up, Anssi.

The diff between the REC and the latest Editor’s Draft[1] indicated at least 
two normative changes, so I’d like to propose a second edition of Web Storage. 
What do you say?

Here’s my analysis for the current mutex. All your comments are welcome.

* ED L174, L283
- WEBIDL Updated. The getter of the Storage interface and the key of the 
StorageEvent are Nullable;
- The test suite has been update for these changes[2][3] . These changes are 
widely implemented by the browsers.
- These changes are normative and should be accepted in the second edition.

* ED L187
- The supported property names on a Storage object should be "in the order that 
the keys were last added to the storage area”(added).
- I wrote a test case[4] for this but the implementation doesn’t seem to follow 
this instruction. It’s more likely to be *in the order of keys that was defined 
by the user-agent*.
- Giving the fact this change is non-normative, we should either ignore it or 
update the instruction to be *in the order of keys that was defined by the 

* ED L262
- Remove 4.3.1 (LocalStorage) Security.
- The former section claimed that user agents must throw a SecurityError 
whenever any of the members of a Storage object originally returned by the 
localStorage attribute are accessed by scripts whose effective script origin is 
not the same as the origin of the Document of the Window object on which the 
localStorage attribute was accessed. 
- There was discussion[5] that this section wasn’t clear enough, dating back to 
2012. I couldn’t find any related topics in the mailing list about why the 
editor removed this section after the Rec.
- My test case[6] indicates none of Chrome/Firefox/Safari throws the 
SecurityError in that case.
- This is a normative change and should be accepted in the second edition.

Other changes are more editorial and can be kept in the second edition, imo. 
Moreover, the archives of the Issue section need to be updated in the new 
document because the formal archives are no longer available.

A draft second edition of WebStorage[7](diff[8]) is available in GitHub. Please 
feel free to raise issues or PRs there.

FYI, according to the 2014 process document[9], to modify a Rec, we can either 
go through FPWD->CR->PR->REC, or if we can prove wide review for the changes, 
things will be easier, i.e., CR->PR->REC.



[1] <>
[7] <>
[8] <>
> On 2015-4-30, at 8:02pm, Kostiainen, Anssi <> wrote:
> Hi,
>> On 28 Apr 2015, at 15:46, Arthur Barstow <> wrote:
>> On 4/21/15 5:39 AM, Kostiainen, Anssi wrote:
>>> Hi,
>>> Is there a plan to publish an errata to sync the Web Storage Rec [1] with 
>>> the latest? I counted 8 commits cherry picked into the Editor's Draft since 
>>> Rec [2].
>>> If no errata publication is planned, I'd expect the Rec to clearly indicate 
>>> its status.
>> Re the priority of this issue, is this mostly a "truth and beauty" 
>> process-type request or is this issue actually creating a problem(s)? (If 
>> the later, I would appreciate it, if you would please provide some 
>> additional context.)
> It was creating problems. Our QA was confused which spec was the 
> authoritative one, and wrote tests (additional ones, on top of the w-p-t 
> tests) against the Rec spec. These tests failed since Blink is compliant with 
> the latest, not the Rec. More context at: 
>> The main thing blocking the publication of errata is a commitment from 
>> someone to actually do the work. I also think Ian's automatic push of 
>> commits from the WHATWG version of Web Storage to [2] was stopped a long 
>> time ago so there could be additional changes to be considered, and the 
>> totality of changes could include normative changes. Did you check for these 
>> later changes?
> No, I just observed the ED has evolved since the Rec publication. There may 
> be additional changes in the LS that haven't been picked up to the ED.
>> If you, or anyone else, would like to help with this effort, that would be 
>> great. (If it would be helpful, we could create a new webstorage repo under 
>> github/w3c/, work on the errata in that repo and redirect the CVS-backed 
>> errata document to the new repo.)
> I can ask if our QA would be interested in contributing.
>> Personally, I think putting errata in a separate file - as opposed to 
>> putting changes directly into [1] - is mostly "make work" and fails the 
>> "principle of least surprise". However, I think the consortium's various 
>> processes preclude us from doing what I consider is "the right thing".
> The best way would be to ensure TR reflects what is broadly implemented. If 
> that does not work out due to process reasons, then a visible note at the top 
> pointing to the authoritative spec would be the second best option. That 
> failing, the errata.
> Thanks,
> -Anssi
>>> [1]
>>> [2]

Reply via email to