Comments (15)
I think providing enough information for editors to take care of autocorrection makes sense. I just hope that we can come up with a single API that works for both IME and autocorrection so that editors don't have to deal with each case separately.
from editing.
Investigating a bit, I am now less sure. The spell checking offered by most popular browsers today is rather primitive because it doesn't take context into account and when a word is more than two letters off, no good suggestions are offered at all.
Additionally, the spell checking is automatically disabled when the right lick menu is overridden and when the text editor is just a little bit more complex than the most primitive possible, it's also impossible to use.
Also, the spell checker language has to be switched by the user and the web editor programmer has no influence on it.
All in all it seems like an ultra broken concept. I am not sure what the security issues for the browser developers are, except that on Mac OS X the spell checker seems for some browsers to be the system spell checker which have had custom words added and I guess some users would add their most secret passwords into their spell checker(?) Somehow it seems this just won't be resolved. The various proposals made that "just let the browser handle it" or "tell the browser about extra dictionary terms" seem rather unrealistic if we are talking about more than just a very primitive editor with no custom controls.
However, what are the alternatives?
There is server side spell checking (Aspell/Pspell based), the way some CKeditor and TinyMCE plugins offer it. There are also some commercial subscription services for grammar checking such as grammarly. All of these will be rather unacceptable for all projects wanting to offer either A) an offline solution or B) don't want to create a lot of server traffic to provide a function that the users computer really has built-in already.
There are also at least two open source client side solutions: http://code.google.com/p/bjspell/ (not updated since 2009) and https://github.com/cfinke/Typo.js/ (still being hacked on). Both are based on Hunspell. These should provide exactly what editor developers will want. The downside is that the end user needs to download dictionary files (700kb-2MB for western European languages) when visiting a site, and at the same time they will likely have bunch of dictionaries bundled with their OS or browser already. The good thing is that download costs go down and will continue to go down, so with time this issue will be of less importance.
Taking all this together, I would suggest to either completely disable spell checking or add it in the least possible invasive way. Text nodes suddenly changing outside of the control of the editor seem like rather invasive, but it's a lot better than random DOM structures changing, empty text nodes disappearing or text nodes being randomly split or merged. The most important part is that the spell checking can be turned off (as it can today).
from editing.
I think we can provide a way for editors to specify where & when spellchecking can be performed so that the apps could provide enough context. However, providing the list of potential correction candidates won't be acceptable in terms of privacy and security.
It appears to me that we need a generic "Replace" device-independent event that gets used for spellchecking & IME.
from editing.
I agree with that Ryosuke. A replace event could require that the site ensure that the selection is completely contained inside a single text node in order to have a default action. It could then handle IME, spellchecking, and maybe overtype.
from editing.
That's a good point! We could even throw some error if the selection is anchored across non-text nodes inside the default event action.
from editing.
@rniwa : Just out of curiosity, could you explain what those security issues are? I mean I get that if using the right word to correct, the js program may be able to find out that the user has added a specific word to his custom dictionary. Is this the security concern? And could it not be handled like access to camera and other devices?
Such an event as you describe is better than nothing, but still I think the usefulness of this kind of spell checking for the kind of editors that can make use of contenteditable=typing over contenteditable=true, will be very limited.
from editing.
The problem is that the user could reveal sensitive information such as the full name, physical mailing address, etc... And unfortunately, most user wouldn't understand the implication of such a security warning dialog/sheet. It's a fundamentally broken security model.
I will strongly object to any API that provides the list of possible correction candidates.
from editing.
I don't think this task force is working on spellchecking, so let's be careful not to get off topic here. We should decide only if browser spellchecking should be available in ce=typing or not. If so we can also decide how to enable it.
from editing.
@BenjamP : Yes, but understanding what the security is is fundamental to understanding why this cannot be added in some other way. If it could be enabled to javascript in general, then it would be a strong argument for not making spellchecking available in ce=typing at all.
from editing.
Ok, that's fair. I don't think we want to take a dependency on that though.
from editing.
@BenjamP : I think you will have a much easier time convincing editor developers that the browser needs to take care of spell checking, once it has been properly explained why this is a security concern for the browser.
from editing.
@rniwa They would add their full name to the dictionary?
Ok, so I guess if a user somewhere in the app gives his name as "Benjamin H." then the app could use the spell checker to check for everything from "Hansen" to "Huntsville" and if one of those doesn't give an error when it usually would (given the browser), then there is a certain likelihood that the person's name is "Benjamin H..." . Is that the concern?
from editing.
It's a security concern for the user because names (including first/last name only), places, etc are likely to be personally identifiable. If a user wants to type them, that's fine. But a browser shouldn't just give access to them.
from editing.
@BenjamP : Ok, and it is your experience that user will add these to their dictionaries and there is no way to exclude the personalized part of the dictionary when offering spell checking? If this is the case and users tend to add passwords and credit card numbers, etc. to their personal dictionaries, then I do understand your guys'es concern and I don't think any editor project will request of you guys to give them access to the spell checker.
If the idea is that ce=typing is to replace ce=true entirely eventually, then adding it the way you suggested makes most sense. Just make sure that the disabling of spell checking and auto correcting is simple and consistent.
from editing.
I am not sure I understand the security concern, but lets just accept this as something only implementers understand.
I take it that everyone agrees that the site needs to be able to enable/disable auto correct and spell checking, whereas language selection of auto correct and spell checking is something only the user controls, correct?
Are the attributes autocomplete
, autocorrect
, autocapitalize
and spellcheck
enough? And it is OK to only have this for text nodes inside the elements with those attributes and an event that is triggered when one of those four has taken place and the contents of a text node have changed?
from editing.
Related Issues (20)
- [EditContext] Issues for May 11 meeting HOT 1
- TPAC 2023 participation - Call for topics HOT 1
- TPAC 2023 participation
- TPAC 2023 participation
- Define behavior of pressing enter in inline editing host HOT 12
- [charter] execCommand spec should be in scope HOT 19
- CfC to include execCommand to list of possible deliverables HOT 1
- RFC: Contenteditable "indent"/"outdent" implementations are not aligned with popular editors HOT 9
- TPAC 2023 agenda HOT 2
- [Delayed Clipboard Rendering] Privacy issue while reading data for web custom types HOT 25
- Outdent behavior with respect to list items is not aligned with popular editors
- Outdent immediately after indent should restore pre-indent DOM (like popular editors do)
- Linked privacy security doc is for older pickling proposal? HOT 1
- RFC: What is expected when a root editable element's contents are completely removed via execCommand
- Support navigator.clipboard inside of Service Workers HOT 9
- Delayed clipboard rendering TAG feedback HOT 3
- Upstream changes from trusted types HOT 1
- TPAC 2024 participation HOT 1
- normative spec changes do not always end up as issues filed with browsers HOT 8
- [execCommand] 9.22 The 'insertText' command action step 5. incorrectly states (U+00A0) as a newline character
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from editing.