Re: [editing] CommandEvent and contentEditable=minimal Explainer

2014-06-23 Thread Robin Berjon

On 17/06/2014 02:39 , Julie Parent wrote:

I certainly understand the concern that it would be impossible to
properly catch and cancel all events.  But I think that is somewhat the
point - it forces browser vendors to get these parts right.  All changes
to an editable dom must fire an event before the modifications are made,
and must be cancelable. Further, I'd say that if the number of events
you would need to preventDefault on grows larger than selection,
command, and maybe clipboard then that implies that we are not building
the right APIs.


Apart from other problems with building on top of contentEditable=true 
(notably that you keep getting the native browser UI, which is likely 
very wrong) I'd be really worried that we'd be painting ourselves into a 
corner with this approach.


If we realise a year or two from now that the design we picked isn't 
ideal and that we'd really need a new event type, the reliance on 
prevent everything I don't know about could severely constrain our 
options, and force us to shoehorn new functionality into existing events 
just to make sure we don't break existing content.


I don't think that the (limited) benefits are really worth it.

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



Re: [editing] CommandEvent and contentEditable=minimal Explainer

2014-06-20 Thread Ryosuke Niwa

On Jun 17, 2014, at 9:00 AM, Piotr Koszuliński p.koszulin...@cksource.com 
wrote:

 
 On Tue, Jun 17, 2014 at 2:39 AM, Julie Parent jpar...@google.com wrote:
 I certainly understand the concern that it would be impossible to properly 
 catch and cancel all events.
 
 I'm not concerned only about this. I'm concerned about the fact that 
 currently existing commands and editable-related features does not fit in a 
 simple command APIs.
  
  But I think that is somewhat the point - it forces browser vendors to get 
 these parts right.
 
 The spec should guide engines' developers, because there's a single spec and 
 many engines. Even if all browser vendors will get these parts right, they 
 may choose different paths. And then, in general, this will be not right and 
 it will be a pain for developers.
  
  All changes to an editable dom must fire an event before the modifications 
 are made, and must be cancelable. Further, I'd say that if the number of 
 events you would need to preventDefault on grows larger than selection, 
 command, and maybe clipboard then that implies that we are not building the 
 right APIs.
 
 
 I don't think that number of events implies that we are building a bad API. 
 Dozen of well defined events is better than three that do too much in an 
 unclear way.
 
 Besides that, as an editor author I'm not only interested in preventing 
 default action of features I don't want. I also want to hide them - remove 
 them from browser UI like context menus, menu bar, or other widgets like 
 special toolbar appearing over contenteditable on iOS. This makes the 
 situation which spec has to describe much more complex. That's why I think 
 it's better to focus on basics 
 (http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0918.html) 
 than on trying to make specification for every feature that was introduced in 
 any engine in any away.

This makes me think that we want something like a white list of editing 
features to enable in a given editable element or perhaps * to enable them all.

e.g. div contenteditable=inline-style copy paste dragdrop/div

- R. Niwa



Re: [editing] CommandEvent and contentEditable=minimal Explainer

2014-06-17 Thread Piotr Koszuliński
On Tue, Jun 17, 2014 at 2:39 AM, Julie Parent jpar...@google.com wrote:

 I certainly understand the concern that it would be impossible to properly
 catch and cancel all events.


I'm not concerned only about this. I'm concerned about the fact that
currently existing commands and editable-related features does not fit in a
simple command APIs.


  But I think that is somewhat the point - it forces browser vendors to get
 these parts right.


The spec should guide engines' developers, because there's a single spec
and many engines. Even if all browser vendors will get these parts right,
they may choose different paths. And then, in general, this will be not
right and it will be a pain for developers.


  All changes to an editable dom must fire an event before the
 modifications are made, and must be cancelable. Further, I'd say that if
 the number of events you would need to preventDefault on grows larger than
 selection, command, and maybe clipboard then that implies that we are not
 building the right APIs.


I don't think that number of events implies that we are building a bad API.
Dozen of well defined events is better than three that do too much in an
unclear way.

Besides that, as an editor author I'm not only interested in preventing
default action of features I don't want. I also want to hide them - remove
them from browser UI like context menus, menu bar, or other widgets like
special toolbar appearing over contenteditable on iOS. This makes the
situation which spec has to describe much more complex. That's why I think
it's better to focus on basics (
http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0918.html)
than on trying to make specification for every feature that was introduced
in any engine in any away.

-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer


Re: [editing] CommandEvent and contentEditable=minimal Explainer

2014-06-16 Thread Julie Parent
I certainly understand the concern that it would be impossible to properly
catch and cancel all events.  But I think that is somewhat the point - it
forces browser vendors to get these parts right.  All changes to an
editable dom must fire an event before the modifications are made, and must
be cancelable. Further, I'd say that if the number of events you would need
to preventDefault on grows larger than selection, command, and maybe
clipboard then that implies that we are not building the right APIs.


