Browser-provided editing APIs

[Kevin Dangoor]

Editors like Ace have to go to a lot of trouble to implement basic editing behavior. The problem is that even with all of that trouble taken, bidi text and accessibility are not easily supported (if at all!).

Meanwhile the built-in editing code in browsers like Firefox already know how to do a10y and bidi text. What if basic editing could be provided by the browser and higher-level (code oriented, in Ace's case) functionality could be added on top?

We can make it happen. We just need to figure out what the APIs should be (and this is where people building the core editor code can help!)

What APIs would you want to outsource basic caret movement, selection and typing behavior to the browser?

https://wiki.mozilla.org/Features/Desktop/EditorAPI

Kevin

--
Kevin Dangoor
product manager, developer tools

work: http://mozilla.com/
blog: http://blueskyonmars.com/
@dangoor

[Fabian Jakobs]

Hi Kevin,

thanks for picking this up.

> Editors like Ace have to go to a lot of trouble to implement basic editing behavior. The problem is that even with all of that trouble taken, bidi text and accessibility are not easily supported (if at all!).

With the Ace approach bidi should be possible but apparently a10y is
really hard to achieve.

> Meanwhile the built-in editing code in browsers like Firefox already know how to do a10y and bidi text. What if basic editing could be provided by the browser and higher-level (code oriented, in Ace's case) functionality could be added on top?
>
> We can make it happen. We just need to figure out what the APIs should be (and this is where people building the core editor code can help!)
>
> What APIs would you want to outsource basic caret movement, selection and typing behavior to the browser?

I'm actually really happy that Ace takes control over all of this.
This makes it much easier to implement features without having to
worry about specific browser implementations. What I would like to see
however are APIs which can be used to inform the browser about Ace's
selection, caret, etc.

Similar to what ARIA is doing for markup. Something like: "Hey browser
I manage my own text selection. If you want to know the contents call
this function." This way we could even switch back to canvas based
rendering if we ever want to without any a10y drawbacks.

Best,
Fabian

[Kevin Dangoor]

Hi Fabian,

On Aug 11, 2011, at 5:50 AM, Fabian Jakobs wrote:

Meanwhile the built-in editing code in browsers like Firefox already know how to do a10y and bidi text. What if basic editing could be provided by the browser and higher-level (code oriented, in Ace's case) functionality could be added on top?

We can make it happen. We just need to figure out what the APIs should be (and this is where people building the core editor code can help!)

What APIs would you want to outsource basic caret movement, selection and typing behavior to the browser?

I'm actually really happy that Ace takes control over all of this.
This makes it much easier to implement features without having to
worry about specific browser implementations.

Part of the problem with contentEditable is that it's apparently not well specified... the browsers don't really have a standard that they follow. There are plenty of browser features that you make use of every day where you need not worry about specific browser implementations.

The basics of editing is a solved problem in the browser, so it seems reasonable to me to try to expose that base level functionality and allow more to be built on top of that.

bidi text is potentially doable, but it's a lot of work to get it right. Work that the browser has already done. That said....

What I would like to see
however are APIs which can be used to inform the browser about Ace's
selection, caret, etc.

... this is a good suggestion. If there was a low-level API for selection, caret, etc. then it would at least be possible for people to implement any editing/rendering behavior they wish.

Similar to what ARIA is doing for markup. Something like: "Hey browser
I manage my own text selection. If you want to know the contents call
this function." This way we could even switch back to canvas based
rendering if we ever want to without any a10y drawbacks.

Yeah, good point. I'll make notes of this in the feature page.