Add inputTypes for Safari and use 'data' to pass argument

[johanneswilm]

Safari has context menus for more editing operations that have not been covered within inputTypes so far:

• capitalize
• make lowercase
• make uppercase
• substitute (?), used for smart quotes, etc.
• paragraphdirectionright/left (adds style="direction: rtl", so that the visual effect for European languages looks like right-justified, and the period at the end of the sentence moved to the other end of the sentence, but the text remains ltr)

[chong-z]

According to Safari's context menu and font panel, I think we should add following inputTypes:

1. 'insertFromSpellcheck' (for other platforms as well)
2. 'insertFromSubstitution' ('omw'+Enter => 'On my way!')
3. 'upperCase'
4. 'lowerCase'
5. 'capitalize'
6. 'writingDirectionDefault'
7. 'writingDirectionLeftToRight'
8. 'writingDirectionRightToLeft'

As well as actions require a parameter (which should be put into 'data' field):

1. 'fontFamily'
2. 'fontStyle'
3. 'fontSize'
4. 'backColor'
5. 'foreColor'
6. 'hiliteColor'

[johanneswilm]

@choniong Yes, we need to discuss this. The other option is to remove these options from the Safari menus.For a lot of this, JS editor developers may prefer for it to be removed rather than to add the inputTypes.

I didn't add "writing direction" because they don't actually do what they claim to do, at least not in the understanding of lay people. Turning on right-to-left does not suddenly make European script go in the opposite direction. Those of us who understand CSS and some more technical aspects can figure out what is going on there, but we don;t really need richtext editors.

The other menus with colors and fonts I couldn't get to work, and my communication with JS editor developers indicates that they haven't dealt with these menus because the Apple users tend to not know of their presence.

If Apple insists to keep these menus, I would agree to do as you say and add these with the data. But I would still urge Apple to add a way to remove these menus entirely, as many/most/all editors will disable at least parts of the options in these menus.

[johanneswilm]

As for fonts: Is there a way for the JavaScript to specify which fonts can be chosen, or does it simply automatically offer all fonts installed on the system? Or those used on the webpage?

[chong-z]

Yes, we need to discuss this. The other option is to remove these options from the Safari menus.For a lot of this, JS editor developers may prefer for it to be removed rather than to add the inputTypes.

I guess we should do both: 1. Support these features and 2. allow opt-in/opt-out.

I didn't add "writing direction" because they don't actually do what they claim to do, at least not in the understanding of lay people. Turning on right-to-left does not suddenly make European script go in the opposite direction. Those of us who understand CSS and some more technical aspects can figure out what is going on there, but we don;t really need richtext editors.

Well I have no idea how RTL script works... But I guess we should support them as they are modifying DOM.

The other menus with colors and fonts I couldn't get to work, and my communication with JS editor developers indicates that they haven't dealt with these menus because the Apple users tend to not know of their presence.

If Apple insists to keep these menus, I would agree to do as you say and add these with the data. But I would still urge Apple to add a way to remove these menus entirely, as many/most/all editors will disable at least parts of the options in these menus.

Yes it don't work on Safari currently, but Safari has the entry and it works on other macOS native apps. Anyways I think we should provide a way for Safari to make it work, and JS can always disable them through opt-in/opt-out.

[johanneswilm]

@choniong Testing:

Google Docs: The rightclick menu is disabled, and those of the options that are available in the top menu are not working.

Microsoft Office 365: same as Google Docs: The rightclick menu is disabled, and those of the options that are available in the top menu are not working.

CKeditor 5: Right-click menu available, but none of the options work.

CKeditor 4: right-click menu unavailable, some of the other options work. (communication with developers indicate that the working options are working because CKE 4 ignored this user action and contenteditable made the change automatically)

TinyMCE: Same as CKeditor 4.

Prosemirror: Right-click menu visible, some simple options work (capitalize, turn to capital letters). Others have no effect (change fonts, etc.).Edit: changing from ltr to rtl causes a JavaScript error and a breakdown of the collaboration process if connected with other users

