Re: 3 things

> On Oct 21, 2015, at 12:28 AM, Johannes Wilm <johannes@fiduswriter.org> wrote:
> 
> On Tue, Oct 20, 2015 at 9:01 AM, Ryosuke Niwa <rniwa@apple.com <mailto:rniwa@apple.com>> wrote:
>> 
>> > On Oct 19, 2015, at 3:58 PM, Johannes Wilm <johannes@fiduswriter.org <mailto:johannes@fiduswriter.org>> wrote:
>> >
>> > On Mon, Oct 19, 2015 at 6:30 AM, Ojan Vafai <ojan@google.com <mailto:ojan@google.com>> wrote:
>> >> IMO, there are three things I'd like to get agreement on in Sapporo and then I'll be happy encouraging our Chrome editing folks to consider implementing what we've got.
>> >>
>> >> 1. The composition + focus change thread I just sent an email about.
>> >> 2. Spec the delete behavior. I think this is a small subset of execCommand and is the only way to make contentEditable=typing not treat IMEs in some weird, special way.
>> >
>> > Why do we need this again?
>> >
>> > As far as I can tell, there are only two operations that can potentially remove parts of the DOM:
>> >
>> > 1. Within an IME text composition, it can remove one of the characters. This is an operation that only happens on a text node.
>> 
>> That's not necessarily true.  Some IMEs, namely one on Android, allows deletion of the stylized text
> 
> 
> Really? As far as I can tell, on the Android IME it has two steps:
> 
> step 1: move all characters belonging to one word into the same text node (which will be inside just one element)

This is what I was describing.

> 
>> However, there is no guarantee that JS will respect (1) and keep the entire text in a single text node (e.g. for styling purposes; think of custom text adjustment algorithm which places each character in a separate position:absolute elements).
> 
> Ok, do we know of IMEs that do not have this separation and that work on more than just text nodes?
> 
> I am asking because if current IMEs don't work on more than individual text nodes after a phase of mangling the DOM, then this will make it easier for us to deal with and to make work in JS editors.

We shouldn't be using an argument that it's okay to break things because it's already broken.


>> I've talked a bunch of people working on iCloud apps, and it seems that keeping the entire composting text in a single text node is a somewhat of a lost cause.
>> 
>> > 2. When recomposing text in an IME that supports this (Android/iOS), if the word that is to be composed goes across several DOM elements, the browser tries to move all parts of the word into just a single element at some stage (compositionstart or when the first change is made). This can mean that nodes are destroyed, etc. .
>> 
>> Again, this could be modeled as "replace" followed by regular composition but it would still hinges on the idea that text editors will put the entire text run in a single text node.
>>  
> Yes, but the replacement is not something the user asked specifically for. It's rather something the browser does in the belief that it is OK to do this simplification of the DOM. That may or may not be true. The JS should know more about that. At least I would like to treat this case differently in my JS code than the cases where the user intentionally did some changes to the DOM.

I disagree. If IME were to start replacing text, then that's exactly what the user intended to do.  Having said that, I'm not opposing adding flags, etc... to indicate that some editing commands are happening due to IME.

>> > I have received Microsoft's list for actions they have in menus on their various devices, and that list is really short and covered by what we have already. I have asked for a list of things they have keyboard shortcuts to. Such a list would be nice to have, but it seems to me that a specific keyboard shortcut not working automatically, is not as bad as having a system menu not work. Also, keyboard shortcuts can be implemented in JavaScript as of today.
>> 
>> I don't think implementing keyboard shortcuts in JavaScript is a good idea. You end up sniffing the operating system name and behaving differently on each one.  e.g. Cmd+B on Mac to bold text but Ctrl+B to do the same on Windows.  The whole point of the Web platform is to provide an abstraction around such a platform-dependent behaviors.
> 
> Right, but if we want to keep the list as short as possible, it is more important to include the bold, italic, underlining, insertLink that you mention because that you mention as that will actually be visible in some menu and ultra confusing if the menu doesn't work.

Listifying is another feature.  In general, I don't think there is a point in keeping this list short because this will be an opt-in feature.  Only apps that support such operations list them as being supported and browsers would reflect that on their UI accordingly.  I'd suggest supporting every single execCommand listed.

> However, if someone in his editor wants to create a shortcut to "turn text to color red, capitalized strikethrough and font face wingdings" then that person is still free to do that (just as now), yet we don't need to to do anything.

They could but this is a problem we should be fixing (not necessarily in editing-tf) by providing some sort of keyboard shortcut abstraction.  It's really awful for web apps to be using different keys (Cmd vs. Ctrl) by detecting systems.

> Btw, would it make sense to create a "default" action for beforeInput that is used whenever the user intents to change the contents of the editor, but we have not yet defined an action name in the current spec? Would that solve the issue of polyfills, or would it just be a useless complication?

I think we probably want to vendor prefix those actions or "x-" prefix them.

- R. Niwa