Re: [editing] Responsive Input Terminology
At a frist glance I almost agreed with you, Björn. Note though that, in terms of output, these events we’re talking about are adapted to the input method used to generate them. We’re not any more talking about device specific events, like “mouse click” or “key press”. One of these events could be “insert character” and the way it is triggered vary depending on device, platform, ATs, etc. This makes me agree that Responsive Input Events is a great choice for it. -- 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, 12 December 2014 at 01:17, Bjoern Hoehrmann wrote: * Ben Peters wrote: There has been a lot of debate [1][2] about the correct name for device independent events [3] as a concept*. We have considered Intention Events, Command Events, and Action Events among others. I believe we now have a good name for them- Responsive Input Events. The reason for this name is that it is the corollary to Responsive Layout: for input instead of output. Together these two concepts can help form the basis of Responsive Design going forward. Responsive Layout responds to geometric changes in the environment or, if you will, adapts to different geometric environments. I do not really see how device independent events respond or adapt. They are independent of their environment already. Instead of Responsive (Input Events), it is possible that some people read it as (Responsive Input) Events, but I do not really see how the input responds or adapts either. The input is what it is, and does not really interact with anything on its own. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/
Re: [editing] Responsive Input Terminology
On Friday, 12 December 2014 at 14:40, Simon Pieters wrote: How about device-independent events? Aren’t we missing what kinds of events we’re talking about? We would just know that those events are device-independent. So far we’ve been talking about “input” events. If this is still the case, this should be clear. Option 1: You agree that because we’re talking about “device”, “input” is an implicit information. I’m unsure. Option 2: Device-Independent Input Events (dii-events then). Option 3: We’re talking about a totally new group of events, which don’t include only input, but everything that is “device-independent”. Then use cases should be listed. -- 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)
Re: User Intentions Explainer (was: List of Intentions)
On Thursday, 11 September 2014 at 17:38, Ryosuke Niwa wrote: On Sep 9, 2014, at 6:31 AM, Johannes Wilm johan...@fiduswriter.org (mailto:johan...@fiduswriter.org) wrote: Absolutely. if this division means we can get into a saner place faster (and with a higher likelihood that it will actually happen) then I am all for it. Of course the long-term future of the web should be taken into consideration as well, and as I understand it, this could be part of the second part then. On Tue, Sep 9, 2014 at 1:28 PM, Piotr Koszuliński p.koszulin...@cksource.com (mailto:p.koszulin...@cksource.com) wrote: I'm not sure if I remember correctly, but I believe that after long discussions we left the question what should contenteditable=minimal be? unanswered. First the intention events lists should be created, so we can see what needs to be handled. And this is what Ben Peters is working on. Still we may also take in consideration that there are limited resources available for working on the specs. Therefore the whole work could be separated into two *independent* topics: 1. Intention events + execCommand. 2. contenteditable=“minimal” That's what I was proposing as well - to have the base (which consists mainly of fixed selection API and intention events) ready as soon as possible, so hopefully browser makers can start implementing it and then we, editor makers, can start using it. This part will already improve the current situation a lot, but it's itself pretty hard as we can see. Then, if anyone will be still interested, a specification for default browser's actions can be created. It's a huge task and there are a lot of controversial topics like the famous delete/backspace behaviour when merging blocks and that's why I would not recommend starting these discussions right now. Could you clarify what use cases could be addressed by implementing 1? Since I consider the lack of concrete use cases to be one of the reasons the last few iterations/attempts to implement something like these have failed, I would really like to have a list of concrete use cases that are to be addressed by each specification listed above. - R. Niwa “1” is the basis for being able to replace browser’s (currently broken) default behavior for user actions. It would guarantee that all behavior can be preventDefault()ed and also provide additional information about the user intentions so actions can be better understood, paired with a more accurate behavior.
Re: User Intentions Explainer (was: List of Intentions)
On Monday, 8 September 2014 at 20:55, Johannes Wilm wrote: If we include deletion/backspace and input text, that will then also mean merging of paragraphs (and other nodes) when the caret is at the beginning of a second paragraph and the backspace key is being hit? Definitely. It’s all about that. About writing specs that will tell how these cases should be handled, possibly coupled with ready to use unit tests. To me it's fine if inputting text/backspace is being included, as long as browser makers believe they will have the time and resources to fix the actual text editing part. That to me seems to be the most broken thing about the whole thing currently. If they on the other hand say they have no time for any of this (as not having fixed bugs in this area for some years might indicate) I would be OK with them leaving the input/deletion/undo history part out. I don’t think that browsers having time/will for it today is a good argumentation for not doing it. The specs have a critical and noble scope, of serving as reference for the future of the web. We’re talking about the future after all. For instance, we can also predict that, if browser for any reason will not implement the specs, a js solution could take place, normalizing the behavior of browsers based on the specs. As long as Intention events will take place, this would be certainly doable.
Re: User Intentions Explainer (was: List of Intentions)
On Tuesday, 9 September 2014 at 11:13, Frederico Knabben wrote: I don’t think that browsers having time/will for it today is a good argumentation for not doing it. The specs have a critical and noble scope, of serving as reference for the future of the web. We’re talking about the future after all. Still we may also take in consideration that there are limited resources available for working on the specs. Therefore the whole work could be separated into two *independent* topics: 1. Intention events + execCommand. 2. contenteditable=“minimal” “1” should be concluded asap, because it is the foundation for the success of “2”. It is also compatible with the current contenteditable=“true”, so it should enable sites/frameworks to fix the current status of things. “2” is the ideal world. Something that would require much more energy to get done right. Still in the beginning, there should be an agreement on what’s in and what’s out. Following that, several specs can get started, each one defining the default behavior we want for each of the features we want “minimal” to have. The first ofc, would be “Selection” (and “Focus”!).
Re: User Intentions Explainer (was: List of Intentions)
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.pet...@microsoft.com (mailto:ben.pet...@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.
