W3C Working Draft: Clipboard API and events | Hacker News Reader

W3C Working Draft: Clipboard API and events

w3.org

22 pointscaptn3m015 comments

There's something that I really need to get off my chest and I looked for an occasion to vent my frustration for a while. I'm taking this occasion right now.

Instead of adding new APIs, is it possible to address the ENORMOUS elephant in the house: <textarea>'s API.

It's unusable. People have built workarounds for years and yet, nothing has changed. Here's a few things to get started:

- Autoresizing. CSS resize: auto; could work but I don't care how we do it.

- Styling content. So we can use it to build IDE. So something like iA's editor can be built.

- Tokenizer. This would help solve the above. Could be a strip down version of a HTMLElement. Or an approach like SVG. Anything. Lots of people have more experience than me on this matter. I'm sure some of you can come up with something.

- Better input management. So we can build IDE with auto-indent.

The web is so dynamic now, and all the editor out there are ugly hacks that are so hard to maintain. Anyone who's built an interface over textarea/contentEditable shares my pain.

If, for whatever reason, it's impossible to have a textarea fullfill this job, then can we at least get a decent contentEditable implementation. It's so broken. On so many level.

I love you all, and I appreciate all the hard work, but I hate textarea's dumb API.

There's no reason that this can't be addressed while adding new APIs. They're not mutually exclusive.

Yes, it is very limited, indeed.

However, W3C is not a single group. Specs are developed (and proposed) mostly by charters or separate working groups. They are developed without "strict" control by W3C. This means that there are lots of specs being built in parallel[1], which means that having people develop the Clipboard API standard won't imply less (or more) development on the textarea-related standard...

[1] Some of them even collide, while others are designed to serve specific (corporative) interests.

The current trend is to find and expose the low-level primitives that let developers build their own tags, so that instead of needing more features added to <textarea> you can build an element that does everything <textarea> does and more. Then you are not constrained by the W3C process or decisions.

Web Components plus the Selection and Range APIs get you most of the way there for <textarea>. Unfortunately, I've found them to have different bugs in various browsers, probably because they're not used so much, but fixing these APIs opens up a lot more than just better <textarea>.

https://developer.mozilla.org/en-US/docs/Web/API/Range https://developer.mozilla.org/en-US/docs/Web/API/Selection

Custom elements can't participate in <form>s easily yet, which should probably be fixed, but a lot of apps are skipping form submission for XHR calls anyway.

I wish I could mark something, hit " or ( and it would be in double quotes or enclosed in brackets like in any decent editor. My muscle memory fools me every time.

Finally.

To me, this looks like a step further away from Flash (used for copying things to the clipboard), which I see as a great thing.

Also, I've been working on a password manager that could dramatically benefit from such an API. I hope that browser vendors will allow synthetic copy/paste (especially copy) events if explicitly allowed by the user (similar to how geolocation APIs work). This would be especially helpful for mobile devices where it's difficult to copy things at the moment.

This is nice, and could really be useful. But it's raising a lot of privacy concerns. A lot of sensitive information is placed in the clipboard like private URLs and even passwords sometimes.

I think a whitelisting of sites is needed in the web browser to use this API.

They're aware of it: http://www.w3.org/TR/clipboard-apis/#privacy-concerns

The problem I see with this spec (and the current implementation in browsers) is that you can't trigger a copy without having the user manually press ⌘C or do the platform equivalent command for that. That way you can't implement custom UI (like toolbars) or even have a link automatically copied to clipboard (by a URL shortener, or by a file upload website).

This is specially problematic on iOS and Android, where copy and paste depend on contextual popups/bars that only show up when you have text selection. This makes it much harder or impossible to implement advanced editors like say, a 3d modelling application, or image editor with copy and paste functionality on these platforms.

The semantics of the "different" origin escaping will be interesting, in that they talk about about rich text editing and the clipboard API's usefulness there, but isn't removing the ability to copy/paste HTML 'formatted' text from another origin a part of that use case?

I am constantly switching between my phone and laptop/desktop. Quite often I get a link on the phone that I would like to open on desktop or vice versa (say forward a link on desktop to someone on whatsapp on my phone).

Would be nice to have some kind of "paste to device X"

Take a look at pushbullet, it allows you to share items between devices, they also added a new feature which lets you share your clipboard between devices.

Thanks! Looks useful

or Instashare

I'm very curious to see if this will make it possible to have password managers on Firefox OS.

Reply on news.ycombinator.com