User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 This will enable remote XUL applications to have spell checking capabilities without having to run the browser chrome and the user having to install an extention Reproducible: Always
We will need to stabilize (freeze) the spellchecking API in order for me to consider it for the toolkit, but I would be excited to do so.
i personally don't like the current spellchecker api's. So i won't be too happy to see them being frozen. But making me like the interfaces would require a lot of rewriting, and i don't know if my ideas of the api are what editor wants. And i currently don't have time to look into it.
Then we should ask someone what editor wants...
Which spell check API are we talking about? nsIEditorSpellCheck.idl nsIInlineSpellChecker.idl mozISpell*.idl How big is this? What languages will be included/excluded? Please also package a spellcheck icon. :-)
Ok, i was a bit confused. The mozISpell* api's look fine. They take a word, and spellcheck it. Just like it is supposed to do. It is the nsIEditorSpellcheck that i'm not too happy with. Maybe just because it lacks documentation :) Or that spellcheck is split between editor and extension/spellcheck, where the latter implements interfaces defined in editor.
Michiel van Leeuwen (comment 5)--in nsIEditorSpellCheck.idl, there are CheckCurrentWord and CheckCurrentWordNoSuggest which seem to be what you are looking for (disclaimer: I've never used any of these apis); is your objection that you need an editor to initialize the spellchecker? I think any of the APIs I mentioned earlier will need some cleanup before they can be frozen. Yonatan Goraly--as reporter of this bug, can you clarify which (how much?) spellcheck components you intend?
As a toolkit API driver, I have several related goals: 1) get a simple frozen interface for spellchecking individual words, which is fully language/locale aware. This part has no UI and would be usable by non-XUL embedders (i.e. Camino) 2) Specify and freeze core support for spellchecking DOM trees and subtrees, such as is done by mailnews, NVU, etc. This part would also have no UI and would be usable by embedders. 3) Add a basic common XUL spellchecking UI that can be hooked up to part 2) and used by XUL applications with xulrunner. The code for parts 1) and 2) should live in editor/ (vacate extensions/spellcheck) and part 3) should live either in editor/ or toolkit/ Does this plan make sense? I'm happy to make this bug a tracking bug, or file additional bugs about parts 2) and 3). I would like to target parts 1) and 2) at the 1.9 timeframe, and part 3) at the 1.10 timeframe (although 1.9 would be fine).
Ability to spell check is essential for any business application, makes it easier for users to adopt. For the application developer, adding spell check capabilities should be transparent. Ideally, any text edit element, such as textbox, would have a spellcheck attribute, when the value is "on" the wrong words would be marked (with a red line or any other visual cue), and contextual menu could be used to select alternatives. A less desirable method would be to invoke a spell check component with the text as a parameter programmatically. These capabilities should be available both for plain text elements and for HTML documents in design mode. Regarding the backend spell API, I think the spell checker should accept complete sentences or paragraphs, to enable correction of typos that span more than one word, such as double and.
there are bugs for in line spellchecking and stuff, they'll be fixed eventually, hopefully they'll be fixed for toolkit.
Benjamin Smedberg (comment 7) -- I agree with part 1 but I do think that api should accept more than individual words as yonatan goraly points out at the end of comment 8. Ideally the API could handle thesaurus-like functionality too (but I'm not advocating an overhaul for that). I also agree with your 2nd and 3rd parts. I am fine with vacating extensions/spellcheck. I don't necessarily agree that the spellcheck components should live in the editor though. If someone wants to spellcheck something that isn't in an editor, they should be able to, right? Maybe I need to look more at the existing APIs. The timeframe is fine with me but it really depends on who is agreeing to do this work. I haven't seen anyone volunteer to work on any of the 3 parts yet.
For reference. Here are a few open semi random spell checker bugs which might be of interest. Some of them deal with a "new" API as well: bug 129704, bug 16409, and bug 119232.
Note bug 302050, which is adding front-end hooks for this to toolkit's textbox binding.