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 <johannes@fiduswriter.org (mailto:johannes@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.koszulinski@cksource.com (mailto:p.koszulinski@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.