Re: contentEditable=minimal

At the beginning I've been sceptical regarding cE=minimal not doing any DOM
modification at all. The ideal situation which I imagined was that you can
easily use cE=minimal in basic case like a single paragraph of text with a
bold and italic buttons (which you need to implement by yourself). This is
a pretty common use case if you have structured content and you allow
editing only specific parts of it, but want to provide basic styling
support. In my imagined situation you would only need to handle style
application/removing and filter pasted/dropped content. All this would be
less than 1k LOC.

And the code size matters. CKEditor's implementation of inserting text and
HTML into selection is 2-3kLOC (hard to estimate because of code reusing).
Few backspaces/delete cases which we handle take around 500LOC which then
use next >2kLOC. I'm pretty sure that full implementation of HTML and text
insertion, backspace and delete, caret movements plus all the necessary
bindings will not fit in 10kLOC (it's a jQ size) unless browsers will help.
And this may affect cE=minimal adoption (or quality of implementations)
because many developers don't accept so big libraries (especially for
mobiles) and well... there's cE=true still - why not use it?

On the other hand, I must agree that even most basic handling
for content deleting and insertion (which shares a lot with deleting) leads
us to immediate problems. Even in simplest case <p>fo[o<b>bar</b>b]om</p>
we need to remove the <b> element, because no one expects that only text
nodes will be deleted. So when we started deleting <b>, then what about
cells selection in tables and so on. Let's leave this. No DOM modifications
made by browser.

So my two proposals are:

1. Events should be made as useful for developers as possible. Delete and
caret movements events should contain information about proposed target
selection, and text input about the character/word. I'm not sure though if
algorithm for finding position after delete and caret movements is simple.
Having this is actually half the way to fully handling these actions.
There's inline, inline-block, block contents, empty elements, tables,
non-editable content (cE=false), nested editables, boundaries of inline
elements, etc. Can the spec contain all this? BTW. This reminded me about
range walker, which is an extremely useful tool, but I haven't seen it in
any specification.

2. I second the idea about example, basic implementation of text insertion,
caret movements and backspace/delete. It does not have to really work,
because it would require cE=minimal and command events to be ready or at
least mocked. But the sample code will be very helpful. It will help some
of us to imagine how all of this will function (e.g. I'm not sure I
understand what and how I will have to handle about composition). And it
will be a nice addition to spec in the future.


On Fri, May 23, 2014 at 11:55 AM, Jonas Sicking <jonas@sicking.cc> wrote:

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



-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer
--
CKSource - http://cksource.com
--
Follow CKEditor on: Twitter <http://twitter.com/ckeditor> |
Facebook<http://www.facebook.com/ckeditor>|
Google+ <https://plus.google.com/107736718646302128806> |
LinkedIn<http://www.linkedin.com/company/cksource>