I’ve recently realized that copying to the clipboard a snippet highlighted by Chili works differently in Internet Explorer (IE) and in Mozilla Firefox (FF). They both copy two versions of the selected section: TEXT and HTML.
- IE TEXT
- HTML entities resolved
HTML stripped off - result copied
- FF TEXT
- HTML entities resolved
BR elements replaced by new lines
HTML stripped off - result copied
- IE HTML
- HEAD element copied
containment path elements copied
selected text with HTML in place copied - FF HTML
- selected text with HTML in place copied
The net result of all this is that IE does the right thing with HTML while FF does the right thing with TEXT, and neither is completely right or wrong.
- copying from IE to Notepad you get an awful long line, but copying to Word you get all wonderfully colored
- copying from FF to Notepad you get a properly formatted section, but copying to Word you get all sadly monochromatic
UPDATE (2007/02/24): What follows is obsolete, because I’ve implemented a transparent method in Chili 1.7
In Chili 1.6 I’ve implemented a workaround for IE, so that IE TEXT is like FF TEXT. It’s a workaround because you need to add a button to each highlighted section, and it will copy all the text in that section when clicked.
The button can be as simple as a DIV placed before the PRE, like this: {[.buttonized /enzymes/chili-web.php]}
Chili will hide any element with a class ie_copy in any browser but IE, where instead it will associate a click handler to it, for copying all the next PRE content as a properly formatted section. You can style the button element as you like, because Chili uses the class only for accessing the element.
You can also place the button wherever you like. If so, i.e. if the button element is not the element preceding the PRE section, then you have to feed Chili the method for getting the PRE content. You can do it globally or locally.
When Chili associates the handler to the button, it will look for a getPRE method inside the button element. If there is one, then it will be used, else Chili will look for a getPRE method inside the global ChiliBook object. If there is one, then it will be used, else Chili will give up and not associate a handler.
You can change the global behavior by changing the declaration of the getPRE method inside the ChiliBook object, and you can change the local behavior by adding a chili metaobject (an object with a class chili) inside the button element, with a getPRE param whose value is the function declaration.
The getPRE function shipped with Chili 1.6 is the following, where the button element is passed into this and the PRE destination is found starting from that origin:
{[.getPRE /enzymes/chili-js.php]}
A button element after the PRE element could then be locally configured like this: {[.buttonized2 /enzymes/chili-web.php]}
Instead of the copy link, look into modifying the content going to the clipboard by way of the onbeforecopy and oncopy methods.
onbeforecopy
http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/events/onbeforecopy.asp
oncopy
http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/events/oncopy.asp
Thank you very much, Jeff!
I’m going to develop a fix for Chili. I think I can release Chili 1.7 very soon, eventually without a workaround like this 🙂