Re: [w3c/editing] Universal interface to modify content in a JS editor from unrelated JS code. (Issue #551)

johanneswilm left a comment (w3c/editing#551)

> Slate is now accepting untrusted beforeinput events

great!

> This incident reinforces my earlier position that an in-built browser API is the only path that ensures reliable text manipulation across the entire web. Any other approach such as relying on untrusted events can break silently for our end users overnight.

A built-in browser API for text manipulation would be a good idea in theory, if browser makers had the resources and interest in keeping it up-to-date, fix bugs, make it customizable, etc. . Unfortunately, that has historically not been the case as text editing does not seem to fall within their core interest. For that reason we have spent the last 15+ years moving toward giving JavaScript more fine-grained access to fundamentals. That way JavaScript editors companies and individual programmers, whose interest are more closely aligned with those of JavaScript editor users, have the ability to make fixes where they are needed.

In this case, for example you were able to get the editor to create a fix within just days. Browser makers, on the other end, have open bug reports for years and up to decades. The last new APIs that have come have been Input events, EditContext and probably the Clipboard API, and it has taken many years for those to be developed. This would require a similarly complex API if done correctly. Reusing some part of the ancient `execCommand` API and hasn't been actively fixed/developed for many years is not a good idea as it gives the wrong semantic type ('paste" rather than "insertReplacementTetx") and it is not supported by more modern APIs like `EditContext`. 

> I would strongly push back on this. I don't see any precedent or reasoning for why the page scripts should be able to identify which browser extension used which DOM API, not just the text manipulation API.

The problem here is of control. The browser makers are the ones who supposedly monitor what the extensions contain, but they don't actually monitor for whether they behave well when it comes to sending editing-related events. 


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/551#issuecomment-6123793936
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/551/6123793936@github.com>