I have a WYSIWYG Editor using contenteditable that allows users to insert "code snippets" using a <code> element. For instance:
<div contenteditable="true">
<p>
This is a paragraph with an <code>inline snippet</code>!
</p>
</div>
https://jsfiddle.net/wyeack/pyta77zd/2/
In firefox, if you place the caret directly before the first character of <code>, it will prepend the element:
However, if you try to do the same thing in Chrome, it appends it to the previous element:
This means that if you use chrome, there is no way of adding content to the beginning of this element.
What's going on here? Is there a way for me to make the behavior more consistent?
Firefox has a superior selection implementation in this case. You can place it inside an inline element like <code> if you move it from right to left using arrow keys. If you move it from left to right, it will stick to the left. This is, so called, gravity.
What's going on here? Is there a way for me to make the behavior more consistent?
First of all – don't use bare contentEditable. Use a good RTE.
Second (and last :P) of all – I don't know about any RTE which normalises this specific behaviour. It's an expensive thing to do and few users would notice it. It is possible, though, but you would need to use an RTE with a proper data model (where the selection is fully abstracted and all input intercepted) and based on that handle the input accordingly.
I could give you more details on how to do it with CKEditor 5, but it's not production ready yet. I've got no idea how to do that with other RTEs, but I know one thing for sure – I'd never ever attempted to fix this on a native contentEditable.
Related
I'm trying to implement mentions within contenteditable div. I'm using external library called TributeJS (https://github.com/zurb/tribute). Mostly it is working fine, but there is an edge case if I write mentions together without space and in multiple lines and then try to delete them with backspace key, then at some point I cannot delete mentions anymore.
Mentions inside input use span with contenteditable="false" like this:
<span contenteditable="false" class="mention" data-id="user1">
#<label class="mention-label">User 1</label>
</span>
I've recorded a video, so I can explain the problem easier:
https://files.fm/f/ga5dak22b
And I've also created a Codepen to reproduce this issue:
https://codepen.io/tilenhosnar/pen/powZqBw
This problem occurs for me in Chrome browser. I'm wondering if there is any way to "force" delete child HTML nodes in contenteditable div on backspace key? I've pretty much tried every solution I could find in the last few days but it is still happening.
Maybe try to use ANSI escape code to go up a line instead of backspace, This question might help you.
I'm talking about content from inside a contenteditable div, and the target is the same contenteditable div. So no external programs involved.
The structure of the HTML in this div is that each individual word is inside a span with some data we need to track. Then the whitespace is left as text nodes between the spans. This works fine for the most part (screw you newlines) but I've encountered a strange problem when copy and pasting.
Chrome turns this
<span attrs="stuff">word</span> <span attrs="stuff">another</span>
into this:
<span attrs="stuff">word </span><span attrs="stuff">another</span>
or this:
<span attrs="stuff">word</span><span style="line-height: 16.79999"> </span><span attrs="stuff">another</span>
This obviously means that if the user copy and pastes over more than one line, then the formatting is completely screwed up, and the content of the span has changed which invalidates our data that we need to track.
The core problem is that other stuff in the div may contain non-breaking spaces for real reasons, so if I globally start swapping them out, then I might break that.
For my spans with my attrs, then I know what should be in them so it's easy to strip out the non-breaking spaces and restore it to how it should be. But for these strange spans with the odd line height, I've no idea how to clean them out without nuking everything.
Right now, I've stripped all the inserted spans that contain just a non-breaking space. But what I'd really like is to either stop Chrome from doing this in the first place, or an unambiguous means to identify the problematic extra spans so that I can clean them up in safety without breaking any similar spans that exist for real reasons. I could use this strange line-height I guess but that's pretty brittle and unsafe it feels.
How can I prevent the spans from appearing or identify them unambiguously?
The problem is not a Chrome problem only. All the time you copy HTML Code somewhere something like this can happen.
This is why you can use editors like CKEditor. They have advanced filter techniques to remove such bad HTML code.
I recommend to use a clipboard program to see how the HTML code is when you copy from different places: https://softwarerecs.stackexchange.com/questions/17710/see-clipboard-contents-hex-text
But implementing this on your own would be a waste of time in my opinion.
CKEditor can be configured very well to prevent the bad HTML code.
Recent versions of CKEditor have a very sophisticated content filtering approach. It is called "Advanced Content Filter".
Basically "Advanced Content Filter" means: The whole HTML code gets parsed or checked. In the case that there is no rule which matches to the given HTML code, it gets filtered out.
I have some HTML in a contenteditable that looks like <span>hello wor</span><strong>ld</strong></span>. If I change it, so that world is misspelt, I would like to be able to get suggestions on this complete word. However, this is what actually happens:
The text is separated into two words, left clicking simply gives suggestions for one or the other.
Is there any recourse?
The implementation of “spelling checks” requested by using the spellcheck attribute (which the question is apparently about) is heavily browser-dependent, and the HTML5 spec intentionally leaves the issue open. Browsers may implement whatever checks they like, the way they like, and they do. You cannot change this in your code.
Although modern browsers generally have spelling checks of some kind at least for English, they differ in the treatment of cases like this, among other things. Firefox treats adjacent inline elements (with no whitespace between them) as constituting one word, but Chrome and IE do not. Moreover, browsers might not spellcheck initial content, only content as entered or edited by the user.
The only way to get consistent spelling checking is to implement it yourself: instead of using the spellcheck attribute (“HTML5 spellcheck”), you would need to have spelling checking routine and integrate it into your HTML document using JavaScript. People who have implemented such systems normally have the routine running server-side and make the HTML page communicate with it using Ajax.
Adding HTML/any tags to either side of selection - Javascript
The problem:
After creating a textarea box in my PHP/html file I wished to add a little more functionality and decided to make an textarea that can use formatting, for example
<textarea>
This is text that was inserted. <b>this text was selected and applied a style
via a button<b>
</textarea>
It doesn't matter what the tags are, (could be bubbles for all that I care due to the fact the PHP script, on receiving the $_POST data will automatically apply the correct tags with the tag as the style ID. Not relevant)
The Question/s
How can I create this feature using javascript?
Are there any links that may help?
And can, if there is information, can you explain it?
EDIT: Other close example but not quite is stackoverflow's editor and note that I do not wish to use 3rd party scripts, this is a learning process for me.
The tags that are inserted in the text are saved to a database and then when the page is requested the PHP replaces the tags with the style ID. If there is a work around not involving 3rd party scripts please suggest
And for the anti-research skeptics on a google search, little was found that made sense and there was Previous Research on SOF:
- https://stackoverflow.com/questions/8752123/how-to-make-an-online-html-editor
- Adding tags to selection
Thanks in Advance
<textarea> elements cannot contain special markup, only values. You can't apply any styling in a textarea.
What you'll need to do is fake everything that a text box would normally do, including drawing a cursor. This is a lot of work, as hackattack said.
You can do a lot if you grab jQuery and start poking around. Toss a <div> tag out there with an ID for ease and start hacking away.
I've never made one personally, but there is a lot to it. HTML5's contentEditable can maybe get you a good chunk of the way there: http://html5demos.com/contenteditable/
If you want to pass this data back to the server, you'll need to grab the innerHTML of the container and slap that into a hidden input upon submission of your form.
Here's other some things you can check out if you're just messing around:
tabindex HTML attribute, to get focus in your box from tabbing
jQuery.focus() http://api.jquery.com/focus/, to determine when someone clicks in your box
cursor: text in CSS for looks http://wap.w3schools.com/cssref/pr_class_cursor.asp
jQuery.keypress() http://api.jquery.com/keypress/, or similar for grabbing keystrokes
Edit: I think I completely misunderstood
If you're not looking for a rich text editor, and just want some helper buttons for code, maybe selectionStart and selectionEnd is what you're after. I don't know what the browser support is, but it's working in Chrome:
http://jsfiddle.net/5yXsd/
you can not do anything beside basic formatting inside a texarea. If you want complex formatting, look into setting a div's contentEditable attribute to true. Or you can make a wysisyg editor, but that is a big project. I strongly suggest using 3rd party code on this one.
I suggest you using the iframe to implement the WYSIWYG effect.
There is a property in iframe called designMode
See here for more
https://developer.mozilla.org/en/Rich-Text_Editing_in_Mozilla
Also there is a lightweight example maybe you would like to take a look:
http://code.google.com/p/rte-light/source/browse/trunk/jquery.rte.js
I need to create a simple rich-text editor that saves its contents to an XML file using arbitrary markup to indicate special text styles (e.g: [b]...[/b] for bold and [i]...[/i] for italic). All the backend PHP stuff seems fairly straightforward, but the front-end WYSIWYG portion of the feature seems a bit more convoluted. I've been reticent to use one of the currently-available JavaScript-based WYSIWYG editors because the rich-text options I want to allow are so limited, and these applications are so fully-featured that it almost seems like more work to stip them down to the functions I need.
So, in setting out to create a bare-bones rich-text editor, I've encountered three approaches:
The first two approaches use the contentEditable or designMode properties to create an editable element, and the execCommand() method to apply new text styles to a selected range.
The first option uses a standard div element, executes all styling commands on that elements contents.
The second option uses the editible body of a window enclosed in an iframe, then passes any styling commands initiated from buttons in the parent document into its contentWindow to alter selected ranges in the contained body. This seems like several extra steps to accomplish the same effect as option one, but I suppose the isolation of the editable content in its own document has its advantages.
The third option uses a textarea overlaying a div, and uses the oninput JS event to update the background div's innerHTML to match the input textarea's value whenever it changes. Obviously, this requires some string finagling to to convert elements like newline characters in the textarea to <br/> in the div, but this would allow me to preserve the integrity of my [/] markup, while relegating the potentially-messy DOM manipulation to front-end display only.
I can see benefits and drawbacks for each method. the contentEditable solutions seem initially the simplest, but support for this features tends to vary across browsers, and each browser that DOES support it seems to manipulate the DOM differently when implementing execCommand(). As mentioned before, the textarea/div solution seems like the best way to preserve my arbitrary styling conventions, but the custom string-manipulation procedure to display rich text in the output div could get pretty hairy.
So, I submit to you my question: Given the development goals I've outlined, which method would you choose, and why? And of course, if there's another method I'm overlooking that might better serve my purpose, please enlighten me!
Thanks in advance!
Have you looked at http://php.net/manual/en/book.bbcode.php? This is your answer. If you are having doubts, then you are doing something wrong. :-)
Then use JS to track keyup event and simple AJAX to print preview of the input. Just like in stackoverflow.
NB It would be far more efficient to generate the preview using plain-js BBcode approach. However, do not overcomplicate stuff unless you necessary need it.
The problem with BBCode, Markdown, ... is that it's not that trivial for genpop. I suggest looking at widgEditor, it is by far the simplest WYSIWYG editor I've seen to date. It was developed some time ago, so I am not sure about compatibility, but it sure is an inspiration.
I would have included this only as a comment, since it does not directly answer your question, but I am fairly new to SA and could not find out how to do that. Sorry.