Add a mechanism to opt-in/opt-out editing features

[rniwa]

There should be a mechanism to allow/disallow a set of editing features.

For example, iPad keyboard has bold, italic, and underline buttons and they should be disabled on a code editor that doesn't support such styling.

However, in the case of contenteditable=true mail client, for example. we may want to opt-out of certain features such as copy/paste instead of opt'ing into support a subset of features.

It seems that we need both an opt-in list as well as an opt-out list as far as we discussed in TPAC. We may even want to add a new HTMLElement subclass to expose these two lists to avoid polluting the HTMLElement interface.

[gked]

I could hear few parts of conversation in the meeting and wanted to clarify few things.
My understanding of the current model is that mentioned IPad floating UI with editing commands actually belongs the system.
The way it is done (may vary from browser to browser) is that browser platform sends a notification to whoever is listening to its events that specific editing command is enabled in a specific context. Then it is the job of the browser app(or whatever else that wants to display editing options) to either display or not those editing commands as a part of context menu or a floating UI.
I am not entirely clear on how this applies to JS editors?
Could you please clarify?

--grisha

[hallvors]

I'm glad to discover you have plans to do this. In the clipboard API we had a (mis)feature inherited from IE, intended to let the script tell the browser that commands copy, cut and paste were enabled at times when the browser would otherwise not consider them enabled. That spec should rely on whatever you develop here instead.

One strawman I have been throwing around is

document.setCommandEnabledState('copy', true);
// or 
document.setCommandState('copy', 'enabled'); // or 'disabled', 'auto', maybe even 'indeterminate'

and I sort of like this. With a document.enumerateCommands() that returns all commands known to document.execCommand in this browser, it would be trivial to disable all but a few whitelisted ones..

[johanneswilm]

@hallvors Your proposal wouldn't work if one has several editors within the same browser window, right? Not that that is a super common usecase, but in a form that may not be completely impossible. of course one could switch everything every time the user changes focus, but that seems like a pain.

[johanneswilm]

@rniwa @rniwa: I actually came up with a usecase where it would not be enough to just set these for the entire page: Say I have a main editor and a footnote editor. Footnotes cannot quite contain the same styling as the main content. So I need to be able to edit these per editing context.

How about we say we start out with browser determined defaults in terms of what is enabled and what is disabled. This should take of the case where editor developers don;t care what is enabled and just want the browser to manage it all.

We can then have both opt in and out and a keyword "all" that enables or disables everything. Something like:

let el = document.getElementById('editor')
let editor = el.getEditor()

editor.disableCommands(['all']) // disables everything
editor.enableCommands(['copy','paste','cut','bold','underline']) // reenables the given array of commands
editor.checkCommands(['enlarge']) // True if the browser's UI supports a command with the name "enlarge"

[johanneswilm]

IS being looked at in #141