Re: 3 things

> On Oct 19, 2015, at 3:58 PM, Johannes Wilm <johannes@fiduswriter.org> wrote:
> 
> On Mon, Oct 19, 2015 at 6:30 AM, Ojan Vafai <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 although this could be modeled as:
 1. "Replace" event which replaces the entire selected with a single text node
 2. compositionstart

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).

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.


> As for defining deletion in general, I fear we are opening Pandora's Box there. We will need to handle paragraph merging and just about all the other complex things Florian mentions.

I agree. I don't think we want to spec anything complicated like merging paragraphs and/or deleting elements in the initial low-level CE mode.

> 
>>  
>> 3. As complete a list as we can get of the editing types.
>> 
>> FWIW, we can implement each of these 3 independently, so they don't block each other.
>> 
> Yes, I would still like to get Apple's list of formatting commands they have in at least one menu on one of their devices. 

At minimum, iPad's builtin software keyboards now support bolding, italicizing, and underling text.  It can support more elaborative features like adding hyperlinks and adding list items.  Obviously, some of these actions are not available on some text editors, but we should provide a progressive enhancement mechanism where editors can tell browsers which styling features are available.  I can also see that some editors may want to provide a custom toolbar item of their own as well.

> 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.

- R. Niwa

Received on Tuesday, 20 October 2015 07:01:38 UTC