I tried this in Chrome. Having a textarea with a lot of text inside, editing the parts at the end become super slow. The cursor and the keyboard input response comes to a crawl.
But if I make it so that the CSS links are moved from the <head> to after </body> it not longer becomes slow. Any ideas why this phenomenon exists?
Code used:
<!DOCTYPE html>
<html>
<head>
<style>textarea {width: 400px; height: 400px;}</style>
<link href="1.css" rel="stylesheet" type="text/css">
</head>
<body>
<textarea name="content"></textarea>
</body>
</html>
This html is actually generated by backend scripts, which will fill the content of the textarea with thousands of lines of text. When the user scrolls down to the end of the content, that's where the slowness begins. If the css at the head area is removed, it will be fast.
Set spellcheck to false:
<textarea spellcheck="false"></textarea>
It might help.
By Augustin suggestion, you can also try adding these guys:
<textarea autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false">
I stumbled also over this issue, in my case only chromium browser is affected.
-> https://code.google.com/p/chromium/issues/detail?id=237433
I had the same problem, but I solved it with the next attribute ng-model-options="{ updateOn: 'blur' }"
try with
<textarea ng-model-options="{ updateOn: 'blur' }"></textarea>
Without seeing a live example, it's difficult to say. But a couple of possible reasons:
You're using custom fonts in the textarea (font-face? SIFr?) which is slowing the browser down due to the additional overheads required. Particularly if you're using something like SIFr!
A validation issue: is your HTML/CSS valid? Try running it through the W3 validations: (HTML, CSS).
Are you using JavaScript on the page? Perhaps some validation or other process that might be triggered by using the textarea?
My gut expectation would be that it's one of the last two points above, to try and help trouble-shoot, try:
Running your markup through the validators and resolving any issues raised. Does it still do it?
Disable JavaScript and load the page. Does it still do it?
I expect you will be able to narrow down the reason very quickly then.
PS: don't put the CSS anywhere but in the head - that will cause you all sorts of other problems!
If the problem only occurs in Chrome, it could be the spellchecker.
According to the link provided by #PapaKai, disabling the spell checker might help. (recently suggested)
You can disable spellchecking on just the textarea with <textarea spellcheck="false"> as explained in this answer
Related
How do I set the autofocus attribute on an element with reagent, so that the produced HTML looks like below?
<textarea autofocus></textarea>
The effect of course being that the text area will have the focus of the browser once the page is loaded.
I haven't found a way to produce the sought after HTML, but the same effect seems to be achieved through JS by adding the :auto-focus option to your element:
[:textarea {:auto-focus true}]
For the benefit of anyone else searching this topic, I'll add that my own issues with :auto-focus turned out to be due to my password manager plugin. The accepted answer works just fine with the plugin turned off.
Hi I'm working on an iOS web app. I can't for the life of me figure out how to disable autocorrect/autocapitalize/spellcheck on a pre element. My HTML looks like this.
<pre id="codePre" class="prettyprint" contenteditable="true" > Some test to edit </pre>
Setting autococorrect/autocapitalize/spellcheck attributes has NO effect (these seem to be only for form and input elements). Are there any ways to go about this at the html level or using objective C (like acting directly on the UIWebView or otherwise)? Are there user defaults I can set that would kill this unneeded 'feature'?
This question is a tad long, but it might help to have at least 1 proposed solution. Try adding autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false" to any element where you don't want auto-correct turned on. Works on the latest Chrome and Firefox, unsure about Mobile Safari.
I just had a look at html of my twitter page as part of learning HTML. At the end of the page I can see a lot of state as the value of a hidden input tag (the value appears to be in json form).
I see no obvious form associated with this, and it doesn't appear in the html request.
I wonder if anyone might be able to guess how/why these inputs and their values might be used.
</body>
</html>
<input type="hidden" id="init-data" class="json-data" value="
{"scribeMetrics":0,"environment":"production","wtfOptions":
{"dismissable":true,"connections":true,"pc":true,"limit":3,"
disabled":false,"display_location":"wtf-component"}
........ and so on.
If you look at this javascript file, you see that the init-data element is used
var a=$("#init-data").val(),
b=JSON.parse(a),
c=$.makeArray(arguments);
b.moreCSSBundle?using("css!"+b.moreCSSBundle,d):d()}if($("html").hasClass("debug"))
//and so on
If you want to know, why they used a hidden field and not standard javascript variables, you have to ask the guys responsible for this at twitter themselves ;). I see no obvious reason and the minified code doesn't make it easier to understand what's going on.
I am reworking some old, hand-crafted HTML. Is the style= attribute doing anything here?
<script type="text/javascript" style="behavior:url(#default#clientcaps)" id="..." src="..."></script>
I find a lot of hits searching for style=behavior:url(#default#clientcaps)}, but will this have any effect on a <script> tag?
style is not a valid attribute on a <script> element (W3C), so it's not doing anything. Even Internet Explorer, which is the only browser that supports CSS behaviors, is ignoring it.
It is some ugly MS stuff.
Provides information about features supported by Windows Internet Explorer, as well as a way for installing browser components on demand.
Try get get to the person who added it and tell him he's a bad guy! ;)
I think in this case the style attribute is used just for a short hand for creating a style tag.
short for:
<STYLE>
#media all {
IE\:clientCaps {behavior:url(#default#clientCaps)}
}
</STYLE>
Its specific to Internet Explorer. For what it does exactly you can read more here:
clientCaps Behavior
I'm doing something rather elementary - doing a <textarea cols="60" rows="35"> textarea scrollable text box.... the problem im getting is html keeps popping up regardless of whether its written in wordpress html or text mode - in text mode on wordpress, when the selected say <br> is selected, it selects all the text, so i cant delete that or it will delete all the text....
It's a bit unclear to me what your problem is exactly. If you posted the problematic html we could use an editor to play around with it and try and help find a solution.
I suspect you aren't "closing" the textarea tag:
<textarea name="thingy" cols=10 rows=5></textarea>
^^^^^^^^^^^