The cut and paste irritation in "smart" in-browser text editing
It's common for modern websites and browser based applications (such as Grafana and Prometheus) to have some corner of their experience where you enter text. On Twitter or the Fediverse, you may want to write tweets; in Prometheus and Grafana, you may want to enter potentially complex metrics system expressions to evaluate, and so on. HTML has a basic but perfectly functional set of mechanisms for this, in the <textarea> and '<input type="text" ...>' form elements. However, increasingly often websites and apps feel that these are not good enough, and what people really want is a more advanced experience that's more like a full blown local editor.
(Sometimes this means code editing style colours, highlighting of matching brackets, smart indentation, and autocompletion (as in Grafana and Prometheus). Other times this is augmenting the basic job of text entry with additional features, as in Twitter.)
Unfortunately, quite a lot of the time an important feature seems to get left on the cutting room floor in the process of adding this smart text editing. Namely, good support for cut and paste (in the broad version that supports copying text as well). True, native browser cut and paste has a surprisingly large range of features (especially on Unix), but web editors often fumble some or much of these experiences. For instance, on Unix (well, X, I can't speak for Wayland) you can normally highlight some text and then paste it with the middle mouse button. This works fine on normal HTML input objects (because the browsers get it right), but I have seen a wide range of behaviors on both the 'copy' and the 'paste' side with smart text editors. Some text editors only highlight text when you select and you can't copy, especially to other applications; some text editors copy but spray the text with Unicode byte order marks. Sometimes you can't paste in text with the middle mouse button, or at the least it will be misinterpreted.
The slower full scale formal, explicit Copy and Paste operations are more likely to work but aren't always safe in things that claim to be text fields. Even when they work, sometimes Ctrl-C and Ctrl-V are intercepted and you can only perform them through menus. And I've seen systems where text would claim to paste but become mangled on input.
Unfortunately, it's easy for me to imagine how this happens during web development. First off, I believe that the Unix style 'select then paste with the middle mouse button' isn't widely supported outside of Unix, so people not developing on that can easily miss it entirely. General cut and paste is widely available, but it's also a generally unsexy thing that is neither as obviously attractive nor as frequently used as typing and editing text in a text field. Most of the time you write Tweets by hand or type in metric system rule expressions (with possibly autocompletion). Copying them from or to elsewhere is much less common, and less common things garner bugs and get to be lower priority for fixing bugs. I doubt web developers for places actively want to break cut and paste; it just happens by all too easy accident.
(This is partly a grump, because I'm tired of my cut and paste not working or only half working if I remember to it in a way that I rarely use.)
|
|