QuillJS: At least some of the options in the right-click menu initially seem to work. But when one then tries to combine with UI controls inside the editor, for example the li tool, it quickly breaks down and either the paragraph direction is lost, or the list number is printed underneath the paragraph.

Facebook status update: turn-to-caps works, changing paragraph-direction seems to have no effect. Bold and other styling has somehow been disabled. Font selection is still there, at least one can get one menu into it, but then it doesn't go any further.

[johanneswilm]

Yes, we need to discuss this. The other option is to remove these options from the Safari menus.For a lot of this, JS editor developers may prefer for it to be removed rather than to add the inputTypes.

I guess we should do both: 1. Support these features and 2. allow opt-in/opt-out.

If we can get a opt-in/out mechanism, like the one I suggested or a different one that accomplishes the same goal, that could work. But I should also add that I have received remarks from people working with JS editors questioning the usefulness of having many of these options altogether as they feel that it is much easier for them to add buttons for extra options such as adding emojis, choosing fonts that they really want to be available, adding rtl-buttons, etc. .

But again -- if we can get this opt-out mechanism, I'm ok with that.

I didn't add "writing direction" because they don't actually do what they claim to do, at least not in the understanding of lay people. Turning on right-to-left does not suddenly make European script go in the opposite direction. Those of us who understand CSS and some more technical aspects can figure out what is going on there, but we don't really need richtext editors.

Well I have no idea how RTL script works... But I guess we should support them as they are modifying DOM.

I don't either, and I agree that we need to support those users. But the button as it is seems confusing for users of ltr-scripts. Even I, somewhat technically inclined, would initially expect that the option would turn my English language text into a mirrored version that runs right-to-left. So if these menus really are needed, I think we need to be very careful in the description of these events to explain what they really do.

The other menus with colors and fonts I couldn't get to work, and my communication with JS editor developers indicates that they haven't dealt with these menus because the Apple users tend to not know of their presence.

If Apple insists to keep these menus, I would agree to do as you say and add these with the data. But I would still urge Apple to add a way to remove these menus entirely, as many/most/all editors will disable at least parts of the options in these menus.

Yes it don't work on Safari currently, but Safari has the entry and it works on other macOS native apps. Anyways I think we should provide a way for Safari to make it work, and JS can always disable them through opt-in/opt-out.

Ok, sure. Have we found any editor on the web where all of these work?

[chong-z]

As for fonts: Is there a way for the JavaScript to specify which fonts can be chosen, or does it simply automatically offer all fonts installed on the system? Or those used on the webpage?

Well I'm not sure when/how Safari is gonna implement it though, but I agree we should.

Ok, sure. Have we found any editor on the web where all of these work?

Nope. :p But with 'beforeinput' it should be easier to implement.

[johanneswilm]

@choniong: I now notice that also Chrome has a "writing direction" option in the right-click menu, and also this breaks ProseMirror. Do we have any documentation for how this feature is supposed to work?

Ok, sure. Have we found any editor on the web where all of these work?

Nope. :p But with 'beforeinput' it should be easier to implement.

True. But if the menus aren't working now, and neither Google Docs nor Office 365 have bothered about trying to get at least some of the options to work, maybe that is an indication of users and developers not looking for these features in those menus and therefore not complaining.

[rniwa]

Here's a concrete proposal.

New Input Types

Add the support for "backColor", "createLink", "fontName", and "fontColor" to inputType as new input types.

These new input types respectively sets the background color of text, wrap content with a hyperlink, change the font face, and change the font color when the user expresses an intention to do so (as in execCommand of the same names).

"backColor" and "fontColor" specifies the color of the background and the font face respectively using the CSS color unit in InputEvent.data.

"fontName" specifies a single family name or a single generic family name as used in the CSS font-family property in InputEvent.data.

"createLink" specifies the URL relative to the base URL of the context object's document in InputEvent.data.

New Content Attribute

