I'am currently developing a WYSIWYG editor for my CMS and got serious bugs here. After switching from IFRAME to DIV contenteditable the behavior changed dramatically.
Using execCommand('formatBlock') to create headlines causes unwanted BR tags to the source code, but only in Mozilla. I thought the reason could be <br _moz_dirty=""> but I could be wrong and did not find a way to fix it.
See demo here: http://jsfiddle.net/Kj9Rp/
Definitely a bug. I've noticed that the relatively recently added contenteditable functionality in Mozilla has a number of quirks not present with designMode. I would stick with the <iframe> and designMode for now and file a bug at Mozilla's Bugzilla.
Your other option is to write your own DOM manipulation code that surrounds selected text within an <h1> element, but that will be relatively involved to get absolutely right.
Related
It's really hard to understand how Tinymce can be considered as WYSIWYG, because I cannot get what I see (visually exactly). So it is more likely "what you see is just what you see".
Currently I use getContent() to get the HTML. But it lacks embedded style and if we show that output html in some container, the visual rendering will look different.
I've tried implementing my own solution to help embed the current style (based on getComputedStyle) to each element. But that's not very efficient (many redundant styles can be included) and not always works (such as for embedded video, I'm not so sure why the <video> is not kept with getContent() and all <video>s disappear in the final output html).
The Tinymce team has done a lot of works, but really not sure why they did not even think about this feature? We need the exact HTML that renders what you see in the editor. We can sanitize the HTML after that by ourselves.
Here is a demo helping you imagine better what's so bothersome with this WYSISWYG editor:
https://jsfiddle.net/L83u5v0n/1/
Clicking on the Show HTML button shows this:
So you can clearly see it's just more likely to be WYSIWYS rather than WYSIWYG. Is there a solution to get the exact output HTML based on some hidden feature of Tinymce that I've not known of? If it's based on some custom script using getComputedStyle then really I do not need it (actually my solution is fairly good).
This is a function of demos that are set up to look good in the editor versus real world usage. The intention of the content_css configuration is to provide the CSS that will be used to render the content.
If you apply the content CSS elements to the page then "Show HTML" works perfectly.
https://jsfiddle.net/xzh8utbp/
Alternatively, delete the content_css configuration (but that won't quite work in your example because JSFiddle adds CSS to the result window).
Note that I've added mce-content-body to the view div because it turns out our codepen demo CSS leverages it. Normally that wouldn't be required, but then I don't think normal integrations use our codepen CSS.
I've been using this (https://bootstrapious.com/p/bootstrap-sidebar) article to set up a sidebar for a web application I'm building. I'm relatively new to web development so what seem like quirks to me might be common knowledge. I'm trying to adapt the stylesheet and in doing so want to change elements. However, none of the adjustment I make seem to work. When I inspect element in the browser, both firefox and chrome, the <i> line actually has been commented out and replaced with an <svg> tag. This then leads to the CSS not being applicable to that particular element. If I pre-emptively write CSS instructions for svg elements it works, but this seems like the wrong approach. Can someone explain to me why this automatic commenting happens and what I can do about it?
I believe the title is pretty self-explanatory but still, maybe, I should ask in detail. I'm building a WYSIWYG editor and I'm really at the beginning of it. So, I realized that maybe knowing the pros and cons would enlighten me. Basically, my question is, since I want an editor that would work at least with 90% in all major browsers, how further I can go using contenteditable within a div and what are the cons and pros of using contenteditable when compared with designMode and iframe? Also, while researching I've found this editor. I believe it is not using any of these attributes and it's moving the location of textarea. Is this a better approach? Well, I know that there are lots of factors that influence the answer on the last question, but as I mentioned, the most important thing I look up in the editor is that it can be used by the 90% of the users. NB: I do not want to use any third party libraries.
contentEditable does not work with floats in IE:
<p>
<img style="float:left" src="foo">
<p contentEditable="true">very long text here ...
... this text won't flow round the image</p>
</p>
This is because contentEditable triggers the infamous hasLayout.
Other than that, everything works pretty well.
For most uses, my preference is still for an iframe with designMode on most browsers and a contenteditable <body> element in IE, which makes it easier to work with. The reasons:
Having the editable content in an iframe effectively sandboxes it and allows you to drop the editor into any page with confidence that the page's CSS and DOM events cannot affect the editable content
designMode is more reliable in Firefox. I've seen several bugs with contenteditable that don't exist with designMode, which is probably because contenteditable was added to Firefox relatively recently whereas designMode has existed since around 2003.
As to ACE, its textarea approach is clever and has many advantages but I suspect the approach is limited to monospaced fonts. Also, CodeMirror 2 uses a related approach but is similarly limited to monospaced fonts.
The designMode and contentEditable attributes, and the APIs that drive rich text editors, are implemented in all major browsers, including Firefox, Opera, Safari, Google Chrome, and of course Internet Explorer.
http://blog.whatwg.org/the-road-to-html-5-contenteditable
Mark Finkle wrote a nice high-level summary of designMode, and later added a post about contentEditable.
I'm a little curious about how the editing of Google Docs works. How did they implement an editor within the DOM? It does not really looks like a form with a textarea, but rather a normal document body with an additional cursor. I guess it is some javascript technique behind.
Is there any free library that I can use for achieving this kind of functionality, or how can I implement it myself?
2019 Update
I'm pretty certain the answer below was accurate at time of writing in 2010 but has been substantially inaccurate for several years. Here's an answer of mine to a similar question in 2012 that may be more accurate, although still possibly not massively helpful.
How does Google Docs achieve content editing?
Original answer
It uses editing functionality built into all modern desktop browsers, accessed at document level via setting the designMode property of the document to "on", or at an element level by adding a contenteditable attribute with value "true" (also triggered by setting the contentEditable property of an element to the string "true").
A very common strategy for editing a piece of content in a web page is to include an iframe whose document has designMode turned on.
Coupled with this is document.execCommand, which in an editable document can be used to apply various kinds of formatting. For example:
document.execCommand("bold", false, null);
... will toggle whether the selected text is bold. There is a pool of common commands between browsers but there are some discrepancies as to exactly how some are implemented. More info can be found here at MSDN for IE and here at MDC for Firefox. Can't seem to find documentation for WebKit.
Since mid-2010 Google Docs seems to completely having switched away from relying on the browser for editing mode.
Instead they built their own text/HTML editor using JavaScript and DOM.
They explain it in a lengthy blog posting on how they implemented the functions.
Having searched for 3rd-party vendors offering similar concepts, I found no one so far. Would have been a great for iOS since they seem to not support the contentEditable attribute until iOS 5 (and even then, there are issues)
For mee it looks like any HTML editor. They just coded their own JavaScript HTML editor. Even the HTML edit view doesn't have any magic.
A good and free HTML editor is TinyMCE but there are many others out there, even some very powerfull proprietary like CuteEditor which is available for PHP and ASP.NET.
BTW: The content of the document (in Google Docs) is placed in an iframe, just as it is in CuteEditor (and probably also in TinyMCE).
As other people have said, google is very uptight about what information they share. However, they have posted a lengthy blog idea about how they built their own word processing system FROM SCRATCH. Building this, would require you to have your own experience team with several days needed to complete it.
Link to lengthy blog is here:
https://drive.googleblog.com/2010/05/whats-different-about-new-google-docs.html
Essentially, they capture where your cursor is, place a div that looks like a line, and manually insert a letter at the place your cursor is
I want to write a very simple WYSIWYG editor, but i don't understand how do they work :(
I've tried to read sources of tinyMCE but stuck in all those classes and functions.
As I know they're creating iframe then do some black magic there and everything works.
The question is: what do those editors do with iframe so it becomes editable?
Thank you.
The keywords are contentEditable and designMode.
Good sources to get started:
Rich-Text Editing in Mozilla (MDC)
element.contentEditable in Mozilla (MDC)
contentEditable in IE (MSDN)
very simple means you want little extension? In such case, you will like http://code.google.com/p/jwysiwyg/
Its constructor is really simple, but not good for extension works.
You can search JQuery. I think there's huge amount of HTML editor or rich text editor available.
By the way, the HTML editor inside Extjs is the worst thing I have ever seen.
Google released yesterday an open source editor:
http://closuretools.blogspot.com/2010/07/introducing-closure-library-editor.html
A quick look at it shows an IFRAME with the BODY tag with the attribute: contentEditable