- From: Frederico Knabben <f.knabben@cksource.com>
- Date: Mon, 8 Sep 2014 18:05:30 +0200
- To: Ben Peters <Ben.Peters@microsoft.com>
- Cc: "public-editing-tf@w3.org" <public-editing-tf@w3.org>, Julie Parent <jparent@gmail.com>, "public-indie-ui@w3.org" <public-indie-ui@w3.org>, public-webapps <public-webapps@w3.org>
- Message-ID: <A585EF05C00B4348AA36BF8B43C98B39@cksource.com>
Pretty good docs, Ben. I have comments mostly about Issue 2 (http://w3c.github.io/editing-explainer/#h_issue_2). As long as actions are well documented, browsers can provide defaults that will fit 90% of the *good quality* content creation requirements out there. Additionally just selection is not enough to make content editable, so contenteditable=“minimal” would have no sense for the eyes of those not participating in this group. IMHO, the following are the “minimal” features that it should provide: - Selection: UI (e.g. caret), creation (e.g. mouse) and modifications (e.g. arrows) - Focus (probably part of Selection, but it’s so hard to make it right that I’m listing it here to not stay forgotten) - Input Text (typing) - Insert New Line - Delete / Backspace - Clipboard / DnD - Undo / Redo All the above should be paired with the proper Intention events so preventDefault and customizations can happen. Once we agree on what contenteditable=“minimal” should do, the next step would be writing specs for each of the above points, in very deep details, including all possible patterns and cases (hopefully unit tests). This is to help browsers’ adoption, easier implementation and guaranteeing a common behavior everywhere, which would require less customizations to happen. The goal here is fixing editing, not disabling it altogether. Otherwise Issue 5 (http://w3c.github.io/editing-explainer/#h_issue_5) makes total sense and editing will, by default, stay broken. -- Frederico Knabben CKEditor Project Lead and CKSource Owner -- CKSource - http://cksource.com -- Follow us 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) On Friday, 5 September 2014 at 23:04, Ben Peters wrote: > There is now an Editing Explainer [1] and a User Intentions Explainer [2], which should help scope the problems and help us drive forward on both areas. I haven’t done much to fine tune them yet, but please let me know if you have feedback on this split from the initial Commands Explainer document. Thanks! > > [1] http://w3c.github.io/editing-explainer/ > [2] http://w3c.github.io/editing-explainer/commands-explainer.html > > On Mon, Aug 11, 2014 at 5:23 PM, Ben Peters <Ben.Peters@microsoft.com (mailto:Ben.Peters@microsoft.com)> wrote: > > > > I agree with this. We should have a single 'shape' for these events and shared terminology. > > > > I think trying to solve all of the problems in one complete spec would be too complex, but if we use an Intentions Explainer to divide the problem into manageable pieces, we can continue on our trajectory of creating these events for Selection, Clipboard, Drag and Drop, Input (aka Editing), and perhaps other user interactions. Are there objections to this approach? If not, I will begin to adapt the Commands Explainer into a more generic Intentions Explainer. > >
Received on Monday, 8 September 2014 16:06:03 UTC