 |
Web Development »
Client side scripting »
General
Intermediate
htmlArea - Turn any TEXTAREA into a WYSIWYG editorBy Fraser CainhtmlArea is a free WYSIWYG editor replacement forTEXTAREA fields on web forms |
Javascript, Windows, IIS, IE 5.5, Dev
|
|
Advanced Search Add to IE Search |
|
|
|
||||||||||||||||
htmlArea is a free WYSIWYG (what you see is what you get) editor replacement for <textarea> fields. By adding a few simple lines of JavaScript to your web page you can replace a regular textarea with a rich text editor that let your users do the following:
Some of the interesting features of htmlArea that set's it apart from other web based WYSIWYG editors are as follows:
Yes! It's really free. You can use it, modify it, distribute it with your software, or do just about anything you like with it.
htmlArea requires Internet Explorer 5.5 or better on Windows to run. This is because it makes use of some advanced features of IE5.5 that aren't available in other browsers yet. It is backwards compatible with other browsers, though. They will get a regular textarea field instead of a WYSIWYG editor.
Sure, make sure you're using IE5.5 or better on windows and see below.
Here is a regular <textarea> field.
And here is a <textarea> transformed with htmlArea (with a single line of JavaScript code).
You can find out more about htmlArea and download the latest version on the htmlArea homepage and you can talk to other htmlArea users and post any comments or suggestions you have in the htmlArea forum.
It's easy, first you need to upload the htmlArea files to your website. Just follow these steps:
<script language="Javascript1.2"><!-- // load htmlarea
_editor_url = ""; // URL to htmlarea files
var win_ie_ver = parseFloat(navigator.appVersion.split("MSIE")[1]);
if (navigator.userAgent.indexOf('Mac') >= 0) { win_ie_ver = 0; }
if (navigator.userAgent.indexOf('Windows CE') >= 0) { win_ie_ver = 0; }
if (navigator.userAgent.indexOf('Opera') >= 0) { win_ie_ver = 0; }
if (win_ie_ver >= 5.5) {
document.write('<scr' + 'ipt src="' +_editor_url+ 'editor.js"');
document.write(' language="Javascript1.2"></scr' + 'ipt>');
} else { document.write('<scr'+'ipt>function editor_generate()
{ return false; }</scr'+'ipt>'); }
// --></script>If you've installed htmlArea anywhere other than /htmlarea/ then be sure to change _editor_url to point to your htmlarea directory (ending with a forward slash "/").
<script language="JavaScript1.2" defer>
editor_generate('fieldname');
</script>Be sure to change "fieldname" to be the name (not id) of the textarea you want to change.
While it's true that all you need is one line of JavaScript to create an htmlArea WYSIWYG editor you can also specify more config settings in the code to control how the editor works and looks. Here's an example of some of the available settings:
<script language="JavaScript1.2" defer>
var config = new Object(); // create new config object
config.width = "90%";
config.height = "200px";
config.bodyStyle = 'background-color: white; font-family: "Verdana";' +
'font-size: x-small;';
config.debug = 0;
// Add additional editor config settings here...
editor_generate('fieldname',config);
</script>See below for even more configuration options that can be added. All of these settings will use default values in editor.js if you don't specify them yourself.
| Width | specifies the width of the editor (in pixels or as a percentage). |
| Height | specifies the height of the editor (in pixels or as a percentage). |
| bodyStyle | specifies CSS style of the editor window including color, default font face, and size. Note, the default font information isn't saved, it just controls how text is displayed if no other font formatting has been applied. |
| debug | if set to 1, displays a debug field with the actual contents of the editor (in raw html) which is updated as your type. |
You can add a config.toolbar config setting to control exactly what's shown on the toolbar. Here's an example.
config.toolbar = [
['fontname'],
['fontsize'],
['fontstyle'],
['linebreak'],
['bold','italic','underline','separator'],
['strikethrough','subscript','superscript','separator'],
['justifyleft','justifycenter','justifyright','separator'],
['OrderedList','UnOrderedList','Outdent','Indent','separator'],
['forecolor','backcolor','separator'],
//['custom1','custom2','custom3','separator'],
['HorizontalRule','Createlink','InsertImage','htmlmode','separator'],
['about','help']
];The square brackets control how the buttons are "grouped" together. You can either erase or comment out (by adding // to the beginning of the line) buttons or button groups you don't want displayed. Most of the buttons do pretty much just what you'd expect, but here's a few odd ones for reference.
| linebreak | adds a linebreak to the toolbar, all buttons after this are on the next line. |
| separator | adds a vertical separator between buttons, helps to visually group buttons together |
| customN | these are custom buttons that can be defined by JavaScript programmers who want to extend htmlArea. |
There is a config.fontnames setting that lets you control this. See below.
config.fontnames = {
"Arial": "arial, helvetica, sans-serif",
"Courier New": "courier new, courier, mono",
"Georgia": "Georgia, Times New Roman, Times, Serif",
"Tahoma": "Tahoma, Arial, Helvetica, sans-serif",
"Times New Roman": "times new roman, times, serif",
"Verdana": "Verdana, Arial, Helvetica, sans-serif",
"impact": "impact",
"WingDings": "WingDings"
};The name on the left is what is displayed to the user. The list of fonts on the right is what is actually put into the font tag in the code.
There is a config.fontsizes setting that lets you control this. See below.
config.fontsizes = {
"1 (8 pt)": "1",
"2 (10 pt)": "2",
"3 (12 pt)": "3",
"4 (14 pt)": "4",
"5 (18 pt)": "5",
"6 (24 pt)": "6",
"7 (36 pt)": "7"
};The value on the right is what the user sees, the value on the left is the actual font size used.
As you can probably guess, there's a config.fontstyles setting for this. Now remember, the styles defined here control how the text looks in the editor. These styles ALSO have to be defined on any page where you display content created with the editor. htmlArea will save the class name with the content but nothing else. It's up to you to define the class style in your pages.
config.fontstyles = [{
name: "headline",
className: "headline",
classStyle: "font-family: arial; font-size: 28px;"
},{
name: "red text",
className: "saletext2",
classStyle: ""
}];The "name" is what's displayed to users, "className" is the name of the CSS class to use, and classStyle defines the attributes of the style in the editor. If you leave classStyle blank you have to be sure to also specify an external stylesheet with all the style information (and matching classNames!). See the next question on how to do that.
You can specify a stylesheet to avoid entering the class style data for each class name. You still have to specify which classNames you want to have available though, see the previous question for information on that.
config.stylesheet = "/style.css";
When we originally started the htmlArea project we had some pretty specific goals in mind for how it would work and what issues were important to us. Those goals still lead the direction of development today and are listed below in order of priority.
htmlArea has to always be backwards compatible with older and unsupported browsers. This ensures that even if a user with an older and unsupported browser can't use htmlArea, they'll always be able to, at a minimum, enter text in a plain textarea like they would have done before. htmlArea should also be compatible with as many programming languages as possible by being completely DHTML and JavaScript based.
htmlArea needs to be easy for developers to integrate into their applications and customize, easy for programmers to extend and modify, and easy for end users to "use". That's why you only have to add a single line of JavaScript for each textarea you want to convert, and why all the code is stored in a single, easy to follow JavaScript file. That's why htmlArea can be used with almost any programming language (ASP, PHP, Perl, Java, etc), and that the toolbar is streamlined, customizable by developers, and follows the conventions of common word processing programs.
htmlArea needs to be fast loading, allow the user to perform word processing functions at a reasonable speed, and not put a lot of strain on a user's browser. To these ends we've managed to keep the main editor program in a single file of only 40k and we've written the editor in such a way that it has a minimal impact on the resources of the browser it is running in. In addition, where we make use of popup windows to perform additional functions we try to put as much code as possible in the popup window so it doesn't increase the size of the base editor.
htmlArea is based on the MSHTML Editing Platform in Internet Explorer 5.5+ on windows. Basically, Internet Explorer includes some functionality to make sections of a webpage editable by defining a "contentEditable" attribute or "designMode" property. It also provides some built in commands for performing common web editing operations (bold, italic, center, insert image, etc).
htmlArea builds on the features provided by Internet Explorer and adds its own user definable toolbar, an easy method to include a WYSIWYG editor in a web page (replacing textareas), an easy way to save user changes, as well as a number of custom web editing commands of its own.
How htmlArea actually works is it replaces a textarea with an (user definable) toolbar, an iframe that has the "contentEditable" attribute set to true, and a hidden field with the same name as your original textarea that gets updated automatically when you modify content in the editor.
The user can enter or modify text as well as use keyboard shortcuts and toolbar buttons to perform operations on the content. A lot of the editor commands are built into IE and called via the execCommand method, but htmlArea also includes other custom commands and functions written in JavaScript and stored in the editor.js file or the popup windows (in the /popups/ folder).
No. None of these other browsers (including IE for Mac) support "contentEditable" or a way to make existing content in the page editable. It might be possible to emulate this in JavaScript, but it would be a lot of work. Other problems include displaying or emulating the flashing | bar cursor you see when editing. The cross-platform Mozilla browser has some bug entries related to adding contentEditable functionality, and perhaps in the future it may be possible to create something for that browser.
Although it's a long shot, you might want to send a friendly letter to Microsoft to encourage them to make the "contentEditable" functionality work on IE for the Macintosh. Once they implement it, we can offer it.
The HTML output by htmlArea is generated by the built in functionality of Internet Explorer. For that reason, there is no easy way to have it output XHTML. If we were going to do it, the way to do so would be to parse the HTML after it's output by IE and convert it to XHTML. That's something we hope to do at some point.
No. We want htmlArea to be compatible with as many programming languages as possible. Because it's written in client side JavaScript, it should work with any programming language. If we start adding language specific features htmlArea won't be as useful to as many people. That said, there's a lot of free "file upload" scripts available, and htmlArea does include a function called editor_insertHTML() for inserting text or HTML tags. If you want to write your own program for doing this it shouldn't be that hard. Alternatively, you might check in the forum to see if someone already has.
Maybe, maybe not. If it's a good feature and it fits in with the goals of our project we'll likely consider it. The best thing to do is post your suggestions to the forum. At the very least we'll try to give you some suggestions and point you in the right direction. At best you might find somebody else has already implemented the feature you were hoping for.
Yes, just search for "buttonface" and "buttonhighlight" in editor.js and change those to whatever colors you like. If you haven't heard of those colors before, it's because they're special windows colors that match whatever color scheme the user has selected for their desktop. For example, if someone has changed their desktop color scheme to "lilac", the WYSIWYG editor toolbar and buttons will match that theme. Try it, it's really neat.
The number one thing you can do to help is also the easiest thing to do; give us a link on your website. The more people who can find out about htmlArea the better it will be.
The next best thing you can do is participate in our forum and post a message or two to help other htmlArea users (or learn something new yourself).
Lastly, any code improvements you want to share would certainly be welcome as well.
This is a bug/feature of Internet Explorer. htmlArea dynamically updates the content of your page to replace a textarea with the WYSIWYG editor. In Internet Explorer, when you update the content of a page after it has loaded and insert an image it will load the image from the server EVEN if has the image in it's cache. This means if you have 10 htmlareas on the same page the "bold" toolbar button will be loaded 10 times.
One workaround for this is to move all your editor_generate() scripts to the bottom of the page, combine them into one script tag, and remove the "defer" attribute from that script tag. This will cause them all to run just as the page is finishing loading and the cached images WILL be used. Meaning, the browser will only need to load each image once.
We update a hidden field every time you make a change in the editor so the hidden field will be submitted when you submit the form. The way undo/redo works in Internet Explorer it seems to reset the undo buffer every time you use JavaScript to set the value of a form element or otherwise make changes to the page. Because of this the built in undo/redo functionality of the browser doesn't work. We hope to implement our own undo/redo functionality at a future point.
Internet Explorer has a tendency to convert relative paths into absolute paths. We've seen some implementations of WYSIWYG editors that maintain relative paths "better" than others but certain operations (such as dragging and dropping, etc) still convert relative paths to absolute paths. We hope to find a workaround for this in a future version.
This is due to Internet Explorer and the way the editor works. The editor already has a HTML header of its own so inserting another one confuses the browser and the content gets thrown away. The best solution is to have another plain text textarea field for HTML header information.
This is a result of how Internet Explorer works. It seems to discard certain tags that it doesn't need to display. Because htmlArea reads the content back from the browser it cannot preserve content the browser has "thrown away".
If you have two or more textareas with the same name on the same page and you try to convert one or more of them into a WYSIWYG editor htmlArea won't work. This is because htmlArea looks up the textareas by name in the entire page, not just inside a specific form. There's currently no workaround for this. We hope to resolve it in a future release.
This is a bug/feature of Internet Explorer. Even if you get unsecure warnings your form contents should still be submitted securely.
htmlArea uses an <iframe> to contain the editor and because the contents of the iframe isn't being loaded off a secure site, Internet Explorer thinks the iframe is unsecure. The problem is, the iframe doesn't load anything off any site, it's blank, it doesn't even have a src attribute. We just create an empty iframe and then use javascript to update it. We hope to have this fixed in a future release.
Note: There's a clever workaround for this problem posted in the forum here. The only issue with it is that can cause the back button to not work as intended (it goes back in the iframe first).
Version 2.03 (Released: December 17, 2002)
Version 2.02a (Released: December 5, 2002)
Version 2.02 (Released: December 5, 2002)
Bug Fixes (Thanks to everybody in the forum for contributing and reporting bugs!)
- fix nested script tag error (thanks to Phil Revill)
New Features
- added 'replaceNextlines' config option to replace nextlines with spaces on output
- added 'plaintextInput' config option to replace nextlines with <br> tags on input
Version 2.01 (Released: December 3, 2002)
Bug Fixes (Thanks to everybody in the forum for contributing and reporting bugs!)
- fixed "function not found" error for non IE5.5+ browsers (thanks to slowhand)
- popup editor - fixed javascript error caused during launch of popup (thanks to slowhand and Chlorel)
- popup editor - fixed toolbar 'linebreak' error (thanks to fbridge9 and RekiM)
Documentation Updates
- Add two new questions to readme.html
- Why do the toolbar buttons take so long to load when I have multiple htmlArea editors on the same page?
- Why do I get "non secure items" warnings when using htmlarea on a secure (SSL) https:// page?
Version 2.00 (official release) (Released: November 25, 2002)
New Javascript Functions
- editor_getHTML(objname) - return HTML content of editor
- editor_setHTML(objname) - set HTML content of editor
- editor_appendHTML(objname) - add HTML content to editor
New Features
- Popup "fullscreen" editor now has minimize and maximize buttons (switched from ModalDialog to popup window)
Bug Fixes (Thanks to everybody in the forum for contributing and reporting bugs!)
- "Create Table" popup now creates tables with the correct number of cols and rows (thanks to Corey)
- Clicking on images no longer causes error when you have "CSS style pulldown" enabled (thanks to Virrdo)
- Fixed bug that prevented external stylesheets from working properly (thanks to slowhand)
- fixed javascript errors in Mozilla 1.0 (thanks to slowhand)
- moved browser detection code to editor page to prevent javascript errors from older browsers and prevent the editor from being loaded unless it's needed.
- submitting empty htmlarea now submits nothing "" instead of "<p> </p>"
- Popup "fullscreen" editor no longer generates error on "<>" html mode change
Version 2.00 (beta2) (Released: October 16, 2002)
New Docs
- created new readme.html with install instructions, faq, and lots of information
New Features
- added support for stylesheets
- get enlarge/shrink window working
- get context menu working (still disabled by default, needs more code for functionality)
- allow user to change ANY option in internal config from calling page
- added _editor_filterOutput function that's called on form submit
- added insert table button
Bug Fixes / Optimizations
- organized associated files into directories
- fixed bug that caused htmlarea to sometimes not display last entered content when user pressed back in their browser.
- moved about window into a separate file to reduce size of editor
Version 2.00 (beta1) (Released: August 19, 2002)
visual changes
- added mouseover/mouseoff events and style for toolbar ui buttons
- update toolbar to take up less space and be smaller
- display point sizes beside HTML font sizes (eg: 7 (36px)
- change "about this editor" icon to an "i"
- created a help popup (content still needs to be written).
- added version number to about page.
code changes
- added "defer" to script tag to prevent editor from being created until page loads
- simplified header that needs to be added to pages that contain editor
- generated script include tag using _editor_url so users don't have to enter URL twice
- moved CSS for editor toolbar buttons into editor.js
- switched to using object to pass configuration arguments to editor_generate
- general code improvements, optimizations and re-organization
- added hooks for keypress events for future use
new features
- added pulldown for CSS style classnames
- added many many more config options including:
- ability to select which toolbar elements you want displayed
- ability to specify the order of toolbar elements
- ability to specify fonts, sizes, and CSS styles for pulldowns
- ability to set default font and style used in editor window
- debug flag that lets you see the source of the WYSIWYG field at all times
- add more sample code and comments showing how to add custom buttons
bug fixes
- fixed error caused when height/width were manually specified (reported by jpeto, thanks!)
- "about this editor" window now works when in textedit mode
Version 1.05 (Released: August 28, 2002)
Version 1.04 (Released: August 27, 2002)
Version 1.03 (Released: August 26, 2002)
Version 1.02 (Released: August 21, 2002)
Version 1.01 (Released: August 20, 2002)
Version 1.00 (Released: August 19, 2002)
General 
News 
Question 
Answer 
Joke 
Rant 
Admin
|
PermaLink |
Privacy |
Terms of Use
Last Updated: 6 May 2003 Editor: Chris Maunder |
Copyright 2002 by Fraser Cain Everything else Copyright © CodeProject, 1999-2009 Web19 | Advertise on the Code Project |