Add new content attribute supportedinputactions (tentative name; alternatives: allowed actions and supportedactions) and supportedInputActions IDL attribute to the Element interface. (Since this attribute / feature is so close to what IndieUI's uiactions content attribute, we could call it uiactions although that's not necessary the most descriptive name.)

The supportedInputActions attribute’s getter must return a DOMTokenList object whose associated element is the context object and whose associated attribute’s local name issupportedinputactions. The tokens of this particular DOMTokenList object are also known as the element’s supported input actions.

The supported input actions of an element specifies a set of input types for which a beforeinput event and an input event must be fired. UA must not fire any beforeinput or input event with an input type not included in the list of the supported input actions. UA may indicate the capability of the content in its UI.

When the supportedinputactions content attribute is missing, the following default values are used.

• For contenteditable=typing, "insertText, insertFromPaste, insertFromDrop, insertNonText, insertFromYank, undo, redo"
• For contenteditable=true, a space separated list of all input types
• Otherwise, the empty string.

[johanneswilm]

Interesting! Is there a way currently to create a link using browser UI or keyboard shortcuts?

[rniwa]

@johanneswilm : Yes, we have this feature called smart link which automatically linkify URL whenever user types in an URL and then inserts a space / enter. Because this feature is pluggable via extensions, etc..., there could be a third party app e.g. to linkify their app link.

[johanneswilm]

I think this could work, if we can figure out of a way to dynamically enable/disable the undo/redo menu entries so that we don't need to rely on feature enabling/disabling for these.

@rniwa Does this mean that you don't see a need for other new inputTypes for safari at this stage?

[rniwa]

I've omitted things like making letters uppercase and smart quoting because those things can be treated like spellchecking features and user replacing text via input methods. It's better to have a fewer primitives that websites need to support instead of adding dozens of new types.

I think this could work, if we can figure out of a way to dynamically enable/disable the undo/redo menu entries so that we don't need to rely on feature enabling/disabling for these.

I'm not sure about manipulating undo/redo arbitrarily but the idea is to not even insert things into undo stack if an action is not supported so that should work as long as author explicitly specifies the actions they'd like to support. e.g. if bold isn't supported and user tries to bold text, that attempt won't be inserted into the undo stack.

@rniwa Does this mean that you don't see a need for other new inputTypes for safari at this stage?

What I've listed in https://github.com/w3c/input-events/issues/32#issuecomment-248762122 is what's minimally required to support the basic features. There's some bidi related features but I think that could wait for now.

[johanneswilm]

There's some bidi related features but I think that could wait for now.

If you mean the ltr/rtl switch, I noticed that Chrome has that as well, and it seems to break at least one editor and be of little use in other editors that for example only target users using Latin/Cyrillic script. Or at least it would make sense to be able to turn this off for those users who only write languages where such a menu might cause confusion.

So I would think this should should be added as an inputtype, if that means it's also something we can disable.

[ojanvafai]

@rniwa @choniong @garykac @gked @travisleithead https://github.com/w3c/input-events/issues/32#issuecomment-248762122 makes sense to me. Y'all good with that? If so, let's spec and implement?

[johanneswilm]

@ojanvafai: Are you ok with also adding the options that are in the right-click "Writing direction" menu on Chrome and and "Paragraph direction" in safari?

[rniwa]

MSIE has recently removed the support for mutating BlockDirLTR / BlockDirRTL for block directions and InlineDirLTR / InlineDirRTL for inline directions but we could bring them back. Alternatively we can add a new command that takes a direction as an argument. e.g. SetBlockDirection and SetInlineDirection.

[rniwa]

Note that some UA may still insert BDI, LRM, RLM, etc... Unicode control character via insertText to control the direction of text still so there isn't really a way to not support bidirectional text.

[johanneswilm]

@rniwa I don't know enough enough about bidi to know whether they are useful. I am mostly concerned about being able to turn them off for pure English text.

Note that some UA may still insert BDI, LRM, RLM, etc... Unicode control character via insertText to control the direction of text still so there isn't really a way to not support bidirectional text.

