As a matter of fact, we're involved in the W3C's Editing Task Force since the beginning. Me and Fred (the author of the blog post) were on the first meeting in Berlin back in 2014 and I've been in Paris the year after. Unfortunately, since then many meetings were held outside Europe and they were also concerned with more technical parts of the spec(s) to which it's harder for us to contribute. However, we still try to contribute as much as we can... but I have to say it's tough.
The problem is that this topic is vast and extremely complicated. Rich-text editing itself is complicated, but when you start considering all the languages (e.g. RTL mixed with LTR, IME), different types of devices and interaction models (software keyboards, block selection on touch devices), different OSes, clipboard, context menus, accessibility (!!), and what else is there, then you just want to quit.
In 2014 we believed in the contentEditable=minimal approach where contentEditable was just meant to provide an input/output layer. Even most of the browser people (all that I can remember) were positive about the idea. We were meant to get a cancellable `beforeinput` event and more reliable Selection and Range APIs. 3 years later and things moved forward (the event is available in some browsers), but so many topics are still open that it's hard to say what's the ETA for all of this.
For example, recently it turned out that IME is a bigger blocker than we thought. Android implements IME APIs in such a way which makes cancelling `beforeinput` impossible to handle on their side.
Simultaneously, there's a recurring idea to drop contentEditable completely and implement a completely new set of APIs. If you'd analyse how many APIs we're talking about you'd welcome contentEditable with open hands. I'm slowly starting accepting the fact that contentEditable needs to be replaced one day and that contentEditable=minimal approach may not be fully feasible, but I expect that we're talking here about next 10 years or more. There's no middle road here – either all the APIs are implemented and stable or contentEditable remains our only weapon.
BTW, I'd like to take this occasion to mention Johannes Wilm from Fidus Writer who's leading the Editing Task Force's work. Without him the whole thing would die sooner or later. We can all give feedback, but someone needs to lead the work and process feedback from all the involved parties.
As a matter of fact, we're involved in the W3C's Editing Task Force since the beginning. Me and Fred (the author of the blog post) were on the first meeting in Berlin back in 2014 and I've been in Paris the year after. Unfortunately, since then many meetings were held outside Europe and they were also concerned with more technical parts of the spec(s) to which it's harder for us to contribute. However, we still try to contribute as much as we can... but I have to say it's tough.
The problem is that this topic is vast and extremely complicated. Rich-text editing itself is complicated, but when you start considering all the languages (e.g. RTL mixed with LTR, IME), different types of devices and interaction models (software keyboards, block selection on touch devices), different OSes, clipboard, context menus, accessibility (!!), and what else is there, then you just want to quit.
In 2014 we believed in the contentEditable=minimal approach where contentEditable was just meant to provide an input/output layer. Even most of the browser people (all that I can remember) were positive about the idea. We were meant to get a cancellable `beforeinput` event and more reliable Selection and Range APIs. 3 years later and things moved forward (the event is available in some browsers), but so many topics are still open that it's hard to say what's the ETA for all of this.
For example, recently it turned out that IME is a bigger blocker than we thought. Android implements IME APIs in such a way which makes cancelling `beforeinput` impossible to handle on their side.
Simultaneously, there's a recurring idea to drop contentEditable completely and implement a completely new set of APIs. If you'd analyse how many APIs we're talking about you'd welcome contentEditable with open hands. I'm slowly starting accepting the fact that contentEditable needs to be replaced one day and that contentEditable=minimal approach may not be fully feasible, but I expect that we're talking here about next 10 years or more. There's no middle road here – either all the APIs are implemented and stable or contentEditable remains our only weapon.
BTW, I'd like to take this occasion to mention Johannes Wilm from Fidus Writer who's leading the Editing Task Force's work. Without him the whole thing would die sooner or later. We can all give feedback, but someone needs to lead the work and process feedback from all the involved parties.