On Sun, Jun 15, 2014 at 11:49 AM, Piotr Koszuliński 
p.koszulin...@cksource.com wrote:


 On Sun, Jun 15, 2014 at 5:15 AM, Olivier F teleclim...@gmail.com wrote:


 On Fri, Jun 13, 2014 at 11:37 AM, Ben Peters ben.pet...@microsoft.com
 wrote:

 On Fri, Jun 13, 2014 at 1:01 AM, Ryosuke Niwa rn...@apple.com wrote:
  On Jun 12, 2014, at 5:07 PM, Olivier F teleclim...@gmail.com wrote:

  Imagine as well a situation where a UA creates a new way to paste
 content, and to prevent confusion with paste they decide to create a new
 ua-prefixed event uaMagicPaste. Now our end-users have a  way of pasting
 content into our editor's DOM without any intervention at all on our end,
 resulting in breakage and bugs.

 This is a good point. Registering for and calling preventDefault() on
 CommandEvent and BeforeSelectionChangeEvent will catch all new events in
 those categories, but ClipboardEvents must be listened to individually
 (Cut, Copy, Paste). We should consider whether we disallow new
 ClipboardEvent types or allow a generic ClipboardEvent listener, which
 would catch uaMagicPaste. I'll add a note to the Explainer for this.


 Yes, we could add ClipboardEvents and funnel all clipboard events through
 there, that would work.

 But I also noticed that Issue 3 was added: Do we need DragEvents too.
 And yes we do, good catch! It is totally possible to alter the DOM of a
 contentEditable by dragging something on top of it.

 I guess we can add DragEvents, but to me this illustrates why the
 practice of enumerating and capturing all current and future events to
 preventDefault them is not the right approach.

 For enumerate+preventDefault to work, every possible event that could
 change the cE's DOM has to fire correctly and cancel correctly. Every one.

 I can't help but to feel that there will always be something missing.
 Something we didn't think of in the spec, something the UA forgot to
 implement, some bug that prevents the event from being fully canceled, or
 some brand new interaction paradigm with its own event Class. Just one of
 these in effect in one major UA and editor devs all over are in pain.

 So long as enumerate+preventDefault is the only way for editor devs to
 control their editors, I'm concerned that there will be a constant source
 of difficulty trying to work around the leaks in the spec/ua/future, and
 that the end-user experience will continue to suffer as a result.


 I've got very similar feelings about all this. For years features have
 been randomly added to contentEditable=true and structuring them now seems
 for me as undoable. As I commented in [1] and [2] there are features
 related to contentEditable that do not fit in the CommandEvent and
 CommandQuery proposals very well. We agree that undo, clipboard and drag
 and drop interfaces have to be separated from commands. Why not other? Why
 all other features have to be pushed into commands section?

 If the commands' related APIs (I do not include very useful low level user
 intent events into that) and commands themselves will lack precision, then
 the only use that a cross-browser editor could make of them will be to
 disable everything. And we'll need to hope that we haven't disabled too
 much (e.g. clipboard events) or too few things, because imprecise spec will
 not clarify this.

 Less is better. Give us stable platform and we'll build great solutions on
 top of that. Make the platform unpredictable and we'll be fighting it the
 rest of our days.


 [1]
 http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0867.html
 [2]
 http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0876.html



 --
 Piotrek Koszuliński
 CKEditor JavaScript Lead Developer



Re: [editing] CommandEvent and contentEditable=minimal Explainer

2014-06-15 Thread Piotr Koszuliński
On Sun, Jun 15, 2014 at 5:15 AM, Olivier F teleclim...@gmail.com wrote:


 On Fri, Jun 13, 2014 at 11:37 AM, Ben Peters ben.pet...@microsoft.com
 wrote:

 On Fri, Jun 13, 2014 at 1:01 AM, Ryosuke Niwa rn...@apple.com wrote:
  On Jun 12, 2014, at 5:07 PM, Olivier F teleclim...@gmail.com wrote:

  Imagine as well a situation where a UA creates a new way to paste
 content, and to prevent confusion with paste they decide to create a new
 ua-prefixed event uaMagicPaste. Now our end-users have a  way of pasting
 content into our editor's DOM without any intervention at all on our end,
 resulting in breakage and bugs.

 This is a good point. Registering for and calling preventDefault() on
 CommandEvent and BeforeSelectionChangeEvent will catch all new events in
 those categories, but ClipboardEvents must be listened to individually
 (Cut, Copy, Paste). We should consider whether we disallow new
 ClipboardEvent types or allow a generic ClipboardEvent listener, which
 would catch uaMagicPaste. I'll add a note to the Explainer for this.


 Yes, we could add ClipboardEvents and funnel all clipboard events through
 there, that would work.

 But I also noticed that Issue 3 was added: Do we need DragEvents too.
 And yes we do, good catch! It is totally possible to alter the DOM of a
 contentEditable by dragging something on top of it.

 I guess we can add DragEvents, but to me this illustrates why the practice
 of enumerating and capturing all current and future events to
 preventDefault them is not the right approach.

 For enumerate+preventDefault to work, every possible event that could
 change the cE's DOM has to fire correctly and cancel correctly. Every one.

 I can't help but to feel that there will always be something missing.
 Something we didn't think of in the spec, something the UA forgot to
 implement, some bug that prevents the event from being fully canceled, or
 some brand new interaction paradigm with its own event Class. Just one of
 these in effect in one major UA and editor devs all over are in pain.

 So long as enumerate+preventDefault is the only way for editor devs to
 control their editors, I'm concerned that there will be a constant source
 of difficulty trying to work around the leaks in the spec/ua/future, and
 that the end-user experience will continue to suffer as a result.


