JFYI - the explainer has just been updated mainly on following points:

• The goal of the proposal
• The reason for not having Lang tag
• The reason to choose ObservableArray type.

Please take another look when you have time. Many thanks!

Thanks for this proposal. We agree a Spell Check Dictionary API is potentially interesting and look forward to seeing it develop. Here are questions, thoughts, and notes that we had (satisfied with concerns):

1. Can you verify (and document in the explainer) that this proposed API is implementable on top of most common platforms' spellchecking APIs? We found the APIs for macOS and iOS, where it appears to work, but we haven't checked Windows, Android, or Linux. If not, it would be good to explain if that's unnecessary.

   i. We see that Chrome, for example, offers "Enhanced Spell Check", which does the checking server-side, perhaps with an LLM. Does that sort of system need this API, and if so, can it effectively take advantage of the API? ii. We also noticed that the Mac and iOS APIs distinguish "ignored" from "learned" words. Which of those would be most useful for web users, or do users need both in different situations?

2. The question came up of whether you need a more sophisticated structure than simple strings, in order to handle internationalization. However, since the Apple APIs wouldn't support such a thing, we're not suggesting it. However, it's with considering that dictionaries on devices are not just collections of words (there are rules, like pluralization, and other things that come into play).

3. We're concerned about the use of an observable array. We agree with Domenic, in what you've linked, that it is important to not add new fake array types; however, we believe that the other part of his comment is as key and perhaps this shouldn't really be exposed as an array at all. It might be better only to keep the explicit function calls to add and remove words, perhaps with just variadic .addWords(...) and .removeWords(...). Since all of the spell check-related things are carefully designed to not be observable, it might be good to not have additional methods to see inside. Also, note that this could be achieved with the addition and removal of a <link> element which would allow it to be declarative, potentially preloaded, etc. When looking at how things are implemented on different OSs, consider how the dictionary words would cross IPC boundaries and how they end up in front of user's via some UI. Imagine how abuse case of rapidly add/removing words could potentially impact the user experience and what to do about that, for instance.

4. How will this API interact with the proposed built-in AI APIs like Proofreader and Summarizer? In particular, if a developer adds a word using this API, it's reasonable to expect Proofreader to accept that word. Context support webmachinelearning/translation-api#9 might be related.

5. Can you be more precise about how this API will affect/interact with popular browser extensions? (e.g., Grammarly)

6. There's some DoS risk if pages can inject an arbitrarily long list of words into the spell checker. Make sure the spec allows the browser to reject overly long lists. There's also a risk that if the word list can be read, then sites might allow an untrusted part of the page to write words (since they're "just words"), and then incorrectly interpolate the words into HTML without sanitizing them. Does making the list unreadable (.addWords() & .removeWords() with go .getWords()) reduce this risk? It's worth considering the impact and tradeoffs of multiple approaches.

7. We would love to see more on the alternative solutions that you considered and the reasons that you decided on this particular design. Try to come up with 3-5. Even if they are bad/silly, that's ok... it's just to give the proposal more strength and for you to work through the various pros and cons.