Spellcheck on MDN

[jwhi...@mozilla.com]

MDN contains user-generated content written in HTML. Most contributors use CKEditor, the WYSIWYG interface, which allows them to write content without knowing HTML.

CKEditor ships with a plugin for SCAYT [1], which implements “spell check as you type”, giving a similar experience to rich text editing in Word and Google Docs. We’ve made this plugin available on MDN, but there are some concerns with its continued and expanded usage (such as bug 1318827 [2], "Enable spell check by default). These issues are:

* It loads additional JavaScript and resources from a third-party website where we have no direct relationship
* It presents advertisements to those who use the spellcheck feature, which can be disabled with a license [3].

I have only seen advertisements for the licensed SCAYT service. It is possible that other ads may be served in the future.

Due to these concerns, I can't support turning on spell check by default. I also think that we can't continue using SCAYT without resolving this license issue, which would require time and resources that are in short supply.

My recommendation is to disable SCAYT and replace it with browser-based spell check. This may require disabling the integrated context menu as well, which gives CKEditor-specific options when you right-click. I'm looking for feedback on this recommendation, especially from those who are regular users of spell check and / or the context menu. I suspect that very few MDN users use either feature, and switching to browser-based spellcheck would be an improvement for almost everyone.

I've written a Google doc [4] that goes into more technical detail about the issues with SCAYT and the options I considered.

[1] http://ckeditor.com/addon/scayt
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1318827
[3] https://www.webspellchecker.net/signup/licensed-signup.html#wsc-trial
[4] https://docs.google.com/document/d/1189WsFRmoFVGHSXgJyuTOZeL3nvKr3NyBIvI-TZeJ6M

[Eric Shepherd]

Yeah, I figured we’d wind up here. I use the context menu pretty extensively (that’s why I’ve got bugs on file about adding more stuff to it). I’ll get over it eventually, I suppose, but it’s a bummer.

I bet we could do a CKEditor add-on pretty easily that would add the context menu items to the standard HTML menu, generating the appropriate events to activate the corresponding functions when chosen. It could be a WebExtension even, but it shouldn’t be necessary.

> On Mar 1, 2017, at 4:52 PM, jwhi...@mozilla.com wrote:
>
> My recommendation is to disable SCAYT and replace it with browser-based spell check. This may require disabling the integrated context menu as well, which gives CKEditor-specific options when you right-click. I'm looking for feedback on this recommendation, especially from those who are regular users of spell check and / or the context menu. I suspect that very few MDN users use either feature, and switching to browser-based spellcheck would be an improvement for almost everyone.

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: https://www.bitstampede.com/
Twitter: https://twitter.com/sheppy

[Makyen]

Adding to the browser context menu has issues:
* Browser extension: Obviously, we can add to the browser context
menu using a WebExtension (and similar extensions for other browsers).
The primary disadvantage I see is that setting it up such that users
need to install an add-on to get the full functionality of editing MDN
is not usually a good a user experience choice.
* In page HTML: An in-page solution would only be supported by
Firefox, as adding to the browser context menu with <menu> HTML elements
is not supported in other browsers without, at least, the user setting a
flag (e.g. Chrome). I have no idea what percentage of MDN edits are
done with non-Firefox browsers. If the usage of other browsers is
sufficiently low, we could go with this solution.

Either of those solutions for adding the CKEditor entries to the
browser context menu requires a significant expenditure of software
development resources.

Enable browser spellcheck and educate users to access it using
ctrl-right-click:
* You can use browser based spellchecking without disabling the
CKEditor context menu. I use browser based spellcheck whenever I edit
MDN. In Firefox, you can access the browser context menu using
ctrl-right-click, or shift-right-click. I just tested editing MDN with
browser based spellcheck enabled on Chrome. Only ctrl-right-click works
in Chrome . (1)

The things required to implement this are to enable browser
spellcheck in the DOM and educate users to use the Ctrl key with their
right-click. Enabling spellcheck can, obviously, be done server side by
small changes to the HTML. At the moment, I do it client side with a
user script. User education could be done, for example, by having a note
at the top of the page, an unobtrusive note shown when the CKEditor
context menu is used, and/or a note at the bottom of the CKEditor
context menu.

The development cost of this should be minimal to small, depending on
how the information is shown to users. There may be increased CS cost,
but there would be increased CS cost for the various solutions which put
the CKEditor entries into the browser context menu.

Just enabling browser spellcheck (the "spellcheck" attribute set to
"true"), while educating users with text in the page or CKEditor context
menu, looks to me like it might give the best of both worlds (have both
the CKEditor context menu and browser spellcheck), while doing so with
lower cost than implementing a method to get the CKEditor entries into
the browser context menu. Educating users is always a pain, but with
appropriately placed information text (and maybe the ability for the
user to disable spellcheck), I think it might work.

I don't see a truly good option here. None of the available solutions
are perfect.

Makyen

1. I don't use Chrome much, so I'm not familiar with its normal
spellcheck UI in "contenteditable" divs. When briefly testing, I found
that it only spellchecked the paragraph in which I focused, not the
whole MDN page I was editing. I don't know if this is normal, but I
assume it is normal for "contenteditable" portions of the DOM.

> _______________________________________________
> dev-mdc mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-mdc
> MDN contributor guide: http://bit.ly/ContributorGuide

[Eric Shepherd]

That’s an option, but the user-unfriendliness of it is a real setback, which is we’ve not already done that.

I had no idea contextmenu wasn’t more broadly supported. That’s horrifying. :)