I've got very similar feelings about all this. For years features have been
randomly added to contentEditable=true and structuring them now seems for
me as undoable. As I commented in [1] and [2] there are features related to
contentEditable that do not fit in the CommandEvent and CommandQuery
proposals very well. We agree that undo, clipboard and drag and drop
interfaces have to be separated from commands. Why not other? Why all other
features have to be pushed into commands section?

If the commands' related APIs (I do not include very useful low level user
intent events into that) and commands themselves will lack precision, then
the only use that a cross-browser editor could make of them will be to
disable everything. And we'll need to hope that we haven't disabled too
much (e.g. clipboard events) or too few things, because imprecise spec will
not clarify this.

Less is better. Give us stable platform and we'll build great solutions on
top of that. Make the platform unpredictable and we'll be fighting it the
rest of our days.


[1] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0867.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0876.html



-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer


Re: [editing] CommandEvent and contentEditable=minimal Explainer

2014-06-14 Thread Olivier F
On Fri, Jun 13, 2014 at 11:37 AM, Ben Peters ben.pet...@microsoft.com
wrote:

 On Fri, Jun 13, 2014 at 1:01 AM, Ryosuke Niwa rn...@apple.com wrote:
  On Jun 12, 2014, at 5:07 PM, Olivier F teleclim...@gmail.com wrote:

  Imagine as well a situation where a UA creates a new way to paste
 content, and to prevent confusion with paste they decide to create a new
 ua-prefixed event uaMagicPaste. Now our end-users have a  way of pasting
 content into our editor's DOM without any intervention at all on our end,
 resulting in breakage and bugs.

 This is a good point. Registering for and calling preventDefault() on
 CommandEvent and BeforeSelectionChangeEvent will catch all new events in
 those categories, but ClipboardEvents must be listened to individually
 (Cut, Copy, Paste). We should consider whether we disallow new
 ClipboardEvent types or allow a generic ClipboardEvent listener, which
 would catch uaMagicPaste. I'll add a note to the Explainer for this.


Yes, we could add ClipboardEvents and funnel all clipboard events through
there, that would work.

But I also noticed that Issue 3 was added: Do we need DragEvents too. And
yes we do, good catch! It is totally possible to alter the DOM of a
contentEditable by dragging something on top of it.

I guess we can add DragEvents, but to me this illustrates why the practice
of enumerating and capturing all current and future events to
preventDefault them is not the right approach.

For enumerate+preventDefault to work, every possible event that could
change the cE's DOM has to fire correctly and cancel correctly. Every one.

I can't help but to feel that there will always be something missing.
Something we didn't think of in the spec, something the UA forgot to
implement, some bug that prevents the event from being fully canceled, or
some brand new interaction paradigm with its own event Class. Just one of
these in effect in one major UA and editor devs all over are in pain.

So long as enumerate+preventDefault is the only way for editor devs to
control their editors, I'm concerned that there will be a constant source
of difficulty trying to work around the leaks in the spec/ua/future, and
that the end-user experience will continue to suffer as a result.


Re: [editing] CommandEvent and contentEditable=minimal Explainer

2014-06-13 Thread Ryosuke Niwa

On Jun 12, 2014, at 5:07 PM, Olivier F teleclim...@gmail.com wrote:

 I have been reading this and have a comment:
 http://w3c.github.io/editing-explainer/commands-explainer.html
 
 Issue 11: We may not need contentEditable=minimal. The same thing can be 
 accomplished by listening for commands and calling preventDefault on all of 
 them.
 
 I think we need contentEditable=minimal even if it is theoretically possible 
 to listen to all commands and preventDefault on them.
 
 Listening to all events and preventing their defaults has the following 
 implications:
 - All CommandEvents and other things that can modify the state of the 
 contents in our cE actually do fire events.
 - We are actually able to enumerate all events that could potentially modify 
 the state of our contentEditable.
 - All of these events can be preventDefaulted.
 
 Given the transient nature of specs, implementations, and bugs I have a hard 
 time believing that the theory that we can just listen to everything and 
 prevent defaults has merit in practice. 
 
 One can easily imagine that some features provided by the UA won't fire 
 events. Or, no need to imagine: just look at undo called from context menu.
 
 Imagine as well a situation where a UA creates a new way to paste content, 
 and to prevent confusion with paste they decide to create a new ua-prefixed 
 event uaMagicPaste. Now our end-users have a  way of pasting content into 
 our editor's DOM without any intervention at all on our end, resulting in 
 breakage and bugs.
 
 In practice, if we are left with the burden of listening to all events and 
 preventing defaults we are left in very much the same situation we're trying 
 to get away from.

