Re: contentEditable=minimal

On Thu, May 22, 2014 at 3:59 AM, Piotr Koszuliński
<p.koszulinski@cksource.com> wrote:
> ## What should cE=minimal handle?

Awesome feedback!

> ## What should cE=minimal handle?
>
> 1. Selection and caret drawing.
> 2. Selection API

Agreed on both!

> 3. Typing characters.
> 4. Delete, backspace.

I think these are the hard ones. More below.

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

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.

> 6. Spell check. When you want a native spell check you cannot override
> context menu. When you want custom context menu, you need custom spell check
> (which is extremely hard). And context menu is very important for many users
> because they used to look there for contextual options, so most editors
> override it. Therefore, a way control at least one of them (I guess it won't
> be a context menu, though that would be awesome) will be great.

There's already a contextmenu feature in HTML, though I don't know if
any other browser than Firefox implements it. And the spec has seen so
much changes that I don't know how closely Firefox conforms to the
spec. Anyhow, I think the ability to extend/replace the existing
context menu is the way to go if that's what people need.

Adding spellchecking primitivies, and forcing webpages to implement
their own spellcheck, seems like the wrong way to go about enabling
pages to do their own context menus.

> ## What should not be handled by cE=minimal?
>
> 1. Bold, italic, list, link, blockquote and other commands creating content.
> 2. Enter key support.
> 3. Tables and images resizing.
> 4. Another thing that browser engines cannot do is trying to be... too
> smart?

Strongly agree with all of these.

> 5. There should be no native toolbars in cE=minimal (and other native UI
> interfering) like the one Safari opens on iOS if you have non-empty
> selection.

I haven't yet checked exactly what's in the iOS toolbar, but generally
I don't think we should dictate UI. Clearly on mobile we don't want to
forbid browsers to bring up the virutal keyboard, which is a form of
"native UI". And the spellcheck UI that safari displays also doesn't
seem bad if spellchecking is enabled.

And UI for cut/copy/past that android renders seems good to render
*somewhere* when there's selection.


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?

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>? What about the beforeinput event?

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.

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 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'd also be interested trying out having the browser perform
plain-text DOM mutations but make sure to keep the rules very simple.
So if you select a stretch of text and press delete, we would not do
any DOM mutation (or possibly we could delete just any text content,
possibly leaving elements empty). Then see how much of a pain it would
be to allow the page to apply its own rules like "ensure all
characters are lowercase" or "insert thousand separators in numbers"
or "do syntax highlighting of JS code".


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.

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.

/ Jonas

Received on Friday, 23 May 2014 09:56:15 UTC