Re: contentEditable=minimal

I have questions about contentEditable=minimal
1. Does document.execCommand() work on contentEditable=minimal?
2. Does contentEditable=minmal support [Backspace], [Delete] keys?
3. Does contentEditable=minmal support Ctrl+C, Ctrl+X, Ctrl+V key
combinations?
4. Will contentEditble=minimal spec defines deleting and pasting? Deleting
and pasting are complex operations, especially selection range cross over
elements, or on table.

I may not clear for "some keyboard handling".

Thanks
-yosi



On Thu, May 22, 2014 at 7:43 AM, Julie Parent <jparent@gmail.com> wrote:

> I question whether contentEditable=minimal should actually handle text
> input.  If the idea is to provide the base platform on which a developer
> can build the editing product of their dreams, isn't text insertion just
> another behavior they could potentially need to disable?
>
> Stepping back, there are distinct concepts that all combine to form the
> current editing environment:
>
>    1. Selections: Enable selections, perform cursor movement, scoping the
>    boundaries on which the selection can operate.
>    2. Input: Perform dom modifications, dispatch events, not limited to
>    keyboard input, also includes IME, paste, drop, etc.
>    3. Spell check: Enable spell check, modify the dom (or dispatch an
>    event) when the user selects a replacement
>    4. Formatting magic: bold when the user hits control + b, change
>    directionality on Ctrl+LeftShift , etc.
>
> It sounds like contentEditable=minimal as proposed would only enable #1
> and #2, and perhaps allow for #3? To break editing down into true building
> blocks, I think we need to provide developers a way to explicitly enable
> each of these systems separably, and not require the element to be
> contentEditable.
>
>
>
> On Mon, May 12, 2014 at 9:26 AM, Robin Berjon <robin@w3.org> wrote:
>
>> On 12/05/2014 00:46 , Johannes Wilm wrote:
>>
>>> Also this looks good. There seems to be consensus that contenteditable
>>> is just not going o get fixed, and so removing the faulty behavior
>>> entirely and replacing it with this would be almost as good.
>>>
>>
>> It depends on what you mean by "fixed". It is conceivable that given
>> enough time and energy the current contentEditable behaviour could be made
>> interoperable, but the problem is that even if that happened it seems clear
>> from developers' feedback that it wouldn't do what they want. A lot of the
>> time you would still want to disable a lot of what it does by default and
>> handle it yourself. This is therefore just intended as a way of providing
>> developers with primitives for editing.
>>
>>
>>  Intercepting key strokes is already now possible and probably the best
>>> one can do. The one thing where this gets complicated is when typing
>>> characters using more than one key stroke. such as ~ + n to make ñ.. I am
>>> not sure if you include that under the "Some keyboard input handling".
>>>
>>
>> Yes, text input is a hard problem and you can't get away without solving
>> it. We are talking about providing primitives here, so things can be
>> expected to be a little bit hairy though.
>>
>> DOM 3 Events has something called composition events for the example you
>> bring up (which can get a whole lot more complicated, notably with things
>> like Kotoeri and such). On the face of it it would seem to be the needed
>> part but I've never used them (or seen them used) in the real world. (The
>> quality of browser support is also unclear at this point.) Some cases also
>> require the IME API.
>>
>> Developers relying on the bare bones cE would probably have to handle the
>> rendering of ongoing composition themselves (which isn't the end of the
>> world, but you need to think about it or you are guaranteed to mess things
>> up). This is probably acceptable at this level, libraries can make it
>> easier.
>>
>> --
>> Robin Berjon - http://berjon.com/ - @robinberjon
>>
>>
>