OK, but those will be unicode characters that come in through a beforeinput event. That's different than this menu which adds a style-tag to a paragraph, especially if it doesn't emit a beforeinput event for this DOM change. Also, entering those unicode characters wouldn't be something that someone who doesn't anything else than ltr would enter accidentally, would it?

[ojanvafai]

I don't know. I defer to @choniong. :)

[johanneswilm]

@rniwa I don't know enough enough about bidi to know whether they are useful. I am mostly concerned about being able to turn them off for pure English text.

Note that some UA may still insert BDI, LRM, RLM, etc... Unicode control character via insertText to control the direction of text still so there isn't really a way to not support bidirectional text.

OK, but those will be unicode characters that come in through a beforeinput event. That's different than this menu which adds a style-tag to a paragraph, especially if it doesn't emit a beforeinput event for this DOM change. Also, entering those unicode characters wouldn't be something that someone who doesn't anything else than ltr would enter accidentally, would it?

[rniwa]

I can tell you that being able to change the block direction of text is extremely important for bidi users. They can't meaningfully use text editors without this feature.

What I mean is that UA could implement that menu item by inserting LRM and RLM instead so I'm not certain if we can guarantee that all UAs would use the newly added input types.

Having said that, it is true that mutating the direction of an existing text is a conceptually different operation from inserting LRM, RLM, BDI, etc... as users type new text into a text field / editor.

[johanneswilm]

What I mean is that UA could implement that menu item by inserting LRM and RLM instead so I'm not certain if we can guarantee that all UAs would use the newly added input types.

This would happen through a beforeinput, inputType = insertText event, right?

That would be more acceptable. At least it would not be causing a DOM change that doesn't go through a beforeinput event.

If a browser would do that, then I think I could wait with getting a specific inputType just for that, even though I still think it may be confusing to end users to see such a menu entry if they aren't familiar with anything else than ltr text.

[rniwa]

If a browser would do that, then I think I could wait with getting a specific inputType just for that, even though I still think it may be confusing to end users to see such a menu entry if they aren't familiar with anything else than ltr text.

FWIW, what each vendor puts on their browser UI is outside the realm of what this task force is chartered to spec.

[johanneswilm]

@rniwa Right, but we need to deal with what browsers actually have. So if the browsers that exist today that have the direction-changing menu entry all agree that they can change the functionality so that they only add or remove characters of text nodes, and that they would prefer that to creating one or several new inputTypes for their writing-direction menu entries, then I would say that would be a workable alternative for now.

I think we all agree that every DOM change in the editing area needs to have a beforeinput event. So if the writing-direction menu entries change the DOM, they need to do this through some beforeinput event, right? I don't care too much which one we pick, but I would prefer if we could have one that would express the user intent as much as possible.

[rniwa]

Yeah, I think the easiest path forward is to add those input types for now.

[johanneswilm]

Ok, so what should we call it? "setBlockDirection" with values "ltr", "rtl" and "default"? Other suggestions?

[johanneswilm]

• For contenteditable=typing, "insertText, insertFromPaste, insertFromDrop, insertNonText, insertFromYank, undo, redo"
• For contenteditable=true, a space separated list of all input types
• Otherwise, the empty string.

I think this goes somewhat counter to the idea of contenteditable=typing, contenteditable=caret, etc. : The idea with these modes was to disable the browser's automatic handling of these events, so that instead the JavaScript editor would listen to all the beforeinput events and do all the needed changes to the DOM itself. For contenteditable=typing, the idea was that the browser would only handle keyboard typing and IME input and the JavaScript would handle everything else. That wouldn't work if we turn off a lot of the inputTypes for this mode, as that would mean that the relevant menus would disappear and presumable the beforeinput events wouldn't be triggered either for keyboard shortcuts, etc. .

I am fine with all the rest of it. I think we should probably take the discussion about the alternative contenteditable types at the next meeting after the one tomorrow and focus on beforeinput/input tomorrow.

