Re: 3 things

On Wed, Oct 21, 2015 at 10:11 AM, Ryosuke Niwa <rniwa@apple.com> wrote:

>
> 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> 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)
>
>
> This is what I was describing.
>

Ok, if it is cleanly separated like that, we don't need to just allow
generic deletion. We just have the inner-IME text deletion (which cannot be
canceled) and the composition-related moving of content (which also cannot
be canceled).

Let's just have those two and nothing more.


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

No, but the point is we should limit it to the actual limits of IMEs and
how they work with browsers today.


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


If I have the word "<span class='first'>A</span>pple" and touch it on
Android, without having done anything more, it turns into "<span
class='first'>Apple</span>" .

I don't think there is any reasonable way to say it was my intention to do
that. It's just the IME on Android that wanted it that way. The JS needs to
have a chance to undo this afterward, or to have the entire thing sandboxed
so that this change is not committed to the actual DOM during the operation.

But you are right, in other situations the IME behavior could actually just
mirrors what I would have wanted to do anyway.


>  Having said that, I'm not opposing adding flags, etc... to indicate that
> some editing commands are happening due to IME.
>

Ok, good. then we agree.

But the point is also we need this exchange of content to happen once, and
it has to be after compositionstart or if compositionstart happens
afterward, then we need some other sign before the content is being
auto-changed.


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

That's also fine with me. As logn as it's not a list we just keep expanding
and never get a full 1.0 version of.  So you propose all of these commands
here: [1] or do you have exceptions?

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

right. but I think this is slightly out of scope for us now, agreed? Maybe
version 2.0, right?


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

I see. Does that work with everyone's vendor prefix policy (just asking).


>
> - R. Niwa
>
>
[1] https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand

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