I don't have a strong opinion either way.  However, can't you just whitelist 
the list of commands you allow and cancel everything else instead for this 
specific case?  I guess you're concerned that it'll make things worse in some 
cases (e.g. new builtin browser features maybe disabled)?

- R. Niwa


Re: [editing] CommandEvent and contentEditable=minimal Explainer

2014-06-12 Thread Olivier F
I have been reading this and have a comment:
http://w3c.github.io/editing-explainer/commands-explainer.html

Issue 11: We may not need contentEditable=minimal. The same thing can be
accomplished by listening for commands and calling preventDefault on all of
them.

I think we need contentEditable=minimal even if it is theoretically
possible to listen to all commands and preventDefault on them.

Listening to all events and preventing their defaults has the following
implications:
- All CommandEvents and other things that can modify the state of the
contents in our cE actually do fire events.
- We are actually able to enumerate all events that could potentially
modify the state of our contentEditable.
- All of these events can be preventDefaulted.

Given the transient nature of specs, implementations, and bugs I have a
hard time believing that the theory that we can just listen to everything
and prevent defaults has merit in practice.

One can easily imagine that some features provided by the UA won't fire
events. Or, no need to imagine: just look at undo called from context
menu.

Imagine as well a situation where a UA creates a new way to paste content,
and to prevent confusion with paste they decide to create a new
ua-prefixed event uaMagicPaste. Now our end-users have a  way of pasting
content into our editor's DOM without any intervention at all on our end,
resulting in breakage and bugs.

In practice, if we are left with the burden of listening to all events and
preventing defaults we are left in very much the same situation we're
trying to get away from.

If cE=min were spec'd to be an editable surface that had everything (or
almost) off by default, including future features, then these kinds of
surprises wouldn't happen. As developers we'd much rather implement new
APIs when we feel we can, rather than having to scramble to preventDefault
on new features when they appear on our end-user's browsers one morning.

Thank-you for considering this.

- Oliver Forget


Re: [editing] CommandEvent and contentEditable=minimal Explainer

2014-06-06 Thread Robin Berjon

On 28/05/2014 01:39 , Julie Parent wrote:

The discussion of which minimal default handling to include with
contenteditable=minimal makes me wonder if contentEditable=minimal
is necessary at all.  It quickly becomes a can of worms of *which*
default handling should be included, and it seems likely to not satisfy
every use case no matter which decisions are made.  However, minimal
is proposed as a building block because currently, disabling all default
functionality of contentEditable=true is difficult/impossible.  But
with CommandEvents, shouldn't contentEditable=minimal be equivalent to:

// Let editRegion be div contentEditable id='editRegion'

var editRegion = document.getElementById(editRegion);
editRegion.addEventListener(command, handleCommand);
function handleCommand(evt){
   evt.preventDefault();
}

No default actions would be taken, but selection events would still fire
and be handled.  There would be no ambiguity.  If implementing
contentEditable=minimal on top of CommandEvents could just be a few
lines of code, why complicate things by spec'ing another property?


I like the simplicity of this approach, but I have some concerns.

As Travis points out, this implies that all events have to be 
cancellable in this context. This can lead to problems (like we had with 
mutations), it can also have performance implications.


Another aspect that may be problematic is the case of UAs that provide a 
UI (like Safari Mobile) whenever they see contentEditable. I was hoping 
that contentEditable=minimal would serve as a sanity flag not to include 
that. In the above it's not possible.


I am not sure that we can have this work properly without specifying the 
default behaviour, which as we all know is a terrible mess. If you don't 
have reliable default behaviour, can you really rely on the browser to 
DTRT for the cases you don't wish to handle? Won't you end up having to 
use a library anyway?


Again, I'm all for the simplicity; I'm just worried about the snoring 
dragon.


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



Re: [editing] CommandEvent and contentEditable=minimal Explainer

2014-06-06 Thread Ryosuke Niwa