[ojanvafai]

+1 to punting on contentEditable=typing until we've solidified beforeInput, supportedInputTypes, inputmode and inputmode-action. Those four are by far the most common author requests we get. We should still explore contentEditable=typing/events/etc, but given limited resources, we can punt unless some browser vendor really needs it sooner rather than later.

[rniwa]

If we're going with a new input type, I'd suggest setBlockTextDirection and setInlineTextDirection with values of ltr, rtl, auto, and null (default).

setBlockTextDirection sets the block text direction of the selected content as if dir attribute was set on the containing block element.

setInlineTextDirection sets the inline text direction of the selected content as if LRI, RLI, or FSI Explicit Directional Isolates Unicode control characters were inserted at the beginning of the selected text, and PDI was inserted at the end of the selected text.

[chong-z]

@rniwa Just a followup to https://github.com/w3c/input-events/issues/32#issuecomment-248762122.

Add the support for "backColor", "createLink", "fontName", and "fontColor" to inputType as new input types.

I believe there is no objections in TPAC, we could just add them to spec.

UA must not fire any beforeinput or input event with an input type not included in the list of the supported input actions.

For contenteditable=typing, "insertText, insertFromPaste, insertFromDrop, insertNonText, insertFromYank, undo, redo"

There seems to be some disagreement about the inputType restriction, see https://www.w3.org/2016/09/22-webapps-minutes.html#resolution09

If I understand correctly your proposal is:

• If an inputType is not included in the list, it should be reflected in the UI and the user shouldn't be able to trigger this action, thus UA must not/has no way to fire the 'beforeinput'/'input'.

But the problems are:

1. cE=typing should be different (from plaintext only textarea), where the UA should still fire all inputType, but instead JS will handle other rich text inputType. Can we remove restrictions to cE=other stuff? (Or discuss later)
2. Assuming you are trying to solve https://github.com/w3c/editing/issues/93, however the proposal won't be able to disallow Copy, Select, Look Up, etc. Or is that intentional?

[johanneswilm]

Add the support for "backColor", "createLink", "fontName", and "fontColor" to inputType as new input types.

I believe there is no objections in TPAC, we could just add them to spec.

They have now been added.

But the problems are

Right, but these restrictions are only about the alternative contenteditable modes. The overall model for being able to turn of features this way seemed to be uncontroversial. The UA will now which actions should be available, and it alone decides what changes it will make to the UI based on this knowledge.

However, in cases like iOS and the native menu that overlaps everything, it is to be assumed that Safari will solve this in a way that makes the menu smaller or go away entirely, as this seems like the easiest solution for them, and it will allow their users to use webbased editors more easily.

[rniwa]

If I understand correctly your proposal is:

• If an inputType is not included in the list, it should be reflected in the UI and the user shouldn't be able to trigger this action, thus UA must not/has no way to fire the 'beforeinput'/'input'.

The proposal is that only the list of input types explicitly listed in supportedinputactions would be allowed, and UA should reflect that in its UI.

But the problems are:

1. cE=typing should be different (from plaintext only textarea), where the UA should still fire all inputType, but instead JS will handle other rich text inputType. Can we remove restrictions to cE=other stuff? (Or discuss later)
2. Assuming you are trying to solve https://github.com/w3c/editing/issues/93, however the proposal won't be able to disallow Copy, Select, Look Up, etc. Or is that intentional?

I think you misunderstood our proposal. The proposal is to have a sensible default value for supportedinputactions so that omitting the content attribute would result in all input types being allowed at least in contenteditable=true case.

I think it's also useful to have a shorthand for common sets of input types. For example, if you wanted to allow typing, deleting, replacing text, etc..., then something like typing shorthand which logically expands to insertText insertReplacementText insertLineBreak insertParagraph insertFromYank insertFromDrop insertFromPaste insertCompositionText insertFromComposition deleteWordForward deleteWordBackward deleteSoftLineForward deleteSoftLineBackward deleteEntireSoftLine deleteHardLineForward deleteHardLineBackward deleteCompositionText deleteByComposition deleteByDrag deleteByCut deleteContent deleteContentBackward deleteContentForward insertTranspose would eliminate the need to explicitly enumerate each and every input types.

