list all required editTypes for beforeEdit/Edit events

[johanneswilm]

At the end of the F2F we found out that Safari has a built-in edit menu to give access to a number of richtext styling commands. We need both a way to turn that menu off (by means of an attribute or otherwise), and we need to list all those edit commands as editTypes for the (before)Edit events. Other browsers may want to hook into those events, even if they don't have a similar menu (ctrl+b -> bold, etc.), but this is not a requirement (browsers may not be listening to key combinations at all).

Also, we need to list the editing events typically supported by Microsoft and add them to the editTypes list if they are not covered yet.

@rniwa has promised to provide such a list within a month.

[spocke]

Couldn't the basic cE=events be without built in text formatting. Then have a cE=styles mode or something to opt-in to later on in some future version of the spec. Then we don't have to spec these commands.

This is an issue on iOS as well where it displays b/i/u in the selection context menu. A.f.a.i.k IE/Edge has only keyboard shortcuts for these that we currently override in for example TinyMCE.

[spocke]

Never mind. I needs to be available for cE=true too. So it needs to be specified.

[ojanvafai]

We don't need separate events though, right? We can add these to beforeInput/input with new editTypes.

[johanneswilm]

@ojanvafai: yes, sorry for confusing wording. Will update.

[johanneswilm]

@spocke I would also have preferred if we had had the list a while ago so we could have had a good discussion about them at the F2F, but I think the amount of edit events should still be fairly limited and the change should be straightforward and not be the cause of many extra concerns, because browsers aren't required to hook into these if they don't listen to "make bold" etc. anyway. So I think it's a good idea to still put it in now, and not wait until a future version.

On your side, you can choose not to listen to these events in three of the four modes (events, caret, typing) and nothing happens. In cE=true, you'll have to do preventDefault to stop them.

@rniwa When you figure out about an attribute to disable the edit menu, could you also make sure the styling menu is disabled on the iOS context menu? As we talked about yesterday, even though an editor can choose not to listen to that event, it will be rather confusing to users if they can choose something in a menu that then doesn't do anything.

Also: Do we have similar problems on Android or Windows Phone?

[Reinmar]

Also: Do we have similar problems on Android or Windows Phone?

In Chrome@Android there's only "select all", "cut", "copy" and "paste" (all in the top bar of the browser).

In IE11@WP there's only "copy" (next to the selection) and then "paste" (next to the keyboard).

[rniwa]

This becomes an even greater issue on iPad in iOS 9 which provides the software keyboard with buttons to bold, italicize, underline, etc... text.

[johanneswilm]

@rniwa: On iOS9 iPad, what kind of keyboard do you show when the user types into a textarea or an input field? Can you show that keyboard instead?

[rniwa]

@johanneswilm : I don't think it's acceptable to always show the keyboard without those buttons if the editor supports rich text editing; e.g. mail client, RTF editor, etc... so this needs to be configurable by the author.

[johanneswilm]

Yes exactly, that's why I mention the possibility to turn it off/on by means of an attribute. You can also invent something more granular so that individual styling options can be turned on/off. Since Apple is the only one doing this, it's pretty much up to you at this stage.

[gked]

Currently, there is only COPY/PASTE default icons available on windows phone.
@rniwa: I can send you the list of all commands that are supported in Edge by default for consolidation, if you like.

[johanneswilm]

@gked It would be good if you could send that list to @rniwa.
As for COPY/PASTE, I think they are much less problematic because almost all editors will want to support those. But not all may want to offer "strikethrough", selecting the font, etc. .

[johanneswilm]

@rniwa : How far did you get in finding all the items for that list?

[rniwa]

I haven't collected the list. I've been busy with web components and other stuff.

[johanneswilm]

OK, @gked could you send me the default commands supported in Edge? @rniwa Where could I obtain the current list for what you need on Mac OS X/Safari?

[rniwa]

I don't know where you can get such a list.

[johanneswilm]

@rniwa :) OK, I guess we'll have to rely on you to get this information to us at some stage. Or if it's super complex, we'll discuss it more at the session at TPAC.

[gked]

@johanneswilm:I am working on it.

[johanneswilm]

At the meeting in Sapporo we said we would start out by using the current list of execCommand editTypes. The edit types accessible through menus and shortcuts used in IE/Edge and the other browsers all seem to be subsets of that list. The list of commands are these: https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand#Commands

[chong-z]

Just to confirm are we planning to implement all the commands in https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand#Commands?

And should we fire beforeinput/input for commands like copy and selectAll? From my understanding it seems that they are not updating DOM?

[johanneswilm]

@chonlong: Exactly. It doesn't make sense to have this work for execCommands that do not require editing hosts and/or aren't updating the DOM. It would be very strange if one could stop copying only in editing hosts and not anywhere using this.

[chong-z]

I was wondering do we got a list of all the required InputEvent types yet? I'd assume we want cut, paste, redo, undo, insertText, replaceContent, insertLineBreak, insertParagraph, deleteComposedCharacter, deleteContent?

But I'm not sure if we want insertHTML and text styling like bold, italic, strikeThrough, underline and justifyCenter etc.?

Thanks!

[ojanvafai]

We need a type for any built-in to the browser behavior that modifies the DOM. So, we need all the text styling ones. I'm not sure there are any built-in behaviors that insert html other than what is already listed in your first list.

[johanneswilm]

We need a type for any built-in to the browser behavior that modifies the DOM. So, we need all the text styling ones.

Correct. How about the clipboard ones? I think all we who have worked on this spec would agree that paste and cut should also be included, but from what I gather, @hallvors from the Clipboard API disagrees, correct?

[johanneswilm]

@choniong See #110 (comment) . We need to cover at least the ones that people can modify the DOM via a common key combination, but possibly much more, if browsers decide they want built-in menus to allow users to choose from these other things.

This issue seems to be covered in the discussion at the above link, and those inputTypes have been added to the spec draft, so I close this issue.