On Jun 6, 2014, at 6:27 AM, Robin Berjon ro...@w3.org wrote:

 On 28/05/2014 01:39 , Julie Parent wrote:
 The discussion of which minimal default handling to include with
 contenteditable=minimal makes me wonder if contentEditable=minimal
 is necessary at all.  It quickly becomes a can of worms of *which*
 default handling should be included, and it seems likely to not satisfy
 every use case no matter which decisions are made.  However, minimal
 is proposed as a building block because currently, disabling all default
 functionality of contentEditable=true is difficult/impossible.  But
 with CommandEvents, shouldn't contentEditable=minimal be equivalent to:
 
 // Let editRegion be div contentEditable id='editRegion'
 
 var editRegion = document.getElementById(editRegion);
 editRegion.addEventListener(command, handleCommand);
 function handleCommand(evt){
   evt.preventDefault();
 }
 
 No default actions would be taken, but selection events would still fire
 and be handled.  There would be no ambiguity.  If implementing
 contentEditable=minimal on top of CommandEvents could just be a few
 lines of code, why complicate things by spec'ing another property?
 
 I like the simplicity of this approach, but I have some concerns.
 
 As Travis points out, this implies that all events have to be cancellable in 
 this context. This can lead to problems (like we had with mutations), it can 
 also have performance implications.

I don't think it will cause problems like mutation events as long as we make 
execCommand non-reentrant.  Asking whether each node can be removed or inserted 
could cause serious problems due to other precondition checks having been 
perfumed already at that point, but firing another event before running an 
execCommand implementation is easy  safe since we already fire other events 
like beforeinput.

 Another aspect that may be problematic is the case of UAs that provide a UI 
 (like Safari Mobile) whenever they see contentEditable. I was hoping that 
 contentEditable=minimal would serve as a sanity flag not to include that. In 
 the above it's not possible.

This makes me think that what we need is a way to hook selection  default 
editing behaviors optimally.  However, we need to need a way to tell UA that an 
element is editable for assistive technology.  Ideally, we don't need to rely 
on ARIA role for that.

- R. Niwa




Re: [editing] CommandEvent and contentEditable=minimal Explainer

2014-05-31 Thread Ryosuke Niwa
I agree it's better to let authors define what behavior they want from UA 
instead of defining the set of behaviors ourselves.

Furthermore, I'd argue that we should separately have a mode where scripts 
would get intention events but UA wouldn't enact any builtin editing commands 
as default actions.  This is  useful for non-text editing applications such as 
drawing and presentation apps.

