I use SimpleMDE on my website for simplifying the usage of <textarea> as a text editor.
When trying to customize it, I ran into one problem: I don't know how to resize the text editor.
For example, when inspecting the result of the SimpleMDE code on my website, I found out the default height for the text editor is 20rem. I want it to be more than that.
I came up with one solution, but I consider it to be unreliable, since it is a method of my own, not a built-in one. I simply changed the CSS attributes for the CodeMirror class (as it is the container class for the text editor).
As you could probably guess though, I am looking for a built-in way to do this to avoid any problems and have it the intended way. So how do I do this?
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 have a contenteditable div:
<div class="one" contenteditable="true">A</div>
If the user enters HTML, CSS or Javascript tags into that contenteditable div, how would I make it syntax highlighted?
So as the user types in variables, tags, etc, they are colour coded
This is not as easy as it might seem at first.
You can create your own solution using some existing highlighting library like PrismJS or HighlightJS and then implement a custom re-render functionality which saves the current cursor position -> parses the content & updates the look (this would be the task of the syntax highlighting lib), and then sets the cursor to the previous position again.
There is one "tutorial" by bililite which can help you with this task.
You can find it here.
TBH: I'm surprised that there (correct me if I'm wrong) seems to be no open source solution for this. Would there be a need for that?
I'm trying to make a twitter-like rich-text editor wherein the characters that go over the character limit are highlighted. I saw this question and tried editing it.
I used Kendo UI's Editor and also Tim Down's rangy library. Using Kendo's inline editor, the rangy library works great.
<div contenteditable="true" class="rte"></div>
Although I need it to work when attached to a textarea.
<textarea class="rte" maxlength="50"></textarea>
The rangy library doesn't work on the textarea quite like the inline editor maybe because Kendo uses an iframe for this. The characters that go over the limit are highlighted but the cursor goes back to the start of the content.
Does anyone know how to fix this? Here's a sample I've been working on: http://jsfiddle.net/G4jn7/12/
This is easily fixed: you just need to pass in editor into the rangy.getSelection() call to tell it to get the selection from the iframe's rather than the main document.
Demo: http://jsfiddle.net/G4jn7/13/
In rangy.getSelection(x), x can be any of several things to identify the document to use: a Window, Document, an <iframe> element or a non-iframe element within the document.
So basically I am creating a mail editor.. (Just want it as a div with contenteditable where i can switch HTML/Clear Text and I've already created a Word style editor (decorations/color/font/size etc)
I DO NOT WANT TO USE A PLUGIN
Problem im having is the div is inherting styles from the page =/ This is not good at all, how can I prevent it?
Example is using H1's.
A "bad" but working solution is to only style classes instead of example H1's.. But is there any good way?
Example pic:
The best solution is, to move the content to an iFrame. All major HTML editors do this trick to avoid interferences from the main style to the editable content
Take a look at the answer from a CKEditor devloper to my question too. Also I wouldn't suggest developing you own editor, it only looks simple in the beginning, but you end up building a lot of workarounds for browser incompatibilities!
You can take a look at YUI CSS Reset. Include or copy their CSS Contextual Reset and add to your editable DIV:
<div class="yui3-cssreset"></div>
If you don't care much about backward compatibility, you can use Shadow DOM. Setting applyAuthorStyles=false and resetStyleInheritance=true on the ShadowRoot prevents CSS of the parent document from affecting the Shadow DOM.
ShadowRoot can be created by calling createShadowRoot() on the div element. Alternatively, you can create a web component for your editor using one of the convenience libraries - Polymer or X-Tag.
There are certainly simpler (and more portable) solutions to your problem, but this one may give you additional benefits in terms of making your editor more reusable and encapsulated.
If you are using it as a html email editor, you shouldn't be using semantic tags like <h1> anyway. Html email doesn't play nice with modern web standards.
I'd suggest converting all the WYSIWYG text into <font> or <span> tags with inline CSS.
Because html email uses different element types (tables vs divs), it is easy to separate the CSS targeting between your page and editable content, providing you are formatting the user input.
I'm working on an ASP.NET MVC project which uses the MarkdownDeep Editor to add a rich editor on top of a basic markdown input textbox (very similar to the Stackoverflow editor window).
Generally it works great. However, in certain scenarios, I would like to disable the preview window. This is automatically generated below the textarea by MDD. Can this be disabled?
Just to be clear, I know I can use CSS to hide the preview. But on some devices it's slow and makes typing painful. I want to entirely turn off that feature. I don't see anything in the docs other than how to customize the preview.
Any ideas?
In the docs it specifically mentions that it is recommended that you have the div preview already in your document because it will be created if it isn't found and consequently, could could a visible page refresh if any re-layout has to occur.
Note: the associated divs are all optional and if missing, the plugin will create them. However... you might experience the page jumping around during load if you do this. ie: it's recommended to explicitly include them.
Thus from the sounds of this, and that there doesn't appear to be any option to turn it off in the API page I would say no, it's not possible.
I am a little confused here: if you don't want the preview, use a regular text area instead of mdd_editor... So, under the scenarios where you don't need the previews, instantiate a plain vanilla editor. What am I missing here?
I know this is old, but I was looking for something else on mdd. I recently had this same requirement.
Just comment out the code
// Update the DOM
if (this.m_divHtml)
this.m_divHtml.innerHTML=output;
in MarkdownDeepEditor.js