[johanneswilm]

I think you misunderstood our proposal. The proposal is to have a sensible default value for supportedinputactions so that omitting the content attribute would result in all input types being allowed at least in contenteditable=true case.

I think it's also useful to have a shorthand for common sets of input types. For example, if you wanted to allow typing, deleting, replacing text, etc..., then something like typing shorthand which logically expands to insertText insertReplacementText insertLineBreak insertParagraph insertFromYank insertFromDrop insertFromPaste insertCompositionText insertFromComposition deleteWordForward deleteWordBackward deleteSoftLineForward deleteSoftLineBackward deleteEntireSoftLine deleteHardLineForward deleteHardLineBackward deleteCompositionText deleteByComposition deleteByDrag deleteByCut deleteContent deleteContentBackward deleteContentForward insertTranspose would eliminate the need to explicitly enumerate each and every input types.

Having a shorthand for combinations would be useful, but this shorthand would then be used in the attribute that specifies the allowed actions, right? In your initial proposal:

• For contenteditable=typing, "insertText, insertFromPaste, insertFromDrop, insertNonText, insertFromYank, undo, redo"
• For contenteditable=true, a space separated list of all input types
• Otherwise, the empty string.

It sounded as if contenteditable=typing should only allow 7 input actions and no delete actions. contenteditable=typing should only allow default handling of these inputTypes, but should still trigger beforeinput events for other inputTypes. That's why we postponed discussion/decision on this part of your proposal.

[rniwa]

Just using shorthand in supportedinputactions is fine. The exact set of default values for supportedinputactions is not important for us so long as it's defined when supportedinputactions is omitted, and author doesn't have to enumerate dozens upon dozens of individual input types for common use cases.

[chong-z]

Just using shorthand in supportedinputactions is fine. The exact set of default values for supportedinputactions is not important for us so long as it's defined when supportedinputactions is omitted, and author doesn't have to enumerate dozens upon dozens of individual input types for common use cases.

I think the confusion is how do you define support.

It could be defined as either:

1. UA still fires 'beforeinput', but no default action, or
2. UA doesn't fire 'beforeinput', thus UI should reflect the change.

contentEditable=typing is using Definition 1 (see contentEditable=events), and I believe your proposal is using Definition 2.

[rniwa]

Oh, it certainly needs to do 2 because the whole point of supportedinputactions content attribute is to disable UI and key bindings. Without UI and key bindings, it's not possible to fire events.

[chong-z]

Oh, it certainly needs to do 2 because the whole point of supportedinputactions content attribute is to disable UI and key bindings. Without UI and key bindings, it's not possible to fire events.

Exactly, so back to the 2 problems in https://github.com/w3c/input-events/issues/32#issuecomment-251554878:

1. supportedinputactions should have nothing to do with cE=typing as they are two different features. (Although they might be able to share the shorthand for the category of inputType) e.g.
   • cE=typing means UA will preventDefault() on other inputType
   • supportedinputactions=typing means disable UI and don't fire events for other inputType
2. Just to confirm, your proposal for supportedinputactions doesn't have the ability to disable Copy, Select, Look Up (as there is no corresponding inputType). Are you OK with this?

[johanneswilm]

Just to confirm, your proposal for supportedinputactions doesn't have the ability to disable Copy, Select, Look Up (as there is no corresponding inputType). Are you OK with this?

I don't think JS editors are OK with it if this means that the overlay menu on iOS cannot be removed because some menu items will always be there. Other than that, it doesn't seem to be much of an issue.

The urgent need for being able to remove support for actions seems to be quite directly linked to the iOS Safari menu, and maybe to a lesser degree to the Mac OS X Safari menus, although it seems to be a smaller problem to ignore those. So far I have not heard any of the JS editor developers complain about other browsers/OSs, so whether or not the copy can be turned off in the Android or Windows Mobile menus seems to be less of a concern.

