Should the API be (at least initially) read-only?

[bsittler]

If we don't allow writes we side-step a bunch of the issues around not being able to use the results from the read API in the write API due to cookie name per se being an insufficient key

[annevk]

I like this plan. It seems better to start out small. Also, if you want client-side state, there's a ton of storage APIs already.

[bsittler]

I may still revisit this proposal, but for now I've gone ahead and proposed a full read/write/monitor API; see the description in the explainer for details and please file issues as you find them (pull requests happily accepted too!)

Rationale: it's harder to make usability improvements to the cookies API (for instance, around default path, predictable character encoding, write-time enforcement of __Host- and __Secure- cookie prefixes, and promise-rejection for feature/capability detection) without a full read/write API.

Any and all feedback and opinions are certainly welcome! There's also an open pull request to make further changes to the explainer and I also intend to start another soon to bring the polyfill in line with the current proposal.

[bsittler]

Read/write is explained and polyfilled now, many of the problems that lead me to open this issue are instead addressed head-on by proposing to support only a sensible subset of cookie behavior and using saner-than-Set-Cookie defaults. Re-open if you still feel read-only is the right starting point (and please explain why!)