Sangwhan, thanks very much for the feedback. The offline discussions were helpful!
The explainer has been updated at - https://github.com/Igalia/explainers/tree/main/spell-check-custom-dictionary Link for the design doc - https://docs.google.com/document/d/1ND1a1Z4i6kXMHqMwEyRkHSj5VVTWgX5Ya0aNLgVQYGw/edit?tab=t.0#heading=h.kmfizh6cwyy4 Ziran On Saturday, 22 November 2025 at 03:44:38 UTC Sangwhan Moon wrote: > Hello, > > It occurred to me that document-local terminology likely would have to be > conveyed to the browser in two different places with this proposal and Web > Speech's Contextual Biasing - > https://github.com/WebAudio/web-speech-api/blob/main/explainers/contextual-biasing.md > > The end result is different (this proposal being for suppression, > Contextual Biasing for boosting) but I would imagine the input likely > heavily overlaps (e.g. given your Pokemon usecase) - it seems like an > architectural consideration for interop between these two mechanisms would > be beneficial for developer ergonomics. > > Sangwhan > > On Nov 21, 2025, at 1:43, Ziran Sun <[email protected]> wrote: > > > > Hi, > > Thanks very much for the review comments and discussions. They were very > helpful! > > We have updated the explainer and added a brief design note to address the > per-document question. > > Link for the explainer - > https://github.com/Igalia/explainers/tree/main/document-local-dictionary > Link for the design doc - > https://docs.google.com/document/d/1ND1a1Z4i6kXMHqMwEyRkHSj5VVTWgX5Ya0aNLgVQYGw/edit?tab=t.0#heading=h.kmfizh6cwyy4 > > @Rick, @Daniel, please let us have your thoughts about this. > > Any further comments would be much appreciated! > > Thanks, > > Ziran > On Friday, 26 September 2025 at 14:41:17 UTC+1 Ziran Sun wrote: > >> Hi Rick, Daniel, >> >> I'm looking at the case of a non-persistent and document-local dictionary >> that stores the word list in memory. Is it Okay to illustrate a bit more on >> why Blink>DOM might not be the right component for this? And what are the >> issues you could foresee on ensuring the data is reliably per-document? >> >> Thank you! >> >> Ziran >> >> On Tuesday, 22 July 2025 at 22:02:41 UTC+1 Rick Byers wrote: >> >>> On Tue, Jul 22, 2025 at 3:18 PM Stephen Chenney <[email protected]> >>> wrote: >>> >>>> Regarding motivation, our client has financial data, such as >>>> stock symbols and company names. There are similar use cases for medical >>>> data, fan fiction, or anything else with words that might not appear in >>>> hunspell's dictionaries. It's conceivable that the Google internal >>>> spelling >>>> APIs have these words but clients may be very reluctant to send their >>>> strings to Google. >>>> >>>> The proposal in this intent is relatively straightforward to implement >>>> and privacy and security is relatively simple to assess. But for >>>> developers >>>> there will probably be significant load time costs around it, to fetch the >>>> site's dictionary and process it to add the words. >>>> >>> >>> I'd love to see some figures on this. Maybe a bulk add API would be >>> enough? As a quick example I picked a random website (bloomberg.com) >>> and found it downloaded 3.4MB compressed including a number of individual >>> scripts, images and JSON blobs which were around 100kB compressed each. In >>> contrast the entire american-english dictionary on my linux machine >>> compresses down to 270kB. So as long as we're talking about something >>> that's less than 10% the size of the whole american english dictionary, my >>> hunch is that the transfer cost will be insignificant and lost in the >>> noise. But still an http approach to at least enable caching would be a >>> good idea with little downside. I could imagine, for example, a <link >>> rel=dictionary> tag or something that would be even simpler than this JS >>> API approach? >>> >>> Anyway this is just random thoughts to try to nudge away from premature >>> optimization, not API owner input or anything :-). >>> >>> We have some ideas around that in future work but nothing concrete. I >>>> think we'll have to address it before we ship. >>>> >>>> A HTTP header approach would make the ergonomics easier (assuming the >>>> infrastructure for setting up a spelling server is reasonably standard) >>>> and >>>> fits better into the existing code, But ti would not work offline. Maybe >>>> the approaches are complementary and we do both. >>>> >>>> I'll try to get some idea on the size of typical dictionaries in this >>>> space. It is important to know, >>>> >>>> Cheers, >>>> Stephen. >>>> >>>> On Tue, Jul 22, 2025 at 12:03 PM Rick Byers <[email protected]> >>>> wrote: >>>> >>>>> Spelling server seems a lot harder to get right to me, obviously more >>>>> to worry about regarding privacy etc. Can you share anything more about >>>>> the >>>>> motivating use cases here? Like how large do these custom dictionaries >>>>> tend >>>>> to be? I'd guess that for even dictionaries up to 1MB compressed it's >>>>> probably faster and simpler to just have the client download the whole >>>>> thing. RTT latency is generally a bigger performance problem these days >>>>> than raw throughput. But if it's important to solve scenarios with really >>>>> large dictionaries then maybe it's worth exploring? >>>>> >>>>> On Tue, Jul 22, 2025 at 11:11 AM Stephen Chenney <[email protected]> >>>>> wrote: >>>>> >>>>>> Thanks for the early feedback, and sorry for the lack of clarity on >>>>>> the explainer. We're working on improving the explainer to address the >>>>>> issues raised here and issues raised on github. >>>>>> >>>>>> We're also considering an entirely different approach whereby a site >>>>>> provides a "spelling server" URL in the HTML header. That would operate >>>>>> more like the existing "send it to Google" spell checking options. We're >>>>>> super early in designing such a thing, but if anyone has early feedback >>>>>> on >>>>>> that approach we would be interested. >>>>>> >>>>>> Cheers, >>>>>> Stephen. >>>>>> >>>>>> On Tue, Jul 22, 2025 at 10:54 AM Rick Byers <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> FWIW I was also a little confused reading the explainer, but I think >>>>>>> I understand the overall design and I think it's a good one: these >>>>>>> dictionaries are transient and document-local, simply a mechanism to >>>>>>> let >>>>>>> pages selectively suppress spell check violations on their own page. >>>>>>> >>>>>>> Presumably discussion of network fetches in the explainer are just >>>>>>> about the app fetching from it's server (not fetches in the browser), >>>>>>> and >>>>>>> all the discussions of "persistent" storage are under the "future work" >>>>>>> section so it's fine to me that there's no detail here (it's out of >>>>>>> scope >>>>>>> because it's hard). I'm not sure whether it would make sense to extend >>>>>>> this >>>>>>> design into persistent storage or not, but I'm also not sure it matters >>>>>>> (as >>>>>>> the explainer says it's simply an optimization - a problem that may or >>>>>>> may >>>>>>> not exist in practice so not worth worrying about today). >>>>>>> >>>>>>> Ensuring the data is reliably per-document is definitely a key >>>>>>> implementation concern, so I agree with you there Daniel. And yes we'll >>>>>>> eventually want signals from other browser vendors, but our process >>>>>>> <https://www.chromium.org/blink/launching-features/> has that step >>>>>>> only after prototyping is complete (often we learn a lot about the >>>>>>> design >>>>>>> from prototyping), so it's premature to ask for it now at I2P phase. >>>>>>> >>>>>>> Cheers, >>>>>>> Rick >>>>>>> >>>>>>> On Tue, Jul 22, 2025 at 7:37 AM 'Daniel Vogelheim' via blink-dev < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> This intent came up in security review, and I'm mostly confused: >>>>>>>> >>>>>>>> - The explainer mostly seems to assume that these are stored >>>>>>>> in-memory, per-document. But it also talks about absence of >>>>>>>> cross-origin-requests; only to add info about CORS, which only makes >>>>>>>> sense >>>>>>>> for cross-origin requests. >>>>>>>> - There are multiple references to loading data, but there is no >>>>>>>> explanation about what kind of network requests are being made when or >>>>>>>> where. >>>>>>>> - The explainer suggests "Persistently store data" as an >>>>>>>> optimization for having to re-load large dictionaries. Again, no >>>>>>>> information about which requests are being optimized away. >>>>>>>> - In "Data Storage" it is pointed out that CustomDictionaryEngine >>>>>>>> exists per renderer process. While renderer processes mostly don't >>>>>>>> have >>>>>>>> cross-origin data, they sometimes do. And they may hold multiple >>>>>>>> documents. >>>>>>>> This seems inconsistent with information being stored per-document. >>>>>>>> >>>>>>>> Non-security feedback: >>>>>>>> - Since this is a web-exposed API, I'd have expected some attempt >>>>>>>> at checking with other browser engines on support. >>>>>>>> - I do not understand the "High-level Architecture". It seems to >>>>>>>> feature a stack of methods that feeds into yes/no decisions which >>>>>>>> feeds >>>>>>>> into a storage thing. I have no idea what this is meant to convey. >>>>>>>> - Blink>DOM might not be the right component for this. >>>>>>>> >>>>>>>> >>>>>>>> Could you please update the documentation to be more clear about >>>>>>>> where data is stored, and about which network requests are being made? >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jul 18, 2025 at 12:08 PM Chromestatus < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Contact emails [email protected] >>>>>>>>> >>>>>>>>> Explainer >>>>>>>>> https://github.com/Igalia/explainers/tree/main/dictionary-api >>>>>>>>> >>>>>>>>> Specification None >>>>>>>>> >>>>>>>>> Design docs >>>>>>>>> >>>>>>>>> https://github.com/Igalia/explainers/tree/main/dictionary-api#-proposal >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> >>>>>>>>> The proposed APIs enable users to modify the document local >>>>>>>>> dictionary in the browser. Users can add, remove, and check words in >>>>>>>>> the >>>>>>>>> document local dictionary. This feature ensures the browser does not >>>>>>>>> mark >>>>>>>>> words in the document local dictionary as spelling errors. >>>>>>>>> >>>>>>>>> >>>>>>>>> Blink component Blink>DOM >>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EDOM%22> >>>>>>>>> >>>>>>>>> >>>>>>>>> Motivation >>>>>>>>> >>>>>>>>> Some words need to be added to the document custom dictionary so >>>>>>>>> that the browser does not mark them as spelling errors. The added >>>>>>>>> words >>>>>>>>> need to be removed at some point if they aren't necessary. Current >>>>>>>>> specs >>>>>>>>> such as element.spellcheck attribute and ::spelling-error CSS >>>>>>>>> pseudo-element manage the words already in the dictionary. Therefore, >>>>>>>>> the >>>>>>>>> new API would be needed to manipulate the document local dictionary. >>>>>>>>> >>>>>>>>> >>>>>>>>> Initial public proposal None >>>>>>>>> >>>>>>>>> TAG review None >>>>>>>>> >>>>>>>>> TAG review status Pending >>>>>>>>> >>>>>>>>> Risks >>>>>>>>> >>>>>>>>> >>>>>>>>> Interoperability and Compatibility >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> >>>>>>>>> *Gecko*: No signal >>>>>>>>> >>>>>>>>> *WebKit*: No signal >>>>>>>>> >>>>>>>>> *Web developers*: No signals >>>>>>>>> >>>>>>>>> *Other signals*: >>>>>>>>> >>>>>>>>> WebView application risks >>>>>>>>> >>>>>>>>> Does this intent deprecate or change behavior of existing APIs, >>>>>>>>> such that it has potentially high risk for Android WebView-based >>>>>>>>> applications? >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> >>>>>>>>> Debuggability >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> >>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>> ? Yes >>>>>>>>> >>>>>>>>> third_party/blink/web_tests/wpt_internal/dom/local-dictionary/* >>>>>>>>> There is WIP patch which includes the tests >>>>>>>>> >>>>>>>>> >>>>>>>>> Flag name on about://flags None >>>>>>>>> >>>>>>>>> Finch feature name None >>>>>>>>> >>>>>>>>> Non-finch justification None >>>>>>>>> >>>>>>>>> Requires code in //chrome? False >>>>>>>>> >>>>>>>>> Tracking bug https://issues.chromium.org/issues/428005649 >>>>>>>>> >>>>>>>>> Estimated milestones >>>>>>>>> >>>>>>>>> No milestones specified >>>>>>>>> >>>>>>>>> >>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>> https://chromestatus.com/feature/6185007701557248?gate=4503614776934400 >>>>>>>>> >>>>>>>>> >>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>> <https://chromestatus.com>. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "blink-dev" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to [email protected]. >>>>>>>>> To view this discussion visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/687a1d04.170a0220.2dad83.0168.GAE%40google.com >>>>>>>>> >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/687a1d04.170a0220.2dad83.0168.GAE%40google.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "blink-dev" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> To view this discussion visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPPzd95-XN%2BjWHLmvwjLg3wv6WjZWYvP52T6Rp%3DjEg_EVw%40mail.gmail.com >>>>>>>> >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPPzd95-XN%2BjWHLmvwjLg3wv6WjZWYvP52T6Rp%3DjEg_EVw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4781c320-5a06-42f1-ae8c-aba939aa7cddn%40chromium.org > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4781c320-5a06-42f1-ae8c-aba939aa7cddn%40chromium.org?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e6c67da8-9f54-4fab-a6ee-9ab84845b528n%40chromium.org.