I figure if we use it, if people want to use i they’ll make sure to encourage the devs of their favorite browser to get it together.

Otherwise, since we already have jQuery around, we could choose to import the <menu> into jQuery.contextMenu, like this: https://swisnl.github.io/jQuery-contextMenu/demo/html5-import.html <thishttps://swisnl.github.io/jQuery-contextMenu/demo/html5-import.html>. Maybe.

> On Mar 1, 2017, at 7:43 PM, Makyen <wp.m...@gmail.com> wrote:
>
> The things required to implement this are to enable browser spellcheck in the DOM and educate users to use the Ctrl key with their right-click. Enabling spellcheck can, obviously, be done server side by small changes to the HTML. At the moment, I do it client side with a user script. User education could be done, for example, by having a note at the top of the page, an unobtrusive note shown when the CKEditor context menu is used, and/or a note at the bottom of the CKEditor context menu.
>
> The development cost of this should be minimal to small, depending on how the information is shown to users. There may be increased CS cost, but there would be increased CS cost for the various solutions which put the CKEditor entries into the browser context menu.

[Janet Swisher]

Has anything changed as a result of this discussion? I came across a
mention of SCAYT in the meta-docs, and I'm not sure whether to delete
the mention yet.

On 3/1/17 16:52, jwhi...@mozilla.com wrote:
> MDN contains user-generated content written in HTML. Most contributors use CKEditor, the WYSIWYG interface, which allows them to write content without knowing HTML.
>
> CKEditor ships with a plugin for SCAYT [1], which implements “spell check as you type”, giving a similar experience to rich text editing in Word and Google Docs. We’ve made this plugin available on MDN, but there are some concerns with its continued and expanded usage (such as bug 1318827 [2], "Enable spell check by default). These issues are:
>
> * It loads additional JavaScript and resources from a third-party website where we have no direct relationship
> * It presents advertisements to those who use the spellcheck feature, which can be disabled with a license [3].
>
> I have only seen advertisements for the licensed SCAYT service. It is possible that other ads may be served in the future.
>
> Due to these concerns, I can't support turning on spell check by default. I also think that we can't continue using SCAYT without resolving this license issue, which would require time and resources that are in short supply.
>

> My recommendation is to disable SCAYT and replace it with browser-based spell check. This may require disabling the integrated context menu as well, which gives CKEditor-specific options when you right-click. I'm looking for feedback on this recommendation, especially from those who are regular users of spell check and / or the context menu. I suspect that very few MDN users use either feature, and switching to browser-based spellcheck would be an improvement for almost everyone.
>

> I've written a Google doc [4] that goes into more technical detail about the issues with SCAYT and the options I considered.
>
> [1] http://ckeditor.com/addon/scayt
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1318827
> [3] https://www.webspellchecker.net/signup/licensed-signup.html#wsc-trial
> [4] https://docs.google.com/document/d/1189WsFRmoFVGHSXgJyuTOZeL3nvKr3NyBIvI-TZeJ6M

> _______________________________________________
> dev-mdc mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-mdc
> MDN contributor guide: http://bit.ly/ContributorGuide

--

Janet Swisher <mailto:jREMOVE...@mozilla.com>
Mozilla Developer Network <https://developer.mozilla.org>
Community Strategist

[Eric Shepherd]

No, SCAYT remains in place. Some of the improvements to its configuration went live, but after deciding to remove it eventually, we have done nothing further.

I believe we do have consensus about switching to the built-in spell checker, although there’s an issue with the fact that this requires a weird key-click thing to get at the browser’s engine. Ideally we’d figure out how to either make CKEditor use the standard context menu, or add access to the built-in spell checker to the CKEditor context menu widget.

[johnww...@gmail.com]

I can confirm, it hasn't been removed. I don't have a deadline for removal either. It's been in place for years, and it feels like it can remain in the current state (enabled by the user) for a few months more, while we ship other features and work on higher-priority technical debt. If something changes, such as SCAYT publishing ads that go beyond self-promotion, we may have to act quickly, so I'm glad we started the discussion. It may become a blocking issue when we start on other work, such as a strict Content Security Policy.

I've opened bug 1351022 to track the feature change.

John

On Tuesday, March 21, 2017 at 2:53:23 PM UTC-5, Eric Shepherd wrote:
> No, SCAYT remains in place. Some of the improvements to its configuration went live, but after deciding to remove it eventually, we have done nothing further.
>
> I believe we do have consensus about switching to the built-in spell checker, although there’s an issue with the fact that this requires a weird key-click thing to get at the browser’s engine. Ideally we’d figure out how to either make CKEditor use the standard context menu, or add access to the built-in spell checker to the CKEditor context menu widget.
>