- R. Niwa

 On May 28, 2014, at 1:39 PM, Ben Peters ben.pet...@microsoft.com wrote:
 
 Great idea! If Intention Events (Clipboard, Selection, Command) cover all of 
 the editing operations that a site would want to handle themselves, we don’t 
 need CE Min as a feature, only a concept that can achieved with 
 preventDefault().
  
 From: Julie Parent [mailto:jpar...@gmail.com] 
 Sent: Tuesday, May 27, 2014 4:40 PM
 To: Ben Peters
 Cc: public-webapps@w3.org
 Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer
  
 The discussion of which minimal default handling to include with 
 contenteditable=minimal makes me wonder if contentEditable=minimal is 
 necessary at all.  It quickly becomes a can of worms of *which* default 
 handling should be included, and it seems likely to not satisfy every use 
 case no matter which decisions are made.  However, minimal is proposed as a 
 building block because currently, disabling all default functionality of 
 contentEditable=true is difficult/impossible.  But with CommandEvents, 
 shouldn't contentEditable=minimal be equivalent to:
  
 // Let editRegion be div contentEditable id='editRegion'
  
 var editRegion = document.getElementById(editRegion);
 editRegion.addEventListener(command, handleCommand);
 function handleCommand(evt){
   evt.preventDefault();
 }
  
 No default actions would be taken, but selection events would still fire and 
 be handled.  There would be no ambiguity.  If implementing 
 contentEditable=minimal on top of CommandEvents could just be a few lines 
 of code, why complicate things by spec'ing another property?
  
 Then, if someone wants a region that just does basic text input, then they 
 simply allow it:
 function handleCommand(evt){
  switch (evt.commandType){
case 'insertText':
  // Let the browser do text insertion
  break;
default:
  // Prevent all other magic
  evt.preventDefault();
 }
  
 This hedges on the fact that CommandEvents would capture ALL the cases that 
 contentEditable currently handles, and that the event would fire BEFORE the 
 dom is modified, and that calling preventDefault would cancel the event, but 
 isn't that a goal of this design anyway?
  
 Julie
  
 -- Forwarded message --
 From: Ben Peters ben.pet...@microsoft.com
 Date: Thu, May 22, 2014 at 4:56 PM
 Subject: [editing] CommandEvent and contentEditable=minimal Explainer
 To: public-webapps@w3.org public-webapps@w3.org
 
 
 I have completed a first-draft explainer document [1], taking the generous 
 feedback of many of you into account. There are 6 open issues on the document 
 currently, and I'm sure there are others that I have missed. It would be 
 great to know if this is heading in in the right direction.
 
 My vision is to use this a non-normative Explainer, and create 2 normative 
 specs to go with it. The specs for contentEditable=minimal and CommandEvent 
 should have first-drafts next week.
 
 Thanks!
 Ben
 
 [1] http://benjamp.github.io/commands-explainer.htm
 
  


RE: [editing] CommandEvent and contentEditable=minimal Explainer

2014-05-28 Thread Ben Peters
Great idea! If Intention Events (Clipboard, Selection, Command) cover all of 
the editing operations that a site would want to handle themselves, we don’t 
need CE Min as a feature, only a concept that can achieved with 
preventDefault().

From: Julie Parent [mailto:jpar...@gmail.com]
Sent: Tuesday, May 27, 2014 4:40 PM
To: Ben Peters
Cc: public-webapps@w3.org
Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer

The discussion of which minimal default handling to include with 
contenteditable=minimal makes me wonder if contentEditable=minimal is 
necessary at all.  It quickly becomes a can of worms of *which* default 
handling should be included, and it seems likely to not satisfy every use case 
no matter which decisions are made.  However, minimal is proposed as a 
building block because currently, disabling all default functionality of 
contentEditable=true is difficult/impossible.  But with CommandEvents, 
shouldn't contentEditable=minimal be equivalent to:

// Let editRegion be div contentEditable id='editRegion'

var editRegion = document.getElementById(editRegion);
editRegion.addEventListener(command, handleCommand);
function handleCommand(evt){
  evt.preventDefault();
}

No default actions would be taken, but selection events would still fire and be 
handled.  There would be no ambiguity.  If implementing 
contentEditable=minimal on top of CommandEvents could just be a few lines of 
code, why complicate things by spec'ing another property?

Then, if someone wants a region that just does basic text input, then they 
simply allow it:
function handleCommand(evt){
 switch (evt.commandType){
   case 'insertText':
 // Let the browser do text insertion
 break;
   default:
 // Prevent all other magic
 evt.preventDefault();
}

This hedges on the fact that CommandEvents would capture ALL the cases that 
contentEditable currently handles, and that the event would fire BEFORE the dom 
is modified, and that calling preventDefault would cancel the event, but isn't 
that a goal of this design anyway?

Julie

-- Forwarded message --
From: Ben Peters ben.pet...@microsoft.commailto:ben.pet...@microsoft.com
Date: Thu, May 22, 2014 at 4:56 PM
Subject: [editing] CommandEvent and contentEditable=minimal Explainer
To: public-webapps@w3.orgmailto:public-webapps@w3.org 
public-webapps@w3.orgmailto:public-webapps@w3.org


I have completed a first-draft explainer document [1], taking the generous 
feedback of many of you into account. There are 6 open issues on the document 
currently, and I'm sure there are others that I have missed. It would be great 
to know if this is heading in in the right direction.

My vision is to use this a non-normative Explainer, and create 2 normative 
specs to go with it. The specs for contentEditable=minimal and CommandEvent 
should have first-drafts next week.

Thanks!
Ben

[1] http://benjamp.github.io/commands-explainer.htm



RE: [editing] CommandEvent and contentEditable=minimal Explainer

2014-05-28 Thread Travis Leithead
Be careful with having events fire before the DOM is updated—at a minimum 
you’ll want to consider whether you will allow dangerous situations like the 
legacy MutationEvents could cause (start a change - pre-change notification - 
make another change - pre-change notification … unexpected things can happen 
(can be especially challenging to implement securely).

HTML5’s focus event model nicely prevents these recursions from looping. I’ve 
proposed a similar mitigation for the “beforeinput” event of DOM Level 3 
Events: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25683

Seems like the Intention Events, if firing before the change is committed, 
might want a similar mitigation strategy.

From: Ben Peters [mailto:ben.pet...@microsoft.com]
Sent: Wednesday, May 28, 2014 1:40 PM
To: Julie Parent
Cc: public-webapps@w3.org
Subject: RE: [editing] CommandEvent and contentEditable=minimal Explainer

Great idea! If Intention Events (Clipboard, Selection, Command) cover all of 
the editing operations that a site would want to handle themselves, we don’t 
need CE Min as a feature, only a concept that can achieved with 
preventDefault().

From: Julie Parent [mailto:jpar...@gmail.com]
Sent: Tuesday, May 27, 2014 4:40 PM
To: Ben Peters
Cc: public-webapps@w3.orgmailto:public-webapps@w3.org
Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer

The discussion of which minimal default handling to include with 
contenteditable=minimal makes me wonder if contentEditable=minimal is 
necessary at all.  It quickly becomes a can of worms of *which* default 
handling should be included, and it seems likely to not satisfy every use case 
no matter which decisions are made.  However, minimal is proposed as a 
building block because currently, disabling all default functionality of 
contentEditable=true is difficult/impossible.  But with CommandEvents, 
shouldn't contentEditable=minimal be equivalent to:

// Let editRegion be div contentEditable id='editRegion'

var editRegion = document.getElementById(editRegion);
editRegion.addEventListener(command, handleCommand);
function handleCommand(evt){
  evt.preventDefault();
}

No default actions would be taken, but selection events would still fire and be 
handled.  There would be no ambiguity.  If implementing 
contentEditable=minimal on top of CommandEvents could just be a few lines of 
code, why complicate things by spec'ing another property?

Then, if someone wants a region that just does basic text input, then they 
simply allow it:
function handleCommand(evt){
 switch (evt.commandType){
   case 'insertText':
 // Let the browser do text insertion
 break;
   default:
 // Prevent all other magic
 evt.preventDefault();
}

This hedges on the fact that CommandEvents would capture ALL the cases that 
contentEditable currently handles, and that the event would fire BEFORE the dom 
is modified, and that calling preventDefault would cancel the event, but isn't 
that a goal of this design anyway?

Julie

-- Forwarded message --
From: Ben Peters ben.pet...@microsoft.commailto:ben.pet...@microsoft.com
Date: Thu, May 22, 2014 at 4:56 PM
Subject: [editing] CommandEvent and contentEditable=minimal Explainer
To: public-webapps@w3.orgmailto:public-webapps@w3.org 
public-webapps@w3.orgmailto:public-webapps@w3.org


I have completed a first-draft explainer document [1], taking the generous 
feedback of many of you into account. There are 6 open issues on the document 
currently, and I'm sure there are others that I have missed. It would be great 
to know if this is heading in in the right direction.

My vision is to use this a non-normative Explainer, and create 2 normative 
specs to go with it. The specs for contentEditable=minimal and CommandEvent 
should have first-drafts next week.

Thanks!
Ben

[1] http://benjamp.github.io/commands-explainer.htm



Re: [editing] CommandEvent and contentEditable=minimal Explainer

2014-05-28 Thread Piotr Koszuliński
But what is the default behaviour then? What will we be preventing?
There's no accepted specification for current contentEditable=true AFAIK,
so I thought that the goal of contentEditable=minimal is to avoid the need
to write a specification for contentEditable=true. Otherwise, developers
may demand from browser vendors that they fix their contentEditable=true
implementations and I don't think that anyone wants that. Why not forget
about contentEditable=true, make it deprecated and create specification
only for algorithms needed by contentEditable=minimal and all required
command events?


On Wed, May 28, 2014 at 10:39 PM, Ben Peters ben.pet...@microsoft.comwrote:

  Great idea! If Intention Events (Clipboard, Selection, Command) cover
 all of the editing operations that a site would want to handle themselves,
 we don’t need CE Min as a feature, only a concept that can achieved with
 preventDefault().



 *From:* Julie Parent [mailto:jpar...@gmail.com]
 *Sent:* Tuesday, May 27, 2014 4:40 PM
 *To:* Ben Peters
 *Cc:* public-webapps@w3.org
 *Subject:* Re: [editing] CommandEvent and contentEditable=minimal
 Explainer



 The discussion of which minimal default handling to include with
 contenteditable=minimal makes me wonder if contentEditable=minimal is
 necessary at all.  It quickly becomes a can of worms of *which* default
 handling should be included, and it seems likely to not satisfy every use
 case no matter which decisions are made.  However, minimal is proposed as
 a building block because currently, disabling all default functionality of
 contentEditable=true is difficult/impossible.  But with CommandEvents,
 shouldn't contentEditable=minimal be equivalent to:



 // Let editRegion be div contentEditable id='editRegion'



 var editRegion = document.getElementById(editRegion);

 editRegion.addEventListener(command, handleCommand);

 function handleCommand(evt){

   evt.preventDefault();

 }



 No default actions would be taken, but selection events would still fire
 and be handled.  There would be no ambiguity.  If implementing
 contentEditable=minimal on top of CommandEvents could just be a few lines
 of code, why complicate things by spec'ing another property?



 Then, if someone wants a region that just does basic text input, then they
 simply allow it:

 function handleCommand(evt){

  switch (evt.commandType){

case 'insertText':

  // Let the browser do text insertion

  break;

default:

  // Prevent all other magic

  evt.preventDefault();

 }



 This hedges on the fact that CommandEvents would capture ALL the cases
 that contentEditable currently handles, and that the event would fire
 BEFORE the dom is modified, and that calling preventDefault would cancel
 the event, but isn't that a goal of this design anyway?



 Julie



 -- Forwarded message --
 From: *Ben Peters* ben.pet...@microsoft.com
 Date: Thu, May 22, 2014 at 4:56 PM
 Subject: [editing] CommandEvent and contentEditable=minimal Explainer
 To: public-webapps@w3.org public-webapps@w3.org


 I have completed a first-draft explainer document [1], taking the generous
 feedback of many of you into account. There are 6 open issues on the
 document currently, and I'm sure there are others that I have missed. It
 would be great to know if this is heading in in the right direction.

 My vision is to use this a non-normative Explainer, and create 2 normative
 specs to go with it. The specs for contentEditable=minimal and CommandEvent
 should have first-drafts next week.

 Thanks!
 Ben

 [1] http://benjamp.github.io/commands-explainer.htm






-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer


RE: [editing] CommandEvent and contentEditable=minimal Explainer

2014-05-28 Thread Ben Peters
I don’t think we need to specify the default behavior. We can instead just say 
that all editing behaviors must fire Intention events that are cancellable. Any 
events that are already defined (like Clipboard) will continue to work, and 
others should fire CommandEvents as necessary.

We will likely need to have a list of well-known Command Events (like bold, 
undo, etc) just so we can have a shape for the related CommandData object, but 
we don’t need to specify the default behavior of those events.

From: Piotr Koszuliński [mailto:p.koszulin...@cksource.com]
Sent: Wednesday, May 28, 2014 2:40 PM
To: Ben Peters
Cc: Julie Parent; public-webapps@w3.org
Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer

But what is the default behaviour then? What will we be preventing? There's 
no accepted specification for current contentEditable=true AFAIK, so I thought 
that the goal of contentEditable=minimal is to avoid the need to write a 
specification for contentEditable=true. Otherwise, developers may demand from 
browser vendors that they fix their contentEditable=true implementations and I 
don't think that anyone wants that. Why not forget about contentEditable=true, 
make it deprecated and create specification only for algorithms needed by 
contentEditable=minimal and all required command events?

On Wed, May 28, 2014 at 10:39 PM, Ben Peters 
ben.pet...@microsoft.commailto:ben.pet...@microsoft.com wrote:
Great idea! If Intention Events (Clipboard, Selection, Command) cover all of 
the editing operations that a site would want to handle themselves, we don’t 
need CE Min as a feature, only a concept that can achieved with 
preventDefault().

From: Julie Parent [mailto:jpar...@gmail.commailto:jpar...@gmail.com]
Sent: Tuesday, May 27, 2014 4:40 PM
To: Ben Peters
Cc: public-webapps@w3.orgmailto:public-webapps@w3.org
Subject: Re: [editing] CommandEvent and contentEditable=minimal Explainer

The discussion of which minimal default handling to include with 
contenteditable=minimal makes me wonder if contentEditable=minimal is 
necessary at all.  It quickly becomes a can of worms of *which* default 
handling should be included, and it seems likely to not satisfy every use case 
no matter which decisions are made.  However, minimal is proposed as a 
building block because currently, disabling all default functionality of 
contentEditable=true is difficult/impossible.  But with CommandEvents, 
shouldn't contentEditable=minimal be equivalent to:

// Let editRegion be div contentEditable id='editRegion'

var editRegion = document.getElementById(editRegion);
editRegion.addEventListener(command, handleCommand);
function handleCommand(evt){
  evt.preventDefault();
}

No default actions would be taken, but selection events would still fire and be 
handled.  There would be no ambiguity.  If implementing 
contentEditable=minimal on top of CommandEvents could just be a few lines of 
code, why complicate things by spec'ing another property?

Then, if someone wants a region that just does basic text input, then they 
simply allow it:
function handleCommand(evt){
 switch (evt.commandType){
   case 'insertText':
 // Let the browser do text insertion
 break;
   default:
 // Prevent all other magic
 evt.preventDefault();
}

This hedges on the fact that CommandEvents would capture ALL the cases that 
contentEditable currently handles, and that the event would fire BEFORE the dom 
is modified, and that calling preventDefault would cancel the event, but isn't 
that a goal of this design anyway?

Julie

-- Forwarded message --
From: Ben Peters ben.pet...@microsoft.commailto:ben.pet...@microsoft.com
Date: Thu, May 22, 2014 at 4:56 PM
Subject: [editing] CommandEvent and contentEditable=minimal Explainer
To: public-webapps@w3.orgmailto:public-webapps@w3.org 
public-webapps@w3.orgmailto:public-webapps@w3.org


I have completed a first-draft explainer document [1], taking the generous 
feedback of many of you into account. There are 6 open issues on the document 
currently, and I'm sure there are others that I have missed. It would be great 
to know if this is heading in in the right direction.

My vision is to use this a non-normative Explainer, and create 2 normative 
specs to go with it. The specs for contentEditable=minimal and CommandEvent 
should have first-drafts next week.

Thanks!
Ben

[1] http://benjamp.github.io/commands-explainer.htm




--
Piotrek Koszuliński
CKEditor JavaScript Lead Developer


[editing] CommandEvent and contentEditable=minimal Explainer

2014-05-22 Thread Ben Peters
I have completed a first-draft explainer document [1], taking the generous 
feedback of many of you into account. There are 6 open issues on the document 
currently, and I'm sure there are others that I have missed. It would be great 
to know if this is heading in in the right direction.

My vision is to use this a non-normative Explainer, and create 2 normative 
specs to go with it. The specs for contentEditable=minimal and CommandEvent 
should have first-drafts next week.

Thanks!
Ben

[1] http://benjamp.github.io/commands-explainer.htm