Re: 3 things

On Tue, Oct 20, 2015 at 9:01 AM, Ryosuke Niwa <rniwa@apple.com> wrote:

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



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)

step 2: do IME composition on that single text node.

So it doesn't ever seem to operate on more complex things that text in text
nodes inside the IME.

As I wrote in the other email, this step 1 has to happen after the
compositionstart event so that the JS has a chance of properly sandboxing
the entire thing without having the IME process mangle the DOM. Mangling
the DOM in an uncontrolled manner is what creates problems for us on the JS
side.



> although this could be modeled as:
>  1. "Replace" event which replaces the entire selected with a single text
> node
>  2. compositionstart
>

Yes, this looks similar to what I wrote.


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


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



>
> > 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 would be ok with adding those five for now. What do you guys think?


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

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.


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?

-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org