Re: contentEditable=minimal

On 23/05/2014 11:55 , Jonas Sicking wrote:
> On Thu, May 22, 2014 at 3:59 AM, Piotr Koszuliński
>> 5. Navigating with arrow keys, selection with SHIFT, CTRL modifier.
>
> Agreed. Developers have to deal with selection moving around anyway
> since they should handle touch screens.

Even without accounting for touch screens, you really want the platform 
to be the thing that knows what Ctrl-Shift-Left means so you don't have 
to support it yourself (and get it wrong often).

> But we should definitely fire events whenever cursor or selection is
> moved and enable the page to either cancel the movement, or adjust the
> location before it takes effect.

Agreed. I also think that it is important that if the selection is 
allowed to have anchors both inside and outside the editing area then 
the editing MUST NOT retain focus. Anything else would lead to really 
annoying cases.

Note: you keep saying things like "cursor or selection". Can we agree 
that they are the same thing? A caret on its own is a selection with a 
single collapsed range (and a direction).

Which brings me to think: when we discussed this at the Summit, there 
was some agreement (between all four of us :) that it was a good idea to 
support multi-range selections. These are useful not just for tables, 
but also for bidi. The reason for the latter is that when selecting a 
line with multiple embedded directions (using a mouse), you want to have 
the visual selection be an unbroken line (as opposed to the crazy 
jumping around you get if you follow logical order).

It's definitely useful, though it does come with its problems. The 
question that opens up for me is: do we want to support multi-caret 
editing as well? The data model certainly supports it, but we have to 
account for it early if it's an option.

At any rate, multi-range selections would be much easier to handle if we 
had something like Selection.forEachRange(function (r) {...}).


> Regarding text entry, I think this is the really hard decision that we
> need to make. I.e. should we "only" fire enough semantic input events,
> or also implement "plaintext" editing in addition.
>
> One interesting question is: Are pages generally happy with the
> plaintext editing of <input type=text> and <textarea>? Or do they find
> themselves often having to override their behavior using the events
> that browsers fire?

I would say yes and no. I don't think we need numbers to state that 
there's a lot of content out there that uses unadulterated 
input/textarea. But they're also handling what is guaranteed to be pure 
text. That is not at all the same as structured text.

Also, a non-negligible subset of those do indeed override the browser's 
default behaviour. Typical cases are input masking or formatting. (Given 
the largely useless state of date inputs today, that's not going away 
any time soon, either.)

> What are the use cases of events like compositionstart and
> compositionend? Were they added in order to enable webpages to
> override composition related editing of <input type=text> and
> <textarea>?

If you look at the examples I posted, you can see that you can't do your 
own rendering of composition unless you have these. As far as I know 
that's the primary use case.

> What about the beforeinput event?

My understanding is that it is cancellable while input is not, which 
enables people to pick the one they need based on their needs and its 
performance implications.

A lot of sites nowadays do something like this: have a textarea in which 
you can enter Markdown, WikiText, or some other horrible goo and with 
every character you type a preview rendering of your text gets updated.

If you use a cancellable text event and carry out the rendering in the 
event handler, the browser has to wait for the rendering to finish 
before it can paint the character in the source box. That leads to a 
small but perceptible lag. Presumably if you operate on events that have 
already had their default action carried out you're fine here.

This isn't to say that this is perfect. It seems to me that this is an 
area of events that isn't all that interoperable yet so we have some 
leeway to change things. (Or perhaps even invent something new.)

> I think there might be a lot of boiler plate needed to implement
> plaintext editing. Not only are there normal "beforeinput" events to
> take into account. There's also things like composition events,
> backspace vs. delete, modifier+backspace/delete (deleting a
> word/line), voice-to-text input (provides data word-by-word), pasting,
> (bidi?), etc. It adds up pretty quickly.

Not all of those are separate, though. Voice input is just an input (or 
beforeinput) that's more than one character long. There's nothing wrong 
with that. So is pasting (though you need cleaning up). Composition you 
need to handle, but I would really, really hope that the platform gives 
you a delete event with a range that matches what it is expected to 
delete rather than have you support all the modifiers (which you'll get 
wrong for the user as they are platform specific). As seen in the code 
gist I posted, given such a delete event the scripting is pretty simple.

> Some of these things pages will have to deal with no matter what. As
> has been pointed out, if the user selects across multiple elements and
> presses delete or 'a', then almost certainly the page will have to run
> application logic. Likewise if the cursor is placed right after an
> element but before a bunch of text, and the user then presses
> backspace.
>
> However it seems like if authors generally are ok with the plaintext
> editing that <input type=text> and <textarea> has, and then only have
> them worry about things like inserting elements to do styling or
> inserting document structure (lists, headers, paragraphs, etc), then
> that means less work for the author, and greater likelihood that text
> editing works as the user expects.

I'm sorry, but I'm not sure that the above makes sense :)

If people want plain text and *nothing* else, I have a great solution 
for them: textarea.

If you have a situation that involves markup however, you need to handle 
it. And I really, really don't think that we will be doing anyone a 
service if we end up with a solution in which the browser will handle 
text for you UNLESS you have an element-spanning selection OR MAYBE 
backspace right after an element AND PERHAPS delete right before one, 
etc. in which case you have to run some application logic.

Maybe I'm missing something and there's an easy way to disambiguate 
here, but it seems like the sort of path down which madness lies. Do you 
have some code to illustrate how it would work?

> I suspect that the right thing to do here is some experimentation. It
> would be very interesting to do a prototype implementation of
> contenteditable=minimal which never did any DOM mutations, not even
> for IME or text editing. Then see how much code needs to handle all of
> the plaintext editing features above.

I think we can get a feel for that without having to polyfill cEmin 
first. That would be neat of course, but given the poor support of even 
very basic things like selections it's not a small project.

> Another thing that we should look at is the ability to style ranges
> rather than just elements. In Gecko we have an internal feature that
> allows us to style DOMRanges. This allows us to render a red dotted
> line under misspelled words and black line under composition
> characters. And do that without worrying about managing a lot of extra
> elements in the DOM.

Yeah, I had the same idea, used it in my example. I think it makes a lot 
of sense.

> Right now pages are forced to sprinkle elements all over the DOM in
> order to do the same thing, which then makes editing that DOM more
> complex. It would be awesome to find ways to enable styling ranges
> which would allow them to keep a simpler DOM.

It would actually be pretty awesome.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Friday, 23 May 2014 12:19:23 UTC