On Fri, May 29, 2015 at 6:25 PM, Florian Rivoal <florian@rivoal.net> wrote: > > Moreover, if the were concerned with contentEditable=typing (See [2] if > you're not familiar) rather than contentEditable=true, the browser would do > nothing in any of these cases, and this would be up to the js > implementation of the editor to decide what to do, so we can spec this even > less. > There have been various ideas lately about what cE=typing is going to be. The concept that I thought there was consensus about until recently was that it was going to be only a spec to give access to certain primitives for JS editor developers to built their editors on top of. So on that level I think you are right, there wouldn't be that much to spec. However, the initial plan was that cE=typing would only be the first stage, and that first editing modules would be developed on top of it in cooperation with JS editor developers that would first be implemented in JS as polyfills on top of the primitives made available through cE=typing. These could be specs for everything from the movement of the caret to advanced features such as merging of paragraph, collective content editing, richtext features for marking parts of the text as bold, etc. . In those specs it would seem that one should add specifications about how to handle this. Note though, that the discussion on Github recently has gone more in the direction of not giving cE=typing access to the the primitives and instead make a more extensive selection API that takes into consideration all the various use cases. -- Johannes Wilm Fidus Writer http://www.fiduswriter.org
Received on Thursday, 4 June 2015 18:50:44 UTC