I dont know whether I am reiventing the wheel.
I need to design an online WYSIWYG where users can make one/two/three-column layout page.The WYSIWYG should adjactly show the contents in design mode as well as preview mode.Therefore, the WYSIWYG should also have the supports for Header and Footer too.Therefore, the WYSIWYG will have at least three boxes(Header, Content,Footer) and in max it may contain six boxes.
IFRAME supports designmode (on/off) and it has content editable property and it also supported by most browsers. Though DIV also has the content editable properly in the latest browsers. Since there are many users who use IE6 still, probably choosing IFRAME is better(need your kind advice).
Now the question is whether I should use 6 IFrames or only one Ifrmae or no Iframe at all? Please suggest.
Thanks.
It sounds to me like you are trying to reinvent the wheel. You should be able to use one of the existing WYSIWYG editors with template support built-in. So I'd suggest you have a look at CKEditor, which probably has all the features you need.
Choose whatever existing editor that you like, but don't try to recreate one yourself, you'll become crazy.
I don't even know what do you understand as different between WYSIWYG and "Rich Text Editor", the main difference might be that no web-based editor can be really "What You Get", because there are lots of little problems.
Anyway, it seems that you want to create a page with one toolbar and several editing instances, I think that all the main editors does support that, but I would avoid using one based on a framework (YUI or Google closure) unless you are already using that framework.
Check instead the features of stand alone editors like CKEditor or TinyMCE. You'll hardly get anything better that those ones.
Don't reinvent the wheel! If you decide that you need to support designmode iframes as well as contenteditable, Google Closure Editor has a very performant implementation of multiple editing surfaces that only creates one iframe at a time.
I would look at YUI Editor from Yahoo, The YUI stuff does support a drag and drop column editing. I would say reuse in this case.
EDIT: Since you say you want to edit multiple areas per page you should also check out the YUI Editor's Multi edit example page
Related
I'm looking for a js WYSIWYG editor that lets me insert readymade content that should be non-editable via the editor's interface, but via a link on it and some custom user interface. Users should be able to add objects to the content that are too complex to be handled by the editor by default and that are finally rendered when the page is displayed.
Looking around I found some TinyMCE plugins, non-editable content and atomic sections, which both point in the right direction but don't look too promising to me. For that I'd like to know if anybody out there has experiences with implementing some functionality like this or can point me to an editor that is probably more suitable for that than TinyMCE?
I implemented something similar using YUI Rich Text Editor. Considering my requirements, dealing with non-editable elements inside an iFrame was a hassle. What I ended up doing is this: whenever the user inserts a custom item using the toolbar (in my case it was a custom gallery with embeddable videos, etc.), I'd "split" the content of the editor at the cursor and insert a gallery "between" the editors. You end up with 2 actual editors and a gallery:
It required a bit of work to manage and render all of the objects and it had its downsides. But with proper CSS and some JS it could be made to look like and work like it's part of the editor.
I think you should stick with Tinymce. Actually all real time editors for browsers use an iframe in which the text gets put due to styling issues i guess. So using another editor won't solve the iframe problem MK_Dev described.
I need to build a wysiwyg editor for a project I am working on and need some guidance. Some of my key points of confusion are the following:
iframe docs vs. contenteditable divs: which one should I use and why? I hate iframes, is there a clear advantage to using iframes?
cross browser styling: execCommand seems to apply different styles in different browsers. Are there any tricks to making this cross-browser compatible? Should I not use execCommand at all and instead apply my own styles?.
adding items to the undo chain: how can run my own script, such as inserting an image, and allow cntrl+z (undo) to remove it? Is there an array of undo/redo items for contenteditable that I can push items into?
keeping the text selection: how I can maintain text selection while making operations such as selecting the font style, where the focus will leave and remove my selection. Rangy? Google closure? Are there other range/selection libraries worth looking at?
Any tips on these items or anything else related to building a rich text editor would be greatly appreciated!
From personal experience, I recommend against doing this unless your aim is to provide a very limited amount of functionality. The sheer number of browser differences and the complexity of their workarounds makes this a very tricky and time-consuming task if you want to do it well.
If that hasn't put you off, here's my thoughts on your individual questions:
iframe docs vs. contenteditable divs
I recommend the iframe approach, for two main reasons:
You have complete control over the document type, CSS and script within the iframe. This is essential if you want consistent behaviour and appearance and want to use your editor within different pages.
Firefox in particular is quite buggy with contenteditable elements, which they only introduced relatively recently (version 3.0) while designMode has existed on documents for many years (since pre-1.0; around 0.6, if memory serves) and works pretty well.
cross browser styling
If it's important for you to have uniform results from applying styles in different browsers then in general you will need to write your own styling code. However, doing this will break the built-in undo stack and you will need to implement your own undo/redo system.
adding items to the undo chain
There's no programmatic way to interact with the built-in browser undo stack. You'll need to write your own.
Update November 2012
There is a spec in the works for custom undo/redo so this is likely to be possible eventually. Here are the relevant bugs for Mozilla and WebKit.
keeping the text selection
I have to declare my interests here, since I wrote Rangy. I don't think there's a better library out there that does a similar job; Google Closure does have a range/selection API but I think it uses their own proprietary interface rather than emulating DOM Range and common browser Selection objects. IERange is another library that is similar in idea to Rangy but much less fully realized and seemingly abandoned immediately after release by its author.
Don't, seriously don't.
What you are suggesting is a major undertaking. You really should be looking at TinyMCE, http://tinymce.moxiecode.com/, or CKEditor, http://ckeditor.com/. Getting what you are after is a massive amount of effort to get working for one version of one browser, to make it portable will take man-years of investment.
A better solution is to look at things like TinyMCE's plugins, http://tinymce.moxiecode.com/plugins.php. You can get your basics the basics (and portability for free) and concentrate on adding the specific value-add items you need to.
I have a site that is in need of a drawing program. My users need to be able to draw floor plans and add text to these images. I'm wondering if anyone has come across a nice SVG WYSIWYG editor.
Otherwise I'm going to have to use a Flash or Java app which I'm not fond of.
The only one I know is svg-edit. It is not nearly as powerful or mature as editors like CKEditor, TinyMCE or FCKEditor are in their field of application, and it won't be as simple to implement, since it is more a script like a component, and finally I don't know how easy it is to customize it.
But I heavily doubt that there is something similar with more comfort.
You might have a try here or here (just to mention, won't work in Internet Explorer - although the site states that it would work if you have Chrome Frame installed but I can't confirm that).
Maybe you could tell us how far this meets your requirements ;-)
One impressive example of a polished and very intuitive webbased "drawing" app is accidentsketch.com. Uses both svg and html.
I was looking at what YUI had, http://developer.yahoo.com/yui/examples/button/btn_example07.html
Can anyone recommend a library/plugin they used to progressively enhance native select element dropdowns at the request of a client? I know it's impossible to style a dropdown in IE, so it's either this or Flash which I don't want to get into.
I'll still leave the regular dropdown in the source for non-JS users and serve the dropdown replica built out of non-form control elements.
Assuming you mean a different library than YUI, I like dojo's dijit.form.FilteringSelect.
Turns out it wasn't all that difficult, pretty much the same logic as a dropdown menu except with a little extra for the toggling bit.
by simple I mean, having buttons:
bold,
italic,
numbered list
bullet point list
indent left
indent right
spell check (obviously supported by ready made js component)
by custom I mean: having custom icons - so really just custom design
no frameworks, written from scratch, lightweight, compatible with major browsers
this is one of the main components of the webapp, so it has to be super lightweight, that's why I don't want frameworks
Unless you are targeting one browser, editors are immensely complicated components to get to work cross browser. There's no reason to do it yourself, unless you want to learn.
Use one of the many available that allow customization:
tinymce,
fckeditor,
wysihat,
others
Writing an editor that works cross-platform can be difficult, but, you should create your own framework as you do it, as it is a large project.
If you just want custom icons, that will depend on how long it takes you to make them, but, to get some basic functionality isn't that hard, probably less than 40 hrs of work if you know what you are doing.
In Unix writing your own shell used to be a rite of passage, in javascript it may be writing your own editor. :)
Where it gets tricky is if I have
<b>some text</b><i>more text</i>
and I decide to remove the tags from this text, then how to fix it will get tricky.
If you want to use only css then it gets to be more of a problem as you are grouping text from span tags, and fixing css classes, while the user is continuing to make changes.
I am dealing with this currently as I want an editor that works in XHTML2.0, and it is not a trivial issue, much harder than it is to do in a desktop application.
I would suggest getting it to work on Firefox 3 and Safari first, then, once it is working, go back and add in the code to get it to work on IE8, and if you want IE7, since MS is pushing IE8 out as a critical update now.
Don't.
Go get something else (any of those Jason mentioned, or e.g. what SO itself uses, WMD). Swap out its images. The end.
Seriously you don't want to write your own editor unless you have a very good reason for it functionally, not just what it looks like.
Read through the first chapters of the emacs tutorial, and you will see that there is not anything like a "simple" editor. But google will give you lots of easy customizable editors.