Most don’t have a need for a new version, that’s all.
I think there’s merit in creating a flexible rte base with the essential components that can be extended.
So you are talking about a SGML editor, text marked-up within tags.
The simplest way would be to do the exact same thing as an HTML editor, except with an XML document and a stylesheet for the different elements.
It’s trickier than the simple HTML editor though as execCommand can handle the textRanges and selections. If you wanted to do custom you will need to do your own work with selection and ranges which is very tricky cross browser.
Most people get by fine with HTML, if you have a need for displaying a custom markup language in rich text then go for it, others might not need it though.
Just don’t expect it to be easy
This project seems like something relevant to any CMS. I guess I am surprised that after suggesting this may not be such a ridiculous amount of work, you would still advise not creating your own.
That said, of course a flexible RTE base with essential components that could be extended is much preferable to starting completely from scratch. I attempted working with TinyMCE, but I didn’t even consider the slimmest version a flexible RTE base. Are there any tutorials for extending/modifying the RTEs you suggested?
The problem of in browser editing does not belong to to server-side scripting, limitations with POST or GET, or even the inability of web apps to cope with desktop-like applications. The problem lies in the simplicity of the form elements and the relative difficulty of extending them- which is why why we are having a discussion of overlaying an iFrame on textareas. PEBCAK aside, as DOM3 support grows and we begin to drop the dead weight of browsers like IE6 and move forward to an age of WebOS and netbooks, this seems like an important discussion!
Yikes, waxing philosophical there… better stop me, I’m only a graduate student.
Back on topic:
Proposed elements to manipulate were:
iFrame
Canvas
Object
And we seem to be in agreement that the iFrame is probably the best choice?
I haven’t personally used object for this purpose, if it doesn’t have support in the browsers I am interested in I’ll use a method that doesn’t require branching.
This project seems like something relevant to any CMS. I guess I am surprised that after suggesting this may not be such a ridiculous amount of work, you would still advise not creating your own.
I’m saying it’s quite possible to do, but offering the same advice as others - If another solves your problem there’s no point, other than a learning experience.
That said, of course a flexible RTE base with essential components that could be extended is much preferable to starting completely from scratch. I attempted working with TinyMCE, but I didn’t even consider the slimmest version a flexible RTE base. Are there any tutorials for extending/modifying the RTEs you suggested?
Nope, but this might get you started if you want to play with it.
Start by adding the elements you need to the textarea.
Set the content of the iframe to the content of textarea.
enable contentEditable / designMode.
Add a submit event listener on the form it’s sitting in to copy the source from the iframe back to the textarea.
That’s the bare bones of the poplar rte’s.
Then look at the source of wymeditor, ckeditor, tinyMce and the midas example form mozilla. Take the best parts that you understand and agree with.
You can get a single properly defined object to work correctly as a substitute for an iframe in all browsers except IE6. It is only if you need to support IE6 as well that you’d need to use a second object definition that references an activeX control to allow it to work for IE6. So with IE6 use now getting low enough to drop support for it the option of replacing iframes, applets, canvas etc with an object is becoming more and more practical.
In answer to your question “Why is iframe the best choice when it was declared to be obsolete many years ago when it was replaced by object?”
Because it works in all the current popular browsers.
When IE6 dies I will look at replacing it with object.
Glad I didn’t just take the first advice and a little conversation is actually going now.
Though, we’ve actually redesigned some stuff (for other reasons) so I now don’t need the custom RTE, but I’ll still probably write my own (or at least start one) just for learning if nothing else.
I think I’ll probably check out using an object because that seems like the most semantic element to use (which is ironic since the object element’s semantic meaning is that it’s basically a catch-all =p).
Thanks- I think this may be the answer to the disconnect I was having with using a textarea with another element.
Speaking of the other element:
So the object element is more standards-compliant, but its partial implementation doesn’t speak well for it. When using the object like a window, we are referencing external data- which is is the syntactical meaning of this element. Is there any usefulness in exploring the better implemented embed element for this purpose? Or is the object element simply better because it can contain other tags to be manipulated; in which case a div with contentEditable = true is basically the same?
The thing about divs with contentEditable = true, at least in FF is that it also lets you change the dimensions of the DIV container as well, which is quite undesirable.
If someone knows how to stop that, I think div might be better (or at least equal to) the object element.
The width and height and !important instructions seemed to work in Firefox and Chrome- they did not show resize handles at all. On Internet Explorer, things worked after I added
position:fixed;
but the resize handles still appeared when you clicked on the element.
I also explored using JavaScript:
onmousedown = event.preventDefault();
But this is only for IE, and the CSS method worked better.
I should mention, my div was wrapped in an object, I don’t know how that effected things since I didn’t do that much exploration before replying:
<div id="wrapper">
<h1>Rich Text Editor Test</h1>
<object id="richtext" name="richtext">
<div id="contentEditable" contentEditable="true">
<p>This is text to be edited.</p>
</div>
</object>
</div>
I don’t know what you mean, The div’s aren’t made resizable for me.
If you mean it’s dependant on the size of the content - that’s just because that’s how block level elements behave. You can add overflow: auto and a height if you want a scroll bar.
Try it with Internet Explorer- it definitely has resize handles. With FireFox, I didn’t get that default behavior, but I think its because I defined the width and height with CSS. It should be resize-able in Chrome, for the same reason TextAreas are, but same as FF with the CSS.
Like it or lump it, that’s how the HTML 5 cookie crumbles. They have said ‘This is the current state of the web, we’ll start there’ http://blog.whatwg.org/the-road-to-html-5-contenteditable
I personally like the attribute, html 5 is the spec for web applications and the form elements are pretty limiting. Go. Team. WHATWG. : )
People have similiar gripes with how other de-facto standards like canvas have been put into the spec.
