widgEditor: A simple, standards-compliant WYSIWYG HTML editor
27 January 2005
There's quite a few HTML-based HTML editors out there, but they all lack something. Most of them are fairly code obtrusive – requiring you to carve out a hefty chunk of HTML/JavaScript in order to get them to display – or the outputted code is hardly standards compliant.
HTMLArea is probably the most well rounded solution, but it's far too complex for most of my applications – its code isn't extremely extensible, the interface isn't customisable, and inherent with its abundance of editing freedom is the risk that an unwise author will produce a horrid looking mash of <font> tags.
Kevin Roth's Rich Text Editor brings in a bit more simplicity, but the source code is again pretty messy, and the ease with which it is applied to a page isn't great.
So, in steps my contender: widgEditor.
I've kept it to a minimal functionality set – the sort of styling that you'd require for a weblog or CMS. However, the object oriented code is easily extensible should you be adventurous enough to want to add on extra doodads.
The key to my implementation is the ease with which the widget is installed. Just put in one line of JavaScript at the head of the HTML page, attach a class to whichever textareas you wish to convert, and they're converted! Style the interface purely through CSS and configure all the options in one place in the code – right at the top.
All of these types of editors rely upon the editing capabilities of the browser. Thusfar, only two browser manufacturers have HTML editing available. Thankfully they're probably the two with the largest market share – Internet Explorer and Mozilla. If you're using anything else, you'll just get the downgraded textarea. (As you will if you don't have JavaScript, either.)
You'll see that I'm now using widgEditor for my own comments. I figure that's the best place to road test it. I'm sure that the code will be hammered over the next few weeks, and found a little wanting, so updates will be forthcoming as bugs appear.
Update (2005-01-28)
I've redone the submission parsing, so now there shouldn't be any problems with overlapping tags, orphaned text, etc. How? I removed some dodgy regular expressions and used full DOM checking to ensure that elements were where they're meant to be.
You should also be able to view the HTML source now. (Don't make untested code modifications at 4AM ... or ever.)
Problems with the toolbar coming up and nothing else in Safari shall be fixed; I have a rough idea of what's going on, but need some solid AppleTime. However, when it's done you still won't get the editor – plain textarea for you, until Steve Jobs does something about it.
Update (2005-01-30)
Textareas with multiple classes (i.e. other than "widgEditor") are now found and converted.
Mozilla's <span> formatting for italic and bold are now converted to <em> and <strong> respectively when the HTML source is viewed and when the form is submitted.
Multiple textareas on the one page are now supported. Some trickery was required because of some weirdness with the DOM and quickly replacing several elements on the page, but it does work!
Update (2005-02-15)
Fixed disappearing content bug when switching between WYSIWYG and HTML Source views.
Toolbar items now give appropriate feedback when cursor is placed in a styled area. (i.e. indicates whether current selection is bold, italic, list, etc.)
Removed whitespace at beginning and end of HTML Source. (Mozilla previously kept adding tabs)
Improved text styling in Mozilla. Previously it could not remove <strong> or <em> tags. This was fixed by using spans whilel in WYSIWYG mode, but seamlessly converting them to semantic tags for all other purposes, including final output.
Hyperlinks can now be removed by clicking the "Hyperlink" toolbar item when a hyperlink is selected.
The addition of entries to the browser's history is not fixable. This is a side effect of using iframes (necessary for Mozilla), and can therefore not be counteracted.
To be added: insert images, clean pasted content.
Update (2005-02-17)
Fixed Safari no show bug. Safari hasn't implemented HTML editing, but they have the hooks to do so, therefore detection of HTML editing returns true. Had to hack around this.
Update (2005-02-28)
Insertion of images has been added. If you ask me, putting images inline with text looks crap, but each to their own.
When content is pasted via ctrl-v it can now be cleaned. By default, widgEditor asks you whether you wish to clean the content, but by changing the widgAutoClean variable in the configuration to equal true, cleaning will be done automatically.
The cleaning function checks for unaccepted elements i.e. anything but #text, <a>, <em>, <h1>, <h2>, <h3>, <h4>, <h5>, <h6>, <img>, <li>, <ol>, <p>, <strong>, <ul>, and replaces block elements with paragraphs, replaces bold and italic with their semantics and removes other inline elements. Unaccepted attributes are also removed i.e. anything but alt, href, src and title.
Some additional Microsoft Word cruft is also removed, to enable clean pasting from that application.
There are no further planned feature add-ons for widgEditor. It will now only be updated for bug fixes.
Update (2005-03-09)
Did some major tightening of the paste cleaning. Wasn't cleaning complex HTML thoroughly, now does so. Pasting from Word into Internet Explorer now removes all Word CrapTags™.
<br>s right before the end of block elements are removed.
Pasted bold and italic styles weren't editable in Mozilla. Now are.
Comments
1/269
Nate Cavanaugh commented on 27 January 2005 @ 04:47
Okay, now that is pretty sweet :)
What is your policy on using this in other projects? Is it a GNU type distro, or are you going to close source it once you're finished with it?
Great stuff :)
2/269
The Man in Blue commented on 27 January 2005 @ 04:51
It'll be an open source thing (just had to bold something :o] )
I'll mention that on the demo page sometime soon.
3/269
Shaun commented on 27 January 2005 @ 05:19
Slight problem in Safari 1.2.4, there's no textarea to be found.
Mighty fine otherwise.
4/269
Rob Mientjes commented on 27 January 2005 @ 05:34
Neat stuff mister. Really neat :P
5/269
Jonathan Broome commented on 27 January 2005 @ 05:43
Very Cool. I did a little testing of my own. This page...
Don't have a Mac handy to test with.
If I could have one wish, it would be that the "B" and "I" buttons somehow kept state when they're in effect (alternate 'depressed' images or a change in border style or something). Wish or not, Great job!
6/269
mattymcg commented on 27 January 2005 @ 06:02
Hey Cam, great work.
I noticed when making a list (ordered or unordered) that if you don't specifically set any text before the list it will put the ol/ul before the end of the /p of the preceding text.
Also the widget seems to be firing my "find" bar in Firefox whenever I type a single apostrophe. A forward slash seems to trigger it as well.
Weird.
7/269
mattymcg commented on 27 January 2005 @ 06:06
That was supposed to say "if you don't specifically set any text before the list as 'paragraph'".....
8/269
Jonathan Snook commented on 27 January 2005 @ 06:18
The editor on this page seems to work well but I encountered two problems in testing out the demo in Firefox 1.0.
I've done a fair amount of work using MSHTML and I'm contemplating building something similar for Mozilla/Firefox. Have you found it difficult to work with?
9/269
kryps commented on 27 January 2005 @ 06:21
The man in red! This is perfect! This is exactly what we are all looking for!
Oh my god, when will there be v0.2a ?
10/269
Jonathan Snook commented on 27 January 2005 @ 06:24
Just trying it again locally in IE6/XP2 and I'm noticing some other behaviour:
invisible, not enabled, or of a type that does not accept the focus.
11/269
kryps commented on 27 January 2005 @ 06:25
Jonathan Broome, you can stay in your world of supporting ie 3 and ie 4 as part of the minority group.
Man in red, keep up the good work, and remember that ie 3 and ie 4 support is pointless.
12/269
romily commented on 27 January 2005 @ 07:52
Just what I'm looking for!
I really like the semantically correct code, the minimal but sufficient options my sort of "hardly computer literate" clients would have, the CSS contextual control which is inherent here, and the minimal effect on page complexity (rider: I don't know all the other contenders, but the code I've seen in a few looks a mess of <font> tags, etc.).
Looks good. Looks good.
13/269
shawn commented on 27 January 2005 @ 08:12
good start! i love the markup footprint.
i have the same disappearing mac ff issue noted above... i've used kevin roth's in a couple of webapps and have found myself wrapping it in a php object for getting it into the page. i did have to re-write some javascript to get it to behave more or less the way i wanted it to, but it has worked fairly well. i just re-format the html on submit to make sure changes get tracked correctly. it likes messing with white space.
looking forward to seeing how you tackle the img and object tags. :-) still working that one out for compliant markup with a fairly easy-to-use (but light) dialog.
14/269
John Nunemaker commented on 27 January 2005 @ 10:33
Very nice tool. It was easy to setup. By far the easiest of those I've tried. Do you have any plans to implement colors?
15/269
Fred Milgrom commented on 27 January 2005 @ 10:43
Just fantastic! Looks great and seems easy to install.
This is definitely something that I will be adding to my own sites in the future.
Keep up the good work!
16/269
Ryan Brooks commented on 27 January 2005 @ 11:16
Well, there are a couple downsides to most of the editors out there, such as HTMLarea and whatnot, and that is that they are built around microsofts crappy editing functions... they also cannot get around mozzie's 'nope, can't paste content here, security risk' without changing the user configuration.
Now. Xstandard! - That's what I'm talking about... It's not crossbrowser, of course, windows IE/Mozzie only, but it has more goodies than you can shake a stick at...
Course, it's enterprise... but meh.
-Ryan
17/269
Jason commented on 27 January 2005 @ 16:59
The interface is really nice. Very simple, clients could deal with this quite easily. My only issue (which has already been mentioned) is the odd nesting of paragraph tags. I also selected a line of text in the middle of some jumble and changed it to Heading 3, and the <h3> was inside a <p>.
But once that's sorted out - very nice work!
18/269
~J~ commented on 27 January 2005 @ 19:43
Nice little app, hope to see more developments such as image, colours, etc.
Only thing I'd like to know is it your page, or the code your script generates that goes against the XHTML verification? Trying to verify your page fails on a fair few points, all of which point to the comments. Just a minor point...!
19/269
Bob commented on 27 January 2005 @ 21:10
Good work.
I have noticed that tags overlap incorrectly though, making it incorrect HTML, which is a shame.
If this could be fixed it would rock.
20/269
Michael Ward commented on 27 January 2005 @ 21:26
Ooooh... rocks!
Just when we're in the preperation stages of rolling out a large CMS - this might just hit the spot!
21/269
Koen commented on 27 January 2005 @ 22:51
I can only confirm what everyone else is saying: Neat, really neat!
22/269
greut commented on 28 January 2005 @ 02:31
Nice, simple but (for html validity) check this : https://bugzilla.mozilla.org/show_bug.cgi?id=54479
23/269
Raymond commented on 28 January 2005 @ 02:42
The MSHTML control has not been updated in years. Let it die. I use XStandard Lite, it free and it's standards compliant. For those who care about Safari, I hear a Mac version of XStandard is coming although I am on Windows so it doesn't affect me.
24/269
The Man in Blue commented on 28 January 2005 @ 03:22
I'm sure that XStandard is a great program, Vlad (one of the developers) hawks it a lot on the Web Standards Group mailing list.
However, I've never used it. Why? Because I have to download it separately. This doesn't make it viable for weblogs, etc. where people visit randomly, maybe to only view one page, and don't have a vested interest in installing plugins or the like.
25/269
Mike P. commented on 28 January 2005 @ 05:26
Great tool. I found that when typing away from a link, the link kept following me. Like this example, where I linked the work 'typing', but I can't make it stop linking!!
26/269
dusoft commented on 28 January 2005 @ 06:43
[24]: I agree really much. I don't like downloading anything either. I have used KEVIN RTE, but its cose is messy as you have mantioned.
[25]: That happens with most of the editors. The workaround is: press cursor twice after the link end (last letter), moving to the right, then once left. Start typing. It should be normal text without link.
27/269
Matt commented on 28 January 2005 @ 06:47
When this is GPLed I can make it a WordPress plugin for the masses. Will there be a way to toggle viewing source?
28/269
mattymcg commented on 28 January 2005 @ 06:55
Re: Comments #14 and #18 wrote:
> Do you have any plans to
> implement colors?
This would defeat the whole purpose of making it standards compliant. Colours should be handled in your stylesheet! If you assign different colours to different headings, you will get your different colours, only it will be controlled so that you can keep a consistent look and feel. As it should be.
Keep fiddling and troubleshooting Cam, it's early days but this is a winner and I look forward to seeing it robust and ready to take the world by storm!
Funny, the ' and / keys are functioning fine this time round. A one-off gremlin?
29/269
Darrel commented on 28 January 2005 @ 07:35
I also have to praise XStandard. Yes, it does have two major drawbacks: It's Windows only, and you have to install it.
However, I've found it to be the only one that reliably handles the differences between the two browsers.
For instance, this control, in Firefox, adds a BR tag on return, while IE adds a P tag.
That's not to belittle this editor. It's VERY nice and I'm glad to see another 'simpler is better' approach to the problem like this.
I wonder why we don't see more Flash based tools? I think XStandard took the right approach by controlling the logistics of the editor themselves rather than relying on the browsers. Flash would seem to offer that benefit, but also add the benefit of being cross-platform compatible and not dependant on a custom install (outside of the flash plugin).
30/269
Vincent commented on 28 January 2005 @ 07:57
Check this out, this is I think by far the best one you'll find out there. The implementation code, a breath. Compatibility? FireFox, Mozilla, IE...
http://www.fckeditor.net/
It's free and open source. Server Side implementation, ASP, PHP, etc...
Great :)
31/269
Ruy commented on 28 January 2005 @ 07:58
Hey hey very cool - it's nice to see an RTB where the code is actually legible (and therefore hackable!).
I have a question though: Is the magical property designMode the only way to get rich text editing to work? I was looking through FckEditor and it seems (emphasised because that thing's code is absolutely monstrous to read through) that they actually capture individual events inside an arbitrary element and then insert content based on that (i.e. you press "a" and it will add "a" to the innerhtml of the editing container - the caret and cursor are faked). It would seem that this would allow them to support many more browsers then just Moz/IE (but they don't). Actually, even if that isn't the case I'm wondering how feasable such an aproach would be.
And sort of off-topic but related, if anyone can figure out how on earth they got fckeditor to have a custom right click menu I will give them an eCookie and an eHug.
32/269
james commented on 28 January 2005 @ 08:25
i had a couple problems, first one was fairly simple to workaround but still a problem and that is if your textarea already has a class, adding a 2nd class of widgEditor doesn't enable the functionality.
the 2nd problem i'm having is getting the widgEditor to appear for more than one textarea on my page
33/269
james commented on 28 January 2005 @ 09:19
ok i fixed that by changing the variable used to iterate through textareas from i to itm since i seemed to be getting set to something like 17 after exiting out of widgEditor's constructor. I still only had 2 out of 3 textareas converting, so after some experimentation i rmade the code iterate through the textarea collection twice, and that worked.
34/269
The Man in Blue commented on 28 January 2005 @ 09:43
Matt [#27]: It has a view source button at the moment, DO you mean are you able to disable it? (You can by changing one line in the configuration at the top of the JS)
James [#32]: Yes, I use a rather lazy class name detection method, I'll fix it up for multiple classes ... And have a look into multiple textareas.
35/269
Ryan Brooks commented on 28 January 2005 @ 11:12
I agree with you, Xstandard definately has it's advantages... And downloading the cab file is definately a downside... But I DO know there's a redunacy option, for non-windows/ie/firefox browsers... I mean, most of the others produce crap that has to be cleaned up with something like Tidy? Why not just write it once the first time.
Anyways, major, MAJOR kudos to this system we've got going on here... I'd be very interested to hear where this is going.
-Ryan
36/269
Lachlan Hunt commented on 28 January 2005 @ 11:24
It's quite interesting, but there are still some fatal problems encountered with this editor, much like HTMLArea and Rich Text Area.
The problem is that it's much too presentationally oriented for any descent use on a web log. There's no buttons for strong, emphasis, code, kbd and other semantic inline elements; yet there are buttons for bold and italic included (which actually abuse span with a style attribute but that is no better than just the b or i elements.
There's also very few semantic block level elements, though it's good to see headings and paragraphs and lists. Though, there's a problem with nested lists, which should appear as a descendent of the previous list item, not a sibling.
Finally, there's no ability to set classes or ids without editing the source, though that would be a little more advanced than just elements so I could live without that.
37/269
boxed commented on 28 January 2005 @ 12:06
What type of "open source" do you mean? I'd like to include this in my SKForum web-app (which is released under public domain), but I need to know what kind of license you're releasing this under.
38/269
Greg commented on 28 January 2005 @ 13:50
Hmm, well, when in Firefox 1.0, when scrolling down the page, if the cursor moves over the textarea (I'm sure triggering a hover event), it:
Other than that,
Thanks,
Greg
39/269
stylo~ commented on 28 January 2005 @ 15:26
Have to agree with lachlan about using spans for bold and italic instead of em and strong. Bad idea.
Also about the inability to attach a style to tags.
I find it easier to have a half-baked htmlcode editor on my admin section (no comments onsite), but I've been keeping an eye on this one: http://tinymce.moxiecode.com/
40/269
The Man in Blue commented on 28 January 2005 @ 15:59
I think the key here is simplicity.
As I noted at the top of this entry, there's plenty of editors out there that do lots of stuff. Lots of them do too much stuff. I find that most of the options they offer are superfluous -- colour, justification, fonts -- these are the sorts of things that most people use to make e-mails look terrible. Seriously, how much styling do you need to make a generic web page entry? We're not talking about designing pages from scratch.
Additionally, most of them aren't that easy to install or modify -- tinyMCE still requires you to put in a config string at the top of your HTML document, and if you ever wanted to make a simple change to the code, good luck. It's 98KB without newlines or comments (133KB with).
Sure, they're still good products, but they're not what I'm aiming to do.
I will have a think about some of the suggested features, but if they don't have any tangible benefits, then I won't put them in.
41/269
stylo~ commented on 28 January 2005 @ 17:57
I agree about the size and ease of others, and code inserted is often crappy. Itried fck and took it out.
If you add the two I noted, I'd be very happy with it. Just what I've been looking for. As-is I use my own little hackneyed htmlcode editor (not wysiwyg) to insert tags, or popup and ask the class name I want, which is then inserted via selectionStart, createRange(), etc.
EDIT: OK, I see now your editor replaces the span formatting with em and strong before submitting it. You might note that as I and lachlan I assume were checking the html and commenting on that. Just need styles and it would be pretty good!
42/269
stylo~ commented on 28 January 2005 @ 18:12
43/269
Yoyo commented on 28 January 2005 @ 18:24
Good work.
Today I tested it and:
- view sorce is working (IE/Firefox)
- spans replaced with em or strong
- multiple fields with class="widgEditor" not working
- using firefox I coul not make bulleter list in this comments box - I went to top of page ;((
At the moment I'm using modified RTE, because it was simplest cross browser editors. Now seems that this editor could be better, but there is still lot of work on bugs (not new features)
44/269
Unearthed Ruminator commented on 28 January 2005 @ 22:27
Very nice tool. It works wonders on these comments - Howver, it would be cool if the images changed to let you know what button was selected (so you could know if you turned itallic back of without having to type something.
45/269
Lachlan Hunt commented on 28 January 2005 @ 22:37
I hadn't realised you were replacing the bold and italic formatting with strong and em when submitted, though I don't know why you don't just add strong and em to begin with. I'll take a look at the code later on when I have time, and I'll see what I can do about fixing it up.
46/269
Phil Thompson commented on 29 January 2005 @ 00:53
'tis a good little mover and there's no doubt. but, it would be nice if paragraphs were the default and not br tags. i think it's particularly sweet the way you can add headings and the like could make web editing for novices a breeze.
Also when you press return twice after a heading, it should revert back to p tags and not br's inside the heading tag. Those changes would make it idiot proof and valuability usuability commodity. keep up the good work.
47/269
Ross commented on 29 January 2005 @ 01:47
I like the simple approch, hope you can keep the focus and avoid the bloat.
Not sure if it's possible, but it would be great if it could leave code untouched (eg php code)
Cheers
48/269
Steven Hayter commented on 29 January 2005 @ 04:44
Only thing I spotted is that it does produce things like </strong><strong> when I think they should cancel eachother out when it's being pulled from a wysiwyg input.
49/269
Jeremy Curry commented on 29 January 2005 @ 05:33
Looks awsome. Haven't done much testing, but works great on my FireFox. Eventually, I'll look foward to using this...
50/269
Shawn Rice commented on 29 January 2005 @ 06:24
I built a site using a Textile type solution so that any user should be able to mark-up text. But, the client found out about these WYSIWYG editors and demanded we have one on the site. I warned him that not every browser could use it and the code it produces isn't always that great. Still, he had to have it.
So, I've been spending ungodly amounts of time creating an editor that degrades to a simple textarea that uses Textile like markup. When a user submits the form I have to check to see if they were using the editor or the markup, fix the code if it was the editor and then do all the database saving, etc. If they're editing an existing document, I have to check if they're editor capable, un-markup the text if not or leave it be if so. When un-markuping (real word?) I have to take into account that the code produced by the editor and produced by the mark-up class doesn't really match, and thus have to account for whatever possibilities may come up.
It's a pain in the rear, to say the least. A simple editor that produces clean code would be a dream! Long story short, this is a nice start you have. Good work!
Oh, and editing the style of it all was wonderfully easy. Here's a quick Firefox-esque theme I threw together while playing:
http://zooley.net/foxy-wysiwyg.png
And the images and modified stylesheet if anyone wants it.
http://zooley.net/foxy-wysiwyg.zip
51/269
Bill Rawlinson commented on 29 January 2005 @ 07:34
Not really much to say except that I like the unobtrusive nature of your installation.
I'm using FireFox 1.0 and don't see the viewsource button - and nor do I see the right click menu that someone else mentioned.
Anyway, I really like what you have going here and look forward to its more stable release.
I currently use RTE in a project I am working on. I wrote a ColdFusion wrapper for it so installation is pretty easy. However, I am always eager to try out things that can lead to greater standards compliance.
Thanks for working on this.
52/269
Jason commented on 29 January 2005 @ 21:44
Now we're cookin'!
I can see this being really useful.
XStandard is a good product, but it is a plugin, and in some cases it provides too much control. I think you're on a winner here in providing a simple interface - there are lots of complicated ones on the market already - we don't need another one.
There's maybe one one other button I'd think about including, and that's "insert image". Other than that I wouldn't put too much more user controls in.
Good work... and thanks!
53/269
manuel commented on 30 January 2005 @ 05:22
Hey, a fkn great job here, really!!
Some more block elements would be nice, particularly blockquote. And (agh) for a CMS, MS Word copy/paste is a must.
54/269
Stian Grytøyr commented on 30 January 2005 @ 06:15
Regarding multiple textareas, which is a must-have for me as well,the problem seems to lie in widgInit(). Essentially, the problem wasthe theTextareas.length changes as you replace them. Also, the ivariable seems to change in unexpected ways.
I've hacked together a version that seems to deal with multiple areas just fine.
Also, I've added buttons to enlarge and shrink each area, which is always handy.
Feelfree to use the code/graphics if you like. If you decide to use thecode it's probably best to do a diff, as I may have changed things hereand there. Also, I'm no JavaScript expert, so look out for silly bugs :)
Thanks for creating widgEditor, Cameron. I've been looking for something like this for quite a while.
Excellent work!
55/269
Jeroen Sen commented on 1 February 2005 @ 00:07
Thnx, for investing time Cameron! I have been looking for ages for a WYSIWYG - html editor with only these features, one word -> GREAT!!!
56/269
Lars commented on 1 February 2005 @ 01:14
Nice try, but is it truely possible to make something small that works on all platforms the exact same way ?
I don't think so...
That's why all well known wysiwyg editors are such a big mess.
IMHO the best way to get things small (speaking only of an admin interface with some features, not speaking of a small comment interface) is to code only for one browser...
By the way, I found a small bug : when you convert a line from P to H1, the italics and bolded text are lost.
2nd bug :When you use widgEditor in Firefox, and type ENTER, the P are not made automatically.
Good luck anyway in the cruel world of wysiwyg editors ;)
57/269
Peter commented on 1 February 2005 @ 04:45
Another problem: using Firefox on Windows XP, when I hit the "View Source" button after making the original content entirely non-bold, I get to see the original source. When I then return back to WYSIWYG view, the original sentence and markup are back. Very annoying.
For the rest, it's quite a decent WYSIWYG editor. Good job :)
58/269
JJ commented on 1 February 2005 @ 06:06
It still got problems with nesting tags: too much tags, a matter of too much tags, but all WYSWYG-editors have this problem (HTML-tidy would be a solution?). Sometimes it becomes even impossible to 'un-strong' a part.
Have a look at TinyMCE, still the best one I came across.
59/269
Ray commented on 1 February 2005 @ 08:02
Hi
Just want to say - keep up the good work. It's fantastic. There will be bugs, but it seems that there are a lot of people ready to support you.
Cheers
Ray
60/269
Kevin Cannon commented on 2 February 2005 @ 01:47
This is really cool. it's exactly what I've been looking for.
Only thing I need that needs modifying before it could be used on clients is the linking. Particularly the ability to remove linked text.
Good job - looking forward to future improvments!
61/269
Tom commented on 2 February 2005 @ 17:45
Hey, your widgEditor is absolutely great! This is even better than what I had planned to write somewhen...
And this is my joy at the editor before I've even had a look at the source code! Well done!
62/269
Hans Adam commented on 3 February 2005 @ 10:44
fanastic work!!
63/269
Tobias Buschor commented on 3 February 2005 @ 10:47
Very good, your widgEditor!
I have only one problem, i can not use the name-attribute of a textarea as a Array. It will send "true" and not the content.
64/269
Nathan Tarter commented on 3 February 2005 @ 14:02
Bravo!I'm impressed. Now I just have to come up with
65/269
Paul Sculthorpe commented on 3 February 2005 @ 20:52
This is fantastic!
For anyone interested, I went into HTML mode and added an image, went back to WYSIWYG mode and could resize the image with resizing handles, nice.
An insert image function would definitely mean I'd replace all our TinyMCE CMS stuff with this. It's ideal for our clients needs and loads up nice and quick.
I like how it uses no external popup windows, just Javascript popups.
Keep up the good (simple, graceful, speedy) work!
66/269
John Elliott commented on 4 February 2005 @ 02:04
This is brilliant work. I've been playing with TinyMCE lattely - which is my favourite of these things so far, but it is still a lot of difficult code...
The code for this is lovely and clean, and I bet it would be very easy to extend with say an image insert menu or a a drop down for applying styles to elements.
Best off all I can read and make sense of the code.
67/269
Kevin Cannon commented on 4 February 2005 @ 02:41
Hey,
Looking at this more & more, it's really great. You accept donations for using it?
Another small thing, if you pop in a euro symbol € is doesn't encode it properly, and if you put it in the HTML, and switch between views twice it looses the encoding during the switch.
Not a major problem, but might be worth noting.
All the best!
68/269
Vik Rubenfeld commented on 4 February 2005 @ 09:16
This is very cool. It's gotten favorable notice at the Expression Engine forum.
Is there a way to add a button that would put html blockquote tags around the selected text?
69/269
Patrick commented on 4 February 2005 @ 21:10
Very nice. Great, clean code - I've spent this morning adding extensions ;-)
Cameron, can you clarify what sort of license you're releasing this under? I'd love to use an amended version for some GPL work I'm doing...
70/269
lars commented on 4 February 2005 @ 21:15
Reply to kevin (comment 67):
try changing the HTML META TAG "encoding" from iso to utf-8
in fact i dunno if the file itself has to be saved in utf-8 after having done this... :/
a workaround is possible when you serve your pages with php, using some functions like utf8encode (and so on)
from what i know encoding is a big mess to cope with on the web
71/269
stylo~ commented on 5 February 2005 @ 18:26
Better with the update!
I noticed switching source view adds entries to history (back button), though. That can be cancelled with js.
72/269
DirtPupFC commented on 9 February 2005 @ 14:21
widgEditor getting some play over in the blosxom world. Thought I'd let you know that I replaced the textarea in blosedit with widgEditor and turned some blosxom folks loose on it. They quickly noted the Safari missing textarea problem, but also noted a couple other things:
If you're interested in seeing it in action, visit:
http://mike.thegreiners.com/cgi-bin/be2.cgi
...and login using guest/guest.
You're off to a very nice start.
73/269
The Man in Blue commented on 9 February 2005 @ 14:34
Thanks Mike.
There'll be a new update this weekend.
74/269
jaytech commented on 11 February 2005 @ 20:28
It's a good & simple editor , yet it has a feature ,common to many editors I've seen , that in my opinion it's a bad one.
After you type something and then delete all the text then the html code shows something like this <p> </p> insted of nothing.
75/269
metaphaz commented on 11 February 2005 @ 22:32
Nice... I'm occasionally loosing text upon switching to html view here on firefox (I think this particular problem only effects moz browsers) added timers at various points to attempt to alleviate the issue, but nothing worked so far. Anybody have any luck with that!
Possible perhaps to replicate the text in a "backup" of some kind.
76/269
Chris commented on 12 February 2005 @ 01:05
Hi! I really like the script but I have one major problem. My form don´t submit when I´ve entered a certain amount of characters. No errors, it just doesn´t submit. And I´ve checked that all functions returns true. I´m clueless!
77/269
Colin D. Devroe commented on 12 February 2005 @ 05:16
Followed the instructions implicitly, and the "editor" simply will not show. No errors, text area remains functional, just no editor. Any ideas?
I've set the id to the name of the field and the class to widgEditor and uploaded the widgEditor.js and widgEditor.css respectively. And, refrenced them in my pages heading.
Not sure where to go from here. Any help would be much appreciated.
Admin: see comment #116
78/269
Colin D. Devroe commented on 12 February 2005 @ 05:18
My textarea is in a table, does that matter?
Admin: see comment #116
79/269
Colin D. Devroe commented on 12 February 2005 @ 05:22
Oh yeah, and my textarea names resemble: id="product_description[1]" name="product_description[1]"
Not sure if that matters.
Admin: see comment #116
80/269
Ray commented on 13 February 2005 @ 07:53
Works perfectly in IE, but can not get it to work in Mozilla. Displays fine, but when I submit a form, everything gets stripped out and nothing gets added to my database (my server side valiadation picks up the text area as empty).
Anyone else having this problem?
81/269
Nathan commented on 16 February 2005 @ 12:13
I love it, love it, and love it...
There are a couple of small glitches but you have done a fantastic job, one thing that I am finding is the iframe is flashing when I hover over my sidebar navigation even though the sidebar is a completely separate entity, it somehow seems to be interfering.
It's a fairly simple menu using unordered lists and CSS hover states.
This is only a problem in FF1.0, no probs in IE. Any suggestions as to why this would happen.
82/269
Nathan commented on 16 February 2005 @ 19:20
Hi me again.
I Hate to do this because I love this thing so much, but when I use a reset button in the form that contains the widgie it only resets the fields I have added, not the widgie itself.
Don't know if anyone else has had this problem, if any help would be much appreciated!
83/269
Nathan commented on 16 February 2005 @ 19:27
Me yet again.
The reset button works fine in source mode but not in WYSIWYG mode, I assume this is due to the Iframe.
Sorry, I hate to brign bad news... Though I can probably go without a reset button anyway!
84/269
Jonathan Snook commented on 17 February 2005 @ 01:43
Nathan: The reset button simply resets the values in any form fields. Because the WYSIWYG view is not a form field, it never gets cleared.
Cameron: to have this work, maybe add an onchange handler and then when the event fires, reset the wysiwyg view to match the textarea.
85/269
Tom commented on 27 February 2005 @ 08:36
Just barely started poking around the code, but one enhancement that would be great would be to allow custom classes in the block select.
For example, I can have
widgSelectBlockOptions.push("<h5>", "Subsection");
And that works fine. What I can't do is
widgSelectBlockOptions.push("<h6 class=\"subsection\">", "Subsection");
or
widgSelectBlockOptions.push("<span class=\"comment_author\">", "Author Name");
If I do that, the code it generates is
<<h6 class="subsection">>Subsection</<h6 class="class1">>
And then on successive iterations of view source, it will convert the < into &lt; and so on.
86/269
Tom commented on 27 February 2005 @ 08:37
Whoops. The "class1" part is from my cut and paste error. What it generates is
<<h6 class="subsection">>Subsection</<h6 class="subsection">>
sorry for the confusion
87/269
The Man in Blue commented on 28 February 2005 @ 16:06
There are no further planned feature add-ons for widgEditor. It will now only be updated for bug fixes.
88/269
George Payne commented on 1 March 2005 @ 04:23
I was working to integrate widgEditor into a forum, where I do not necessarily have control over the html I inherit. Anyway, I've noticed that widgEditor seems to freak a bit when it gets this code:
<ul type="1">
The cleanup routines remove the 1 (number 1) and turn the tag into
<ul type="">
89/269
The Man in Blue commented on 1 March 2005 @ 11:26
Re: #134
That's because there's no such value as "1" for <ul type=>. It's invalid.
90/269
Tae commented on 2 March 2005 @ 01:21
i got this code from just adding a line break before the last word:
<p>widgEditor <strong>automatically</strong> integrates the content that was in the <br />
</p>
<h1>textarea!</h1>
can the br tag be stripped out whenever there's a closing p tag right after it?
91/269
Tanny O'Haley commented on 2 March 2005 @ 05:21
instead of:
<p>This is a test to see what the <strong>WYSIWYG</strong> editor does with Word <em>pasted</em> into it.</p> that Firefox creates.
I noticed that you're not providing any more features. I would really like to see blockquote added. Actually I would like to see common elements like sub and supper script, and inline quotes added too. I'm really looking forward to version 2. You've done a wonderful job.
92/269
Stephen O'Brien commented on 2 March 2005 @ 21:44
Excellent work, I think a lot of people agree that this was needed.
What I'd like to see:
* Better <br /> stripping in Gecko
* Better empty <p> stripping
* A few more tags in the "change block type" box, eg <blockquote>
93/269
Andrew commented on 3 March 2005 @ 06:27
Great Tool! Just one issue (isn't that always the case?), I originally added a toolbar button for Strike Through, which I find to be very useful when editing text. I can still add the button, but because the system strips out span tags, and to add a strike through the system uses <span> when I save or switch to HTML it gets stripped away. Even if I add the <span> tag in the code view it doesn't stick. I also noticed that if you paste in code with any span tags in it - it also gets stripped out. This makes it hard to really use CSS to style the text. Thanks for the great tool, it has really changed the way my work flow and the way I organize myself. Cheers.
94/269
George Payne commented on 4 March 2005 @ 12:28
One troubling side-effect in Firefox/Mozilla is that redirects are broken by widgEdit. Eg, if you go to a page with widgEdit, then go to any page on the same site with an http-equiv refresh, it will not work. Very odd. Related to iframe history issue?
95/269
The Man in Blue commented on 9 March 2005 @ 03:56
Re: Andrew (#93)
It's better not to use inline spans for strikethrough anyway, as it's semantic data, see:
http://www.themaninblue.com/writing/perspective/2004/12/13/#comment1
96/269
HarleyPig commented on 9 March 2005 @ 10:29
I'd like to customize this script (especially since it's no longer being updated, just maintained) but am running into trouble modifying/adding buttons and select boxes. I'm having similar problems as the one mentioned in 130. I additionally tried putting "variousblockelements" instead of "<variousblockelements>" in the widgSelectBoxOptions but that just caused other oddities.
Anyone got any pointers?
97/269
Tim commented on 15 March 2005 @ 03:26
Great tool!
It was just what I needed to satisfy a client!
Thought I would just share the following.
I added a <base> tag to the Iframe template (with a variable set at the beginning of the code along with the css variable). The reason being that in my website the admin area (and therefore pages using widgEditor) sits in its own admin folder. This means an inserted image won't display if you use a relative url.
Cheers
Tim
98/269
Milton Keynes web designer commented on 16 March 2005 @ 02:06
Oh this is good!!
Bring on the simplicity. I have been searching around for two days and ended up spending all morning hacking around with FCKeditor. This, however, is exactly what I was after.
Thank you!
99/269
Chris commented on 17 March 2005 @ 07:29
Awesome! I had been loathing integrating htmlArea into our home-grown CMS. I needed something simpler. I was going to write my own WYSIWYG editor, but you've saved me the trouble!
You, sir, kick ass. Thank you so much!.
100/269
Bill Hovingh commented on 18 March 2005 @ 01:02
Here at my shop, we also need something that in addition to correcting the dreaded Word CrapTags™ will also clean up the even-more-dreaded CP1252 Crap Characters™. That will be as simple as a series of RegExp replacements of the form
pasteContent.replace(/\u0097/g,"“")
I'm working on adding that in now. Do you want me to send you what I end up with?
101/269
The Man in Blue commented on 18 March 2005 @ 01:31
What are the CP1252 characters?
102/269
Bill Hovingh commented on 18 March 2005 @ 02:48
The Microsoft CodePage 1252 (Windows Western) character encoding improperly uses most of the reserved control-character code points in the range 128-159 to represent certain typographical symbols and other special characters. For example, the codepoint 151 (which would, again improperly, be represented as an HTML numerical entity —) displays the em dash character. The correct named HTML entity for this is &emdash;, but even that doesn't get rendered properly in some browsers. Other offending characters that are very frequently imported in cut-from-Word, paste-to-IE operations are the curly quotes.
The solution, I've found, is to replace each instance of an offending character (i.e., one represented by a code point in the "forbidden" range) with its HTML numeric entity. This is easily done with regular expressions, and that's what I'm working up now. Since you're offering widgEdit under the GPL, I'll gladly offer it as a patch if you want it.
103/269
Alec commented on 22 March 2005 @ 12:13
The best of the sophisticated editors is WYSIWYG Pro which I've used for some Mambo installs. It costs a little money but is very good value (about $50/site, which is fine for commercial installs).
I tried HTMLarea, Rich Text Editor, tinyMCE and none of them were easily customisable and/or provided the ability to strip functionality. tinyMCE was the most elegant but meant that every page was carrying lots of extra baggage and any time HTML code was pasted in it was stripped of essential tags. Rich Text Editor was too difficult to customise and too ugly. HTMLarea was just a mess.
As soon as anyone has widgEditor working in Mambo, let me know as I would like to give it a whirl.
The biggest downfall WYSIWYG Pro has is with Javascript. It's better now but has a tendency to mangle it.
Thanks Man in Blue.
104/269
George Payne commented on 23 March 2005 @ 07:26
Just FYI, I've submitted mods to mvnforum to include widgEditor as an optional editor. The developer says the mods may be in the GA release. It suffers a bit from the Mozilla redirect issue I mentioned above, but I think widgEditor makes a pretty nice addition to the forum. See mvnforum.com if you're interested.
105/269
Mathias Bynens commented on 26 March 2005 @ 03:39
Great script. I'm digging Matt's WordPress plugin. I think I found some small bug in the widgEditor, though: when editing text with entities in it, then viewing the HTML source, the entities aren't translated to their HTML code.
106/269
Mark J commented on 26 March 2005 @ 05:19
I'm also interested in widgEditor's integration into WordPress, but I've noticed that lists are still not always valid XHTML.
Steps to reproduce:
1) Create three lines:
item1
item2
item3
2) Select all three lines and click the "list" button
3) Select the middle item ("item2") and tab it over (which should make it a child of "item1." But if you examine the code it produces, "item 2" is contained within a UL that is a direct child of the top UL, instead of being a child of the "item1" LI.
107/269
Thibaut Allender commented on 27 March 2005 @ 23:03
thomas, "target" attribute is deprecated in some DTDs (like xhtml 1.0 strict) so i guess it's impossible ;)
you'd rather use, if you still want to force a new window (anti-ergonomic but...) <a href="blah" onclick="window.open(this.href); return false;">blah</a>
which can be achieved with some regular expressions *after* the user has submitted his content.
108/269
Thomas commented on 28 March 2005 @ 07:08
Thanks Thibaut!
109/269
Tom commented on 29 March 2005 @ 05:38
Is anyone else out there having difficulty with widgeditor and Firefox 1.0.2 on the Mac?
Works great in FF 1.0.2 win and IE 6 Win, but seems to hide the content of my textarea about 1/2 of the time. If you submit the form at this point, of course you lose all the content.
We didn't see this behaviour with FF 1.0.1. I'm not a javascript wiz by any stretch, so any assistance is appreciated.
110/269
Tom commented on 30 March 2005 @ 05:03
Regarding my earlier post about firefox 1.0.2 problems, it looks like I had something corrupt in the profile. Starting clean with a new profile and it all works groovily.
Great little editor. :)
111/269
Crowdog commented on 31 March 2005 @ 08:00
I'm having the same problems as Tom (comment 168-169). Firefox Mac is causing widgEditor to drop the text that's in the textarea when it loads. Unfortunately I have no idea how to "start clean with a new profile" because I can't find any reference to profiles in Firefox at all. How did you create a new profile?
Also, I'm just now noticing a new problem - every time I type an apostrophe, FF's search bar opens and puts a cursor there so the next character I type, FF starts searching the document for. Annoying!
112/269
n/a commented on 1 April 2005 @ 01:28
Firefox profiles:
http://kb.mozillazine.org/Profile_folder
113/269
Ryan commented on 2 April 2005 @ 09:14
I'm having some problems with the editor using Firefox for editing stuff.
basically I set up the text editor then put
" echo $contents;" in before I close it up (i'm doing PHP)
The Contents go in ok but whenever I submit the code it appears to be blank. It works fine in Internet Explorer. Is it a firefox problem or a widgeditor problem?
Otherwise it's a brilliant product, the best I've ever seen at being a nice simple content editor suitable for launching at untechnical people. Thanks.
114/269
Joseph Dakroub commented on 17 April 2005 @ 01:49
Safari 1.3 (part of the 10.3.9 update) has support for contentEditable and designMode. However, widgEditor and all other WYSIWYG editors do not seem to be working with it.
Please readhttp://weblogs.mozillazine.org/hyatt/ for more information.
115/269
Ryan commented on 17 April 2005 @ 06:56
I think I can help with the FireFox problem I reported earlier (113). I got the error "theForm has no properties" using the Web Dev. Toolbar in Firefox. Is this any use to you guys?
116/269
The Man in Blue commented on 18 April 2005 @ 01:56
Re: #115
Thanks for the bug report. The code assumes that the form is two levels up from the original textarea. I assume this isn't the case with your HTML?
Will update with fix soon.
117/269
The Man in Blue commented on 19 April 2005 @ 04:35
Comments that:
Will be deleted, as they do not help other users.
If you really need help, contact me.
118/269
Matt Bailey commented on 19 April 2005 @ 19:55
Great script - thanks. Just installed latest version of Safari (v1.3) and noticed that the widgEditor toolbar now appears, but still doesn't work (I think - haven't tested it properly yet). It might be that your code simply needs a bit of tweaking.
The guy who created Safari says this on his weblog:
"HTML Editing
Safari 1.3 supports HTML editing, both at the Objective-C WebKit API level and using contenteditable and designMode in a Web page."
119/269
Matt Bailey commented on 19 April 2005 @ 20:50
Another quick question; I'd like to set the font type and size displayed in the text area, like you have on your example page (rather than have it default to Times), but I can't seem to find the right CSS class. I thought it might be something like this:
.widgContainer textarea.widgEditor p { etc...
Doesn't seem to work though. I'm sure it's a really simple solution. Can you help?
120/269
The Man in Blue commented on 20 April 2005 @ 00:36
Styles for the content contained in the editor are contained in css/widgContent.css.
If you wish to change the location of this file, the directory path can be modified in the config variables at the top of the widgEditor.js script.
121/269
Dan commented on 20 April 2005 @ 07:37
I don't think any one has mentioned this bug yet, but I'm not sure.
I can't exactly figure out when this happens, but for example, on the: sample page in WYSISYG mode, if you highlight the sentence, then make it bold and italic, and then submit, the bold and italic formatting is lost.
122/269
Sean commented on 22 April 2005 @ 05:56
Sorry, posted that using Safari...
Safari 1.3 (and 2.0 I would assume) now supports contentEditable="true" according to this post.
Does this change anything in the way of Safari support?
123/269
The Man in Blue commented on 22 April 2005 @ 13:48
Yes, Safari should be able to support widgEditor now, but I'll have to get the new version and check it out. Could take a while.
124/269
Phil Thompson commented on 25 April 2005 @ 21:54
I'm getting some issues in IE whereby the closing </li> is being removed from unordered list items.
Insituations where the textarea already contains some HTML, on submit in Internet Explorer 6 the </li>'s disappear but, the </ul> remains intact.
This can rectified by highlighting the list, clicking the unordered list button to remove the list and then clicking it again to restore the list.
125/269
Michael Winston commented on 27 April 2005 @ 08:55
Okay, this is brilliant. I will be using this with Safari/Firefox in a PHP development environment. Here's my feedback:
1) If the original textarea's name is in php-array-parsable form (e.g. name="content[user][description]") then the additional sanity-check element added around line 241 causes a conflict, and overriding, of the document's value because the name is "content[user][description]WidgEditor" . Php interprets this as the same as the original and overrides it with the text "true". Removing that line (241) fixes it and seems to have no adverse effects).
2) Safari (yes, it works in the new Safari) doesn't properly execute some javascript on submission. Instead of wrapping the text in <p></p>, it wraps it in "function (match)
{
return match.toLowerCase();.....".
So you might want to look at that.
3) On line 594 (detectPaste): Does ctrlKey function the same for a Mac (which uses "command", not "control")? I don't know enough js to tell, but you might want to add some if it 's different.
4) Did I mention this is brilliant? It is. You are a genius. I'm going to customize mine to add underline, superscript, subscript, strikethrough, and keyaccess support for the buttons.
Thanks for all of your hard work!
126/269
The Man in Blue commented on 27 April 2005 @ 13:06
The bug in Safari 1.3's output is due to the fact that it has incomplete support for JavaScript regular expressions. I'm trying to figure out a way around it at the moment.
127/269
Sean commented on 29 April 2005 @ 01:32
Does anyone else have this problem using FF on Linux where all of the Widg content jumps out of the box -- kind of flickers a few hundred pixels away from the box, then settles in? This happens when the page first loads and also when ever I do any edits with the toolbar (such as click the 'bold' button). Anybody else?
128/269
Rich commented on 29 April 2005 @ 03:30
Hi There,
Brilliant piece of code!! I am now a complete Javascript convert! (Who'd have thought it was only good for rollovers!?!?)
However, I've tried to use it on a secure page and i keep getting a 'there is insecure content on this page - do you want to display it?' message. I've converted all the URS to absolute secure urls i.e. https://, but it doesn't seem to make a difference. I've narrowed the problem down to the generation of the iFrame (i think ;o) ).
Have you got any ideas on how to overcome this?
Cheers
Rich
129/269
The Man in Blue commented on 29 April 2005 @ 05:07
No, don't know any way to get around https:// & iframes, though I haven't tried.
I'd assume that anything with an iframe in it would probably set off an alert, as it might be possible to circumvent the secure protocols with them.
130/269
Sean commented on 29 April 2005 @ 11:33
Oh no really?! So does that mean that as soon I put this stuff I'm developing on an SSL secured page, the user will get SSL warnings? Am I missing something here because this seems like a really big problem, no?
Also, if anyone has any ideas about my post above (#127) with spastic content, I'd be most grateful!
131/269
Rich commented on 29 April 2005 @ 19:45
Ok then, thats a real shame!
If anybody knows of a workaround please do let me know. It seems the iFrame is generated dynamically, how about if it was pre-made and referenced through https?
Is there any alternative to the iFrame?
132/269
Aaron commented on 30 April 2005 @ 05:30
I am having the same problem with firefox and the spastic content.(post #127)
In IE the insert image feature seems to put the image in the top left corner after inserting it, not into the textbox(sometimes).
133/269
Ryan Thrash commented on 30 April 2005 @ 05:56
Any one having any luck getting this to work "properly" in Safari yet?
134/269
Sean commented on 30 April 2005 @ 16:40
Any chance we could talk you into (or help you) setup a forum? It would only need a couple of categories, maybe 'general discussion', 'installation issues', and 'support issues'. The thing is, I think a lot of questions on this board would have a much better chance of being seen (and maybe answered), if there were threads for each topic. For example, I've been asking about the spastic Firefox thing, others have talked about HTTPS issues, and Safari support seems to be a new hot topic. We need threads man! I'll help! sean - nospamplease - datafly -dot -net
135/269
The Man in Blue commented on 1 May 2005 @ 01:06
Yeah, except I'm the only person who does any development on it, so putting it in a forum isn't going to speed things up.
136/269
Greg_K commented on 2 May 2005 @ 01:46
any chance of a BBcode version?
I took a look, but theres a ton of code to get rid of too. Its not going to be a easy as I had hoped.
BBwidg does have a nice ring to it :)
If anyone is interested in helping create one? contact me thru my website link & I'm ready to do all I can do to help.
Widg rocks ;)
cheers
137/269
Phil Thompson commented on 2 May 2005 @ 19:27
In regards to the spastic content, I have had this as well (only in Firefox on Windows XP) and only when the form is set to float in CSS, removing the float fixed it; so could that your problem?
In my case the spastication occurs when typring in a paragraph or header format but, if I am typing a list, there is no problem whatsoever.
138/269
Aaron commented on 3 May 2005 @ 10:50
Has Anyone an issue with IE where upon inserting an image the image is inserted in the top left corner of the screen, instead of into the textarea? It works fine in firefox. Thanks.
139/269
Aaron commented on 3 May 2005 @ 11:35
Ok I apologize for posting on this page so many times with questions, this is not really a forum..but I narrowed down the problem to when inserting an image in IE if the widgeditor does not have focus (the user has not click in the text box) then the image in the top left problem occurs. I a way to give the focus to the textarea upon clicking on the insert image button
Thanks
140/269
sean commented on 3 May 2005 @ 18:03
[SOLVED!] About the spastic content problem in FF, as soon as I got widgEditor out of its CSS float elements (as suggested above), the problem was solved. In order to keep my CSS layout, I just edited the widgEditor.css and set a big left-margin to make room for my left-side navbar. I think this workaround will work for anyone having this problem.
141/269
Chris Mc commented on 3 May 2005 @ 20:26
This is exactly what i have been looking for. I was having troubles with people pasting straight from word. Which was VERY messy. Ive changed the code slightly so it doesnt prompt when someone copies text in.
Fantastic!
142/269
Rich commented on 5 May 2005 @ 01:38
[SOLVED SECURE IFRAME PROBLEM]
Hi There, i've been trying to fix the problem with 'there is insecure content on this page - do you want to display it?' message for a few days now. The answer is to supply a fake src attribute when generating the iFrame, I found the solution at the following URL
http://scott.yang.id.au/2003/02/page-containing-non-secure-item/
Basically you need to add the line:
this.theIframe.src = "blank.htm";
where 'blank.htm' is a fictitious page. Add it just after the line:
this.theIframe.className = "widgIframe";
You need to supply this for IE to think it's loading a page and stop hassling you thinking it's a non secure iFrame.
Hope this helps!
Rich
143/269
Ben Nolan commented on 9 May 2005 @ 08:25
Hey Man In Blue,
Just to let you know I'm using widgeditor at foopad.com and it's awesome. Thanks heaps for the great tool.
I've done a fair bit of JS development myself, so if you need some help with development - feel free to give me an email ( ben at ripcord.co.nz ) and I'll try and help out. I'll have a go at fixing the safari bugs over the next week.
Cheers,
Ben
144/269
ChrisF commented on 9 May 2005 @ 23:55
I would really like to use the widgEditor in my project, but it seems to be disabled when using it on a modal dialog in IE (on Windows XP). Everything looks right, I just can't edit the text. Anyone else seen this or have any suggestions?
145/269
ChrisF commented on 10 May 2005 @ 01:47
Never mind. Google told me that design mode is not supported on a modal (why?) so I would have to simulate the modality.
146/269
Scott Teresi commented on 10 May 2005 @ 04:32
Just would like to second the request to add compatibilitly for Safari 1.3/2.0 WYSIWYG editing to WidgEditor!
(Another fan of your very well-designed piece of software, especially without the feature bloat that makes other editors so confusing.)
Scott
147/269
ChrisF commented on 11 May 2005 @ 08:11
BUG:
When I typesome text and then make part of it bold and and adjacent part italics, the space between them disappears when you submit. This is because of the code near the comment: "/* Remove all text nodes containing just whitespace */". Why is that code there?
148/269
Jacky commented on 12 May 2005 @ 01:33
I've got a problem when some of my guest posting using the Widgeditor, the javascript code appeared in the content, e.g.
function (match) { return match.toLowerCase(); }>十分認同最後一段，想令blog在香港興起，各位blog友便須努力。function (match) { return match.toLowerCase(); }>function (match) { return match.toLowerCase(); }>function (match) { return match.toLowerCase(); } class="khtml-block-placeholder">function (match) { return match.toLowerCase(); }>我曾經有以下經歷 — 我有一個英文blog，它是專為我的學生而設。我希望他們留comment與我一同討論時事。所以內容只談時事，甚少論及我的日常生活。過了一段日子後， 我發現有些學生在他們寫開日記的xanga內，開始post多了一些有內涵對時事作分析的文章。function (match) { return match.toLowerCase(); }>function (match) { return match.toLowerCase(); }>function (match) { return match.toLowerCase(); } class="khtml-block-placeholder">function (match) { return match.toLowerCase(); }>function (match) { return match.toLowerCase(); }>我會繼續運用我的影響力，令blog發揚光大。 function (match) { return match.toLowerCase(); }>function (match) { return match.toLowerCase(); }>
Any one also get this bug?
149/269
Nate Beaty commented on 13 May 2005 @ 15:19
I also get that javascript cruft when submitting a form in Safari 1.3.
Also, in the latest nightly build of Camino (haven't tried in the current Stable), an empty widgEditor-enabled textarea won't allow input. However, if you switch to HTML-code mode, type something in, then switch back to WYSIWYG mode, it allows editing. It also works fine if the textarea is pre-populated with text.
Thanks Cameron for this fine piece of code! I use it on many of my client admins..
150/269
Raul commented on 13 May 2005 @ 15:51
Jackie, I've heard of and seen this problem occur on a few occasions. Mainly for some Mac users. I'm not sure it's only them as I've yet to encounter this.
So yeah, I am curious about this issue too.
151/269
Jeroen Stok commented on 17 May 2005 @ 18:10
Great editor but....
Using IE 6.0.2 on XP:
152/269
Bobo commented on 18 May 2005 @ 16:53
"When typing text in the formfield the buttons above disappear or flicker constantly"
I second the motion! Please fix. OK in Firefox. BTW, great code.
153/269
bobo commented on 18 May 2005 @ 18:03
one more thing, when I insert a URL (e.g. http://www.google.com) it gets changed to <a href=\"www.google.com\"> why is it so?
154/269
John Elliott commented on 18 May 2005 @ 21:02
"When typing text in the formfield the buttons above disappear or flicker constantly"
The earlier versions didn't do it - I'd hazzard a guess that its something to do with the addition of Word CrapTagsâ„¢ removal in the most recent update.
Once again though the editor is brilliant.
155/269
jehoho commented on 19 May 2005 @ 02:07
Easy to install and easy to handle by the users!
But I found a bug wich has to do with the element name of the textarea element.
There must not be brackets like [...]!
Details:
To get arrays from my form data in my php-backend I create names with brackets like [...] for my form elements. Creating the form and the transformation to widgEditor works: I can see widgEditor on my website but it seems, that the transformation "back" does not work:
My former textarea element sends "true" and there´s no additional data from other elements: I cannot see data from widgEditor.
156/269
bobo commented on 19 May 2005 @ 09:41
""When typing text in the formfield the buttons above disappear or flicker constantly"
further to this issue, it seems that whenever I click in the textarea in IE 6.0.2, all the buttons reload. it makes typing in the textarea a challenge, to say the least.
157/269
Mathieu commented on 20 May 2005 @ 06:40
just reporting a problem I have, I dont know if its in the JS, or in my code, but sometimes (about 1/4 times randomly) the content of the editor disapear completly.
this happen, when the page load. I see everthing and then nothing when in finish his refresh.
I use the script from 02-28, with Firefox 1.0.4 on OSX
158/269
Frank commented on 21 May 2005 @ 01:21
Most features work just like a charm. But when editing the Source and adding the "lang" and "xml:lang" attributes and going back to WYSIWYG view they are deleted. However, when saving the page in source-view, they are saved, but only until you edit the page once again in WYSIWYG mode.
In Germany (where I am from) you need the lang-attribute with almost every tag, espacially <span>, <strong> and <em> ... would be great to be able to use it with widgEdit. Any ideas?
159/269
Peer commented on 24 May 2005 @ 08:21
hi cameron,
please don't stop the development of this great editor, he's the only one, i know, who build clean xhtml 1.1 code.
160/269
Sean commented on 25 May 2005 @ 13:52
Yes Mathieu (post #157), I've been having the identical issue. This is quite severe because if editor loads blank, then the user submits the form, it will submit the value as blank!!! (means people might accidentally erase all their content because of this bug).
It's such a serious problem that I've had to switch to another editor to avoid lost data for a Mac-centric client. We need Safari support, puh-leez?!
161/269
indi commented on 26 May 2005 @ 22:53
Is it possible to add tags that won't be stripped?
I, for example, am trying to use font face to write in another language (sinhala). WidgEdit adds escape quote to the "font-name" so that it appears as \"font-name\" and doesn't show up.
Is there a standard way to prevent the font tag (or others) from being modified?
162/269
Jay commented on 27 May 2005 @ 15:40
Preface: The run() function in widgEditor.js uses window.onload to conjure widgInit for designMode detection.
Abstract: We're trying to give focus to the first field in the form when the page loads like so:
<body onload="document.theform.firstfield.focus()">
Issue: When simultaneously using widgEditor and the onload attribute within the body tag, widgEditor fails.
How can we make this work?
163/269
The Man in Blue commented on 27 May 2005 @ 15:49
The code in the widgEditor run() funciton does not overwrite the window.onload event, it executes existing window.onload event calls before executing itself.
You should do the same with your script call. Inline JavaScript events are a bad idea, as can be seen in your case -- they overwrite the widgEditor call.
164/269
Chris Mc commented on 1 June 2005 @ 20:43
Hi there.
This is a fantastic script. Im having a play with it trying to add in my own features like adding in a smiley or graphic from a click.
However no matter what i try I cannot get it to fill in widg unless i click HTML view.
What I plan to do is have the WYSIWYG window and then have people add in image links from a popup window that contains thumbnails from my gallery.
I.e.
Id want something like this in my popup
<a href="javascript:InsertText('[img=http://www.google.co.uk/intl/en_uk/images/logo.gif]','noise')"><img src="http://www.google.co.uk/intl/en_uk/images/logo.gif" /></a>
Which would put [img=http://www.google.co.uk/intl/en_uk/images/logo.gif] into the editor.
(even better if there was a way it could mimic the copy paste function so we could see it)
Any chance you could point me in the right direction?
165/269
Phil Thompson commented on 2 June 2005 @ 00:51
Can you not just drag the images into the widgeditor window?
I've certainly done this with thumbnails on the same page as widg but admittedly not with a popup.
you could then the change the image code on submit via server-side scripting, so that widg shows the thumbnail and saves space but the html on your website shows the fullsize smiley image.
166/269
Chris Mc commented on 2 June 2005 @ 01:19
Thanks for the reply.
The gallery im on about has a couple of thousand images, so thats why id want them to come through a popup. It would also be nice to be able to customize what info was being sent to the editor.
I.e. click on image and i could send [img][src=http://www.image.com/car.gif][comments =redcar][url=http://www.image.com/gallery/][/img]
Which i could tie into a javascript link.
Basicaly i want to know how i can create a function to enter my own text into the editor.
I had a go but its throwing all sorts of errors at me saying it cant find editor or theIFrame no matter how much i try to pull it apart lol
167/269
david commented on 9 June 2005 @ 12:48
very nice work but I have to agree with the guys about the lack of a styles drop down
the version commented in:
http://tinymce.moxiecode.com/
is much more complete but is not as simple as this one which is very important when you want to implement it in a big CMS
man in blue: could you tell us if there is a plan for including styles in a drop down list?
168/269
Aaron commented on 9 June 2005 @ 15:11
Are older versions availiable?
169/269
The Man in Blue commented on 9 June 2005 @ 16:04
Are older versions availiable?
Nup.
170/269
Gorm commented on 11 June 2005 @ 09:38
Tanks! Finally a usable UI.
I tried to use overflow:visible on the textareas, but it doesnt do the trick of having the textareas expand.
- Any ideas?
171/269
John Elliott commented on 13 June 2005 @ 21:39
I've found a sort of solution to the Flickering buttons problem in IE.
I've commented out the lines 1335 to 1339 in the widgEditor.js file that loop through the menu list
This doesn’t seem to cause any problems, although I did get an intermittent error which I can’t replicate very well however this may be unconnected – I was pasting in large bits of text from word to see what happened.
I’ve checked it in IE6 on XP and Firefox and everything seems to work ok without these lines.
172/269
Derek commented on 16 June 2005 @ 21:30
Great piece of work - thanks!
I noticed an issue with Mozilla and framesets when using widgeditor. Sometimes the editor doesn't render at all and sometimes it just won't render on refresh. If you view the page out of the frameset it works fine.
Unfortunately I'm forced to use a frameset for my current project - does anyone know a way round the problem?
173/269
jehoho commented on 21 June 2005 @ 00:45
I wanted to change widgEditor´s frontend to another language.
Instead of changing all these english hardcoded text in the code to text in my language I created an array for language settings in the configuration variables.
Therefore it is much easier for developers to change from one language to another without crawling through the complete code.
An idea for the next version?
If you want to use the language settings change following in widgEditor:
1st step:
Put the following part into the CONFIGURATION VARIABLES:
widgLang = new Array();
widgLang['BLOCKTYPE'] = 'Change block type'; // line 117
widgLang['H1'] = 'Heading 1'; // line 118
widgLang['H2'] = 'Heading 2'; // line 119
widgLang['H3'] = 'Heading 3'; // line 120
widgLang['H4'] = 'Heading 4'; // line 121
widgLang['H5'] = 'Heading 5'; // line 122
widgLang['H6'] = 'Heading 6'; // line 123
widgLang['P'] = 'Paragraph'; // line 124
widgLang['CLEAN_SOURCE'] = 'Do you wish to clean the HTML source of the content you just pasted?'; // line 285
widgLang['B'] = 'Bold'; // line 945
widgLang['I'] = 'Italic'; // line 950
widgLang['A'] = 'Hyperlink'; // line 955
widgLang['UL'] = 'Unordered List'; // line 960
widgLang['OL'] = 'Ordered List'; // line 965
widgLang['IMG'] = 'Insert Image'; // line 970
widgLang['SOURCE'] = 'HTML Source'; // line 975
widgLang['A_TEXT'] = 'Please select the text you wish to hyperlink.'; // line 1197, 1208
widgLang['A_URL'] = 'Enter the URL for this link:'; // line 1214
widgLang['IMG_SRC'] = 'Enter the location for this image:'; // line 1226
widgLang['IMG_ALT'] = 'Enter the alternate text for this image:'; // line 1230
2nd step:
Change all the english texts in this array to text in your language.
3rd step:
Replace every hardcoded text in the script with the corresponding element of the configuration array widgLang.
Example:
Change this: ...
widgSelectBlockOptions.push("", "Change block type");
widgSelectBlockOptions.push("<h1>", "Heading 1");
widgSelectBlockOptions.push("<h2>", "Heading 2");
to: ...
widgSelectBlockOptions.push("", widgLang['BLOCKTYPE']);
widgSelectBlockOptions.push("<h1>", widgLang['H1']);
widgSelectBlockOptions.push("<h2>", widgLang['H2']);
or change this: ...
alert("Please select the text you wish to hyperlink.");
to:...
alert(widgLang['A_TEXT']);
and so on...
The line numbers behind the definitions of the configuration array widgLang are showing the positions of hardcoded text - before pasting the extension ;-)
Have fun
174/269
Karuna commented on 3 July 2005 @ 01:50
One Question:
When I copy some Text from Word to this Editor I have sometimes additional paragraphs with a nonbreakingspace in. How can I change this?
Example:
<p>&nsp;</p>
175/269
Ksenia commented on 7 July 2005 @ 09:28
Here are possible solutions for Mac problems:
Slightly change in detectPaste method is needed:
if ((theEvent.ctrlKey || theEvent.metaKey) && theEvent.keyCode == 86 && this.wysiwyg) {
I replaced javascript iframe generation with static iframe, pointing to a static html template.
I also use body.innerHTML for updating, instead of document.write.
I didn't test it in Win IE yet, but Firefox on Mac seems to work just fine
176/269
Ksenia commented on 13 July 2005 @ 02:22
I had a strange problem with pasting text with fixed row width (content of plain email from Mail.app). The single breaks were replaced by paragraphs. The problem seems to be in the function acceptableChildren. It looks like breaks were somehow never accepted as an element, even when widgInsertParagraphs == true. Testing environment: Firefox 1.0.4 on Mac.
Anyway, the following patch seems to help. Replace line 1466
if (!theChildren[i].nodeName.isAcceptedElementName())
with
if (!theChildren[i].nodeName.isAcceptedElementName() && theChildren[i].nodeName.toLowerCase() != 'br')
177/269
The Dood commented on 15 July 2005 @ 18:36
Hi! Great bit of code there!
I am having issues with IE though - when it loads up, the text area - set to 100% overflows to the right (in other words, it seems to take up 110% of the screen). As soon as you resize the window, it fits to 100%. FF is fine. Seems like IE doesn't like margins and paddings around the text area, but I could be wrong.
178/269
Dave commented on 21 July 2005 @ 07:39
This looks great! Exactly what I'm looking for!
Don't shoot me for asking (blame the client) but anyone know how it works on IE for the MAC. (Yes, I know I should tell the cleint to get a better browser. But let's assume I can't -- just yet.)
179/269
Peer commented on 2 August 2005 @ 07:17
Hello Cameron,
thank you for that very fine Peace of code.
Look here:
http://www.peer-bode.de/xmentor_reloaded
I think, this is the first WCMS, that produce clean and valid XHTML 1.1 output with a WYSIWYG Editor
180/269
Pete Harrison commented on 23 August 2005 @ 22:45
Is there no way of doing any event handling on the textarea's? As the widgeditor replaces the textareas with it's own Iframes etc, any OnBlur/OnChange events get lost.
My page is driven by details from a database, doing validation at the server means updates will be lost if the page is reloaded so I need to do them at the client side.
Fantastic tool though.
Pete
181/269
Dave commented on 30 August 2005 @ 06:12
This is great. I'm going to try it out on my site.
Any chance of supporting <pre> (and/or <code>) tags? I'm a bit of a javascript-o-phobe and its not obvious to me how to prevent it from inserting and <br/> tags as the user types.
Thanks.
182/269