I'm implementing kind of a rich text editor based on HTML5 contenteditable features and now stuck on the following obstacle. Say we have several blocks with contenteditable attribute set to true. Whenever user edits text, it should detect the overflow somehow and move the rest of text to the next block (links are stored in the model). And if the actually changed text is moved, the focus and cursor should be moved too.
How this could be possibly achieved? The only idea I have now that partially solves the issue (at least rendering) is to render the complete piece of text in a separate hidden area and then use linked fields dimensions to detect pieces of text to be shown in each area.
The solution is built on top of Backbone + Marionette + Lodash + jQuery.
Related
Typing is slow in content editable if the content is long(length varies according to the device) in android WebView.To improve the performance, I was looking to implement the below options. But I'm not sure whether this would have significant improvement in the typing speed.
Having only the current focused div visible and nearby div's visible
and set the visibility of the other div to display: none.
Having set the content editable false to other div's except the focussed div.
I also considered replacing the content editable div with other non-content editable based editors which are available. But the problem is most of them are based on Codemirror and Codemirror has issues in auto-correct and focus in android WebView.
https://github.com/codemirror/CodeMirror/issues/6145
Rewriting the editor from scratch will take a lot of time. So just wondering if this could improve the performance of typing in long content content-editable divs. Suggestions for improving typing speed are most welcome.
Google Docs was revamped with the editor which was not based on content-editable but not sure how it works without the WebView not allowing to intercept keypress events in javascript side.
Reference link:
Google Docs Editor
I am about to write a input system for a web application that is a bit more complex. We have Labels in our text that are weather displayed as a bootstrap label (when the contenteditable div is blured) or displayed as handlebars e.g. {{firstname}} when the text is focused.
The changing in states is done by jQueries $().html(content) where I change the content based on the source when I focus the text field.
The problem is: if I click the text, I don't want to need to click a second time to place the cursor, because the text changed. It works as long I don't click inside of a tag but inside the contenteditable root element. but if I click inside of a tag inside the contenteditable, the cursor is not set.
my idea was to get the mouse position when clicking the contenteditable and then set the text cursor to exact that position when I have changed the text. But while I know, how I set the cursor to a specific offset inside a text node, I have no clue how to get this necessary offset when clicking. any ideas?
Edit: Here is the behaviour in a little screencast: https://youtu.be/RZvHxxM6wsQ
Edit2: Here is the problem reproduced on the smallest kind of working example:
https://jsfiddle.net/8z5Lnxef/3/
When I click on a text in a contenteditable div, the cursor does not appear to move.
once text is typed, the cursor becomes visible and text is entered in the clicked location.
its as if the cursor moves, but is not being redrawn.
I am unable to reproduce the bug in a simple jsfiddle environment.
Has anyone encountered such an issue before?
In the meantime I am trying to isolate the cause of the problem by removing css and javascript file references from the page.
and reverse- starting with a blank page and adding js/css in attempt to reproduce.
EDIT IN RESPONSE TO COMMENTS BELOW:
Browser: chrome
Javascript modules: jquery, jquery ui, rangy.
I tried to remove all javascript. and the bug was still there.
It must be coming from the css.
I am trying to single out the css rules involved. It appears to be a combination of things.
the :before psudo class (that I am using to show placeholder text in the div if it has no text) seems to be part of the problem.
The problem was traced to css3 3d transformations on a div that is located in the background of the contenteditable element.
Will try to place the background element in an iframe to resolve the issue.
I am trying to create a javascript code editor just for learning and I am doing a great job so far. The only thing is that I wanna place the autocomplete box in a position relative to the text cursor in textarea. So how can I determine the cursor position relative to the upper left corner of the window ?
Something else please, how can i capture the tab & enter keys press in a textarea ?
I am using a semi-transparent textarea (semi to keep the cursor blinking) with underlying div to enable code highlighting later on. Is this the best technique to do that ? Or there is a way to make textarea accept rich text or HTML ?
I suspect that you can do all that without a textarea. Read up on the contentEditable property. Here's a demo. This is how the Google Docs editor is implemented, incidentally. And here's a stackoverflow question dealing with finding the cursor position in a contentEditable div.
This is both a conceptual and how-to question:
In wiki formatting, or non WYSIWYG editor scenarios, you typically have a textarea for content entry and then an ancillary preview pane to show results, just like StackOverflow. This works fairly well, except with larger amounts of text, such as full page wikis, etc.
I have a concept that I'd like critical feedback/advice on: Envision a two pane layout, with the preview content on the left side, taking up ~ 2/3 of the page, and the textarea on the right side, taking up ~ 1/3 of the page. The textarea would float, to remain in view, even if the user scrolls the browser window. Furthermore, if the user scrolls the textarea content, supposing it has exceeded the textarea's frame size, the page would scroll so that the content presently showing in the textarea syncs/is parallel with the content showing in the browser window.
I'm imagining a wiki scenario, where going back and forth between markup and preview is frustrating. I'm curious what others think; is there anything out there like this? Any suggestions on how to attack this functionality (ideally using jquery)?
Thanks
Any markup language or simplified markup language like the wiki notation will differ from the output due to the formatting, so scrolling both textarea and formatted output by the same ammount of pixels or with some proportions will always loose sync.
Give them users two scrollbars and give up...
or
I've got an idea for You. It's based on the idea of not scrolling the preview at all, but generating it only from a currently edited part.
Finding out what is visible in the textarea was my first idea, but it won't be any more reliable than scrolling both views together.
What You can do is get the current cursor position in the textarea (can be done. has some browser issues)
Then get some n characters before and after the current position rounded to full lines and generate preview from that. You can check for cursor position change every 1 or 2 seconds and upate preview if it changed.
n depends on the textarea size.
pros:
no sync problems, need to generate only a part of a larger text
cons:
updates only if user moves text cursor.
You could make it a feature... The textarea would be a dominant part of the page and the preview div would float by.
If You need more details or help just ask in comments.
Looks like a great idea! You might have a #preview and a #input, with the preview updated with a simple event:
document.getElementById('preview').addEventListener('change', update, false);