[rniwa]

1. Just to confirm, your proposal for supportedinputactions doesn't have the ability to disable Copy, Select, Look Up (as there is no corresponding inputType). Are you OK with this?

Yeah, I don't think those are input actions. They're more of selection features so we should be discussing in a different avenue (e.g. in the selection API). Also, disabling copy doesn't really make sense on Linux where middle button click is supposed to copy & paste things from any app to any other app.

[johanneswilm]

Yeah, I don't think those are input actions.

Agreed.

But that also means we need to find another solution for this:

or this:

[johanneswilm]

@choniong @rniwa How about if we add copy to the list and potentially others and define it so that if an input action is not enabled, the corresponding beforeinput event is not triggered and the default action of that beforeinput event is not taking place if there is a corresponding beforeinput event.

So in the case of copy, where there is no corresponding beforeinput event, only the UI elements are disabled/removed, but because there is no beforeinput event, nothing is canceled.

[rniwa]

Preventing copy doesn't really make sense in that any text that's selectable should be copyable on iOS and Mac. Not allowing copy would result in a serious UX degregation. We should be able to disable cut & paste when the corresponding input events are not listed in supportedinputactions.

[johanneswilm]

@rniwa True, but the point is to get the menu out of the way because it overlaps with the editors menus. So I would imagine either one adds one's own buttons that then create a copy action (which should be event easier to do with the updates that have been announced for the clipboard api), and/or the JS code adds and removes the copy from the list continuously to make the UI show at certain times and not show at other times, to prevent overlapping.

[rniwa]

@rniwa True, but the point is to get the menu out of the way because it overlaps with the editors menus

I don't understand what that even means. On iOS, the way to copy text is by selecting text and tapping on "Copy" on the popover that shows up.

On Linux, there is an implicit copy whenever selection changes on any app because the user can press a physical middle button on his mouse to initiate the paste on any other app, and the original app that put the content into the clipboard doesn't even get notified.

So this idea of overriding a way to initiate a copy can't even be implemented on some platforms even in native apps without breaking the fundamental UX of the platform.

[johanneswilm]

I don't understand what what even means.

See the two screenshots in https://github.com/w3c/input-events/issues/32#issuecomment-253676018 . This is what JS editors seek to avoid in some way. And this turning off of features was the way we hoped to get there, but if the copy entry won't go awya that way, then we need to find another way.

[johanneswilm]

So this idea of overriding a way to initiate a copy can't even be implemented on some platforms even in native apps without breaking the fundamental UX of the platform.

AFAIK, the overlapping problem is exclusively a Safari/iOS issue. That's the only ones we have heard complain, anyway. Android and Windows phone don't seem to have this issue.

I don't think it matters how it's fixed to the editors who have this problem, so if there is some other way that is more compatible with your platform, then that should work just as well.

[rniwa]

The only way to disable that would be to disable text selection entirely.

[johanneswilm]

The only way to disable that would be to disable text selection entirely.

OK, but the point seems to be that they want to show their own menu when text is selected, the reason being that they offer actions the browser native menu doesn't provide, so they cannot easily use the one that comes with the browser. Maybe we need to think in some completely different way to resolve this, how about one of these:

• Provide an easy way to add custom entries to the browser native editor menus.
• Make sure that JS can create its own text selection system if native text selection is turned off (may be a bit too complex if this is only needed for one platform).
• Provide the JS with coordinates for the part that is being overlapped by browser native UI elements so that the editor can move its menus somewhere else (again: may be a bit too complex if it's only needed for Safari/iOS).

[rniwa]

Provide the JS with coordinates for the part that is being overlapped by browser native UI elements so that the editor can move its menus somewhere else

This is probably a good idea. Because on Mac, there is an autocorrection bubble that shows up as user types. On almost all non-mobile platforms, input methods' candidate window almost always overlaps with autocompletion feature websites provide.