-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a mechanism to opt-in/opt-out editing features #93
Comments
I could hear few parts of conversation in the meeting and wanted to clarify few things. --grisha |
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
and I sort of like this. With a |
@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. |
@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:
|
IS being looked at in #141 |
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.
The text was updated successfully, but these errors were encountered: