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
Related
I have created a modal box that initially hides the modal box contents with css display: none. Then, I heard from some article that using this display:none could prevent google bot from crawling the contents, and it is not good for SEO.
Instead, it recommends me to use absolute positioning to create negative position values and hide that content.
I am trying to look for some good example of modal box that actually use this technique but I was wondering if:
modal box contents are really hidden from google to crawl?
Is this common practice to use negative position value for absolute positioning when creating a modal box?
Any good example I could look?
Don't use 0 height, negative margins to hide content. Google is able to understand now that you have hidden content in this way. Actually, inserting zero height for an element with text in it might trigger a flag with the Googlebot.
If you need to send text info to the crawler, then insert that text in the meta description tag. This way visitors do not see that, but Google will.
I'm an SEO. Google never gives a definitely yes or no answer, but the general consensus is placing content in modals and hiding them results in that content still being crawled, but it is held with less significance. This makes sense as most of the information Google is looking for would/should be presented to the user when the webpage is opened, not after. The majority of your ranking results will be due to your immediate on page seo. I wouldn't experiment with trying to transition or hide content in this way as Google does have methods of detecting this sort of thing, an could result in an even worse outcome for the site.
Our angularjs site seems to be having issues with page size on mobile. It seems that when you pull up an input (dropdown or text), some area of the page behind the buttons and inputs goes white.
Regardless of where you are providing input, the white area starts at a particular spot on the page and stretches all the way to the bottom.
I've tried using Safari to inspect the DOM on mobile but I can't seem to figure out where to start debugging this. Any ideas?
On input
On scroll
I am developing a website for a report. The majority of the report fits within a column that can be no larger than 800px. However there are a couple of sections of the report that include tables that are just so detailed it is impossible to fit within that space.
The solution I am considering is to use JavaScript/jQuery to detect tables that are too large for the column and turn them into links, that when clicked, brings up a light box using more available screen space and displays the table.
This does not seem to difficult to do… but then I started considering accessibility.
So after detecting the oversized tables should I cut them out of the DOM and store them in a variable or should I hide them?
Do accessibility devices such as screen readers use the original source or do they respect changes made by Javascript?
If you hide the content with display:none then the screen reader will not see it until you toggle that attribute.
You could also rip the content out of the DOM as the screen reader only looks at the rendered DOM.
When you create a lightbox, you will have to set focus into the lightbox in order for the screen reader to read the content.
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.
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);