(Or you could just put the button in Flash, which can track user-initiated events.)

That “zeroclipboard” hack… that’s a clickjacking exploit, isn’t it? Browsers really need to guarantee that What You See Is What You Click. Hacking atop the fault doesn’t seem sustainable.

jd/adobe

But that’s a digression from the subject of this post. The applet seems to be the way to go, if you cant do it all with a hidden field. The applet and js api you wrap around it just need to bridge the gap – put a facade up that smooths away the funkiness you describe here, until such time as sanity is brought to the subject. That would give you your IE compatability too (when you need it).

I know everyone has this knee-jerk reaction when it comes to java applets, but seriously, why not?

1) Access to the global OS clipboard proper – I’d be very worried for the future of the web if you succeeded in doing this while sticking to non-proprietary W3 tech.

2) Create your own clipboard + cut & paste methods that stick to your app – context menus & events bound to Ctrl+C/X/V operating with mouse coords and focus respectively on a textarea.

Regards,
Barney

When I inspect BeSpin with Firebug, I see a div element with id=editor that contains a canvas element with id=canvas — and that’s it. I can’t use Firebug to manipulate the editor (like resize, move or delete elements). I can’t put CSS declarations in my user agent style sheet that will have any effect on the BeSpin text editing — and furthermore, I can’t use any extension that manipulates fonts, colors, etc. on my behalf. Even Firefox’s Zoom Page function has no effect on BeSpin. When I run a “Find on Page”, I can’t find any of what I’ve typed. Even the copy & paste problem you describe in this post arises partly because you’ve spun your own UI. What about testrunners? I use Selenium IDE to automate my website testing. Completely useless with BeSpin. The ScrapBook extension, which lets you save webpage clippings? Useless again with BeSpin. Spellcheckers? Useless. Context-sensitive searches? Useless. The list of browser features and extensions that this breaks just goes on and on.

And then there’s Ubiquity. Oh what irony that Ubiquity becomes completely useless on a fellow labs project given what the word ubiquity means!

BeSpin is still hackable in one very important regard: because it uses the browser’s Javascript engine, I can use something like GreaseMonkey to alter it’s behaviour. But BeSpin is its own system — I have to learn the BeSpin system in order to do any hacking on it.

What happens if everyone starts thinking this kind of thing is a good idea and developing their own BeSpin-like projects? We’ll have 10000 different websites with 10000 different systems that people have to learn in each new case to do something basic like change their font!

To be fair, you’ve proposed adding a custom DOM within the canvas. This may address some of my concerns, but unless you are proposing to make that custom DOM a wider standard, it really doesn’t address anything. You may as well just dump out plain text, because the tags are meaningless by virtue of having no common interpretation. (Because that’s what meaning is!)

I don’t wish to sound too critical. I realise this is an experiment and I think it’s a great exploration of what’s possible and is a very promising project in itself. But unless you address hackability, then I cannot support the project.

(Aside: I find myself constantly trying to defend web hackability. Whether it be because of Flash, Silverlight or Java, or information hiding and non-mutability in ES4, or security practices that haven’t been subjected to a proper cost/benefit analysis. Where is the FSF when I need them? :) )