Just wondering if anyone has any ways of adding paragraph spacing visuals to text inside a textarea via CSS, or even JS?
I'm aware of line-height but would like to add the impression of spacing before/after paragraphs themselves inside of a textarea, instead of having to hit enter twice inside the textarea to get a space between paragraphs.
Is this possible with a textarea alone or do I need to consider rich text editors, or maybe even writing a simple text editor myself with paragraph spacing? (I'd rather not go this route as I am merely after paragraph spacing, not all the additional formatting options that comes with text editors)
Nope. Without the line-spacing property you cannot add space between paragraphs in a textarea without altering the value of the area. This is not something that JavaScript or CSS selectors can do.
Yes, it should be possible with JavaScript by replacing the value of the textarea while listening for keyboard event values, specifically for the Enter key.
You store the value in a variable, and whenever a user hits enter (its event value is 13), it takes that text and adds a new line to the end. Now that becomes the value stored in the variable, and a new line is added the next time the user hits enter, and so on.
Here's an easy implementation if you're already using jQuery:
$('#my-text').keypress(function(e) {
if(e.which === 13) {
var text = $('#my-text').val();
$('#my-text').val(text + '\n');
}
});
e is the keyboard event passed in as a parameter, and when that happens to be an enter key, the code stores the text value and then replaces the value of the textarea with that value plus a new line.
Here's a demo on codepen:
http://codepen.io/denmch/pen/qNyjZE
Related
I'm trying to create a custom simple text editor so I can color certain pieces of text as the user types. So for some pieces I may want to make green, others blue. To do this I need to bind my content to the innerHTML property of the div which is working fine to initially display my content. (I can see my html rendering in the div).
<div class="textarea-editor" contenteditable="true" [innerHTML]="getBuiltRules" (input)="onRuleEditorFullKeyUp($event.target.innerHTML)"></div>
Then in the input event, I'm grabbing the current innerHTML and want to search and surround certain strings with <span class='color-green'></span> so this text would show green, then I want to have the changes rendered back to the div.
onRuleEditorFullKeyUp(value: string) {
// search and surround some text with html tags then set a variable
this.setBuiltRules = value;
}
The issue i'm having is once I set setBuiltRules = value, it seems to re-bind the innerHTML and the carat position goes to the very beginning. So if i'm typing something, it goes to the beginning after each character.
Is there a better way to do this so I don't lose my cursor position?
Note: setBuiltRules and getBuiltRules reference a service property.
I have an input field, at the end of which i've created a character counter:
The problem is that now, it is possible to type beneath the counter which is no good:
I would like the typing area to be restricted a certain distance before the end of the input field, something like this:
I am aware of maxlenght but since the letters have different lengths i.e. you can fit 183 "i" but only 57 "W", which would make for a really unintuitive typing experience, if your typing is cut off at the middle of the field.
The two possible solutions that occur to me.
1.
Simply shortening the input and positioning the counter next to the input, then styling a common parent element to look like the input. This is the more simple and less error prone solution.
2.
This way is a bit more complicated, but basically what you would do is create a hidden element somewhere (NB not display: none;) with the same font size/weight/family and attach a keydown event handler to the input field.
In this handler you copy the contents on the input to the hidden element, measure the width in pixels and compare that to your input. If the difference is too small, you return false in your input handler, making sure you're not preventing the user from pressing delete or backspace first.
It should be noted however that this method is pretty difficult to get right and I would consider it to be the "dirty" solution.
I have the following div in UIWebView:
<div contenteditable="true"></div>
If the user inserts new line (using the return key in the visual keyboard), and when he is done he clicks on done in the previous/next/done grey visual keyboard, it combines the lines to one line.
How can I avoid it?
Perhaps this JSFiddle can shed some light onto what's happening within your application. If you type some lines in the top DIV (gray background color), the HTML code that you get as the return value of its innerHTML property will first display in a textarea field below it (including HTML tags formatting). As you will soon see it's not merely what you'd expect to handle in your application ('line one' + CRLF + 'line two'...), but it also contains HTML elements separating lines one from another. That's how browsers are able to display contenteditable DIVs as if they're 'memo' type controls - by parsing their HTML (that's what browsers do). This HTML formatted text is also how your application receives user submitted text, and there you have to decide what to do with this formatting. You can either strip them away (which is, I suspect, how you set that object's property and it deals with that for you) replacing HTML elements like <DIV></DIV> and so on with a space character, or choose (with your control's property, or in code) to handle this formatting whichever way you'd like them to be handled. I'm not familiar with UIWebView though, and you'll have to find on your own how to retrieve complete HTML formatted values that you want to apply to the next DIV element that you're displaying (or same one that you're assigning new values to).
UPDATE: After searching the web for UIWebView reference, I've actually stumbled across one related thread on SO that shows how to retrieve innerHTML value of an element in your underlying HTML document:
//where 'wView' is your UIWebView
NSString *webText = [wView stringByEvaluatingJavaScriptFromString:#"document.getElementById('inputDIV').innerHTML"];
This way you'd be able to retrieve the whole innerHTML string contained within the contenteditable DIV that you use in a webText string variable and parse its HTML formatted text to whatever suits your needs better. Note though, that different browsers format contenteditable DIVs differently when Enter Key is pressed and some will return the next line enclosed in a new DIV, while others might enclose it in paragraph P and/or end the line with a break <BR> or <BR />, when shift+enter were used together to move to the next line. You will have to account for all these possibilities when processing your input string. Refer to the JSFiddle script I wrote using your UIWebView component to check what formatting applies.
Of course, in your case, it might be simpler to replace your contenteditable DIV with a textarea that will return more commonly formatted \n end-of-line (CR+LF). DIVs however are easier to design, so choose whichever suits your needs better.
Cheers!
I don't believe there's a solution to this from the objective-c side of the stack. The standard HTML- element only delivers a single string. It might be possible to achieve through some javascript magic or similar on the web-end of things.
My HTML-skills are not up to scratch but if you also control that end perhaps changing the to a textArea might help?
Alright, So I have an issue that is a bit weird. I am using a RichTextEditor and have allowed the user to re-size it. All the controls have been stripped away to a main toolbar such that the RichTextEditor just looks like a box with text in it. I have an issue where when I save the htmltext generated by the editor and then re-render it later it always adds an extra line break at the end of the text. I've found that this is due to the paragraph tag, and since I want the user to be able to align text I have to keep it. Does anyone know how to strip this last line break without stripping all the formatting?
I hacked a fix for this, basically involves stripping the last closing paragraph tag </P>. RichTextEditor is ugly :(
This is absolutely a bug, and it is triggered by setting the "htmlText" property instead of the "text" property. This occurs whether you assign it in code, or cause the designer to set "htmlText" instead of "text" by checking the "render as html" button in the properties for the text field. Also of note, this only occurs on "input" type TextFields. And if you start with a "dynamic" type textfield and subsequently set "type" to "input" (also have to set "selectable" to true or cursor will be invisible (another bug)), you will see the extra line appear right in front of your eyes. Again, this does not effect dynamic text fields, just those in input mode.
Despite the fact that the htmlText property is identical in both cases whether you assign a string like "Hello" to text or htmlText (the htmlText value generated is identical for either), the extra line only appears when setting the htmlText property.
Specifically, it occurs when you set htmlText to a string that actually contains html paragraph tags. If you just assign htmlText some text like "Hello", the problem will not occur. On the other hand, if you assigned htmlText <p>Hello</p> or you assigned htmlText to itself (which you need to do to preserve the html and force the internal metrics to update immediately), then the problem occurs. Someone mentioned, if you omit the closing </p> tag, the problem won't occur, and that's true. It's also true that assigning something like <a>Hello</a> won't trigger the problem.
So in summary, this problem occurs only when one sets the htmlText property of an auto-sized, multiline, input type text field to a value that contains <p></p> tags. It does not occur with dynamic text fields, nor does it occur on input text fields that are not autosized, nor does it occur on those who are autosized but not assigned <p> tags to htmlText.
To reproduce this problem, set up a text field in the designer and make sure the background and outline is turned on so you can see the size of the field, then it will be a single line high (multiline text field) as expected (assuming it's wide enough). If you then go to the code and set txtfld.htmlText = txtfld.htmlText (set it to itself), this mere assignment of htmlText property (to it's own same value) causes an additional line to be added. And the value of htmlText is in fact the same, it hasn't actually snuck in an extra <p> tag or anything... it just displays this trailing return that shouldn't be there. As expected, the same thing occurs when you check "render as html" in Flash properties for the text field, which seems to cause it to set htmlText instead of text, and causes the problem to appear.
It's unlikely that there are actually two rendering modes, since it technically always renders htmlText (i.e. htmlText always has a value, and you could always set the text format of some segment of the text with setTextFormat, which was originally assigned with "text", and that doesn't trigger some kind of switch to "html rendering mode" or anything like that.
The behavior seems to strictly come as a result of assigning htmlText property.
The only way to avoid it (aside from setting htmlText, reading back the value, stripping the last </p> tag off, and reassigning it), is to just initialize all your text fields as plain "text", and then manually apply the formatting through calls to setTextFormat( TextFormat, beginIndex, endIndex).
The true catastophe of this bug, as mentioned in the original problem post, is that you cannot save and restore the htmlText value of a TextField, because setting htmlText to a string containing html (specifically the p tag), causes this extra line to be added, compounded by the fact that if you specifically want the textfield to be sized right, you'll probably have autosize turned on, and that's specifically when this problem creeps up and ensures the size is NOT right.
I had a similar headache with flex html text components. Flex does not have proper support for many html cases. You'll see extra padding for <p> and <li> all the time. Heck, there isn't even support for the <ul> tag. If there is a line break in a normal text, flex appends extra padding at the end of the tags and removing this line break will remove the extra padding.
However, you might want to use something like this: http://code.google.com/p/flex-htmlfilter/
I've asked a few other questions here about this system, so I'll try to avoid repeating a lot of detail.
The short version is that I have many html pages, each with a form that accepts input, but never saves the input anywhere- they are only ever printed out for mailing. A previously developer who had never heard of #media print did the initial work on most of them, and so he came up with some... odd solutions to hide the ugly text boxes on the printed page, usually resulting in two completely separate copies of nearly the same html. Unfortunately, that broke the back button in many cases, and so now I must go back and fix them.
In some cases, these html forms really are form letters, with text inputs in the middle of the text. I can style the text inputs so that the box doesn't show, but they are still the wrong size. This results in a bunch of extra ugly whitespace where it doesn't belong. How can make the inputs fit the text entered by the user?
The best I can come up with at the moment is to have a hidden <span> next to each input that is styled to show instead of the input when printing, and use javascript to keep it in sync. But this is ugly. I'm looking for something better.
Update:
Most of our users are still in IE6, but we have some IE7 and firefox out there.
Update2:
I re-thought this a little to use a label rather than a span. I'll maintain the relationship using the label's for attribute. See this question for my final code.
The span idea isn't that bad. With a Javascript library like jquery, a single 1-2 line Javascript function could dynamically replace all the appropriate <input> tags with <span>..</span>. You wouldn't have to enter in any of the spans yourself.
In really rough pseudo-javascript code with jquery it would be something like:
function replaceInputsOnSomeButtonClick() {
// Find all inputs, wrap value with span tag, remove the input tag
$("input").text().wrap("<span>").remove();
}
CSS doesn't have answer for this one. Inputs are "replaced elements" – a black box in CSS.
input {content:attr(value)} works only for initial value in HTML, and won't reflect any later changes.
So the best you can get is less ugly Javascript.
for(var i=0; i < form.elements.length; i++)
{
var input = form.elements[i];
if (input.type != 'text') continue;
var span = document.createElement('span');
input.parentNode.insertBefore(span,input);
span.className = 'show-in-print';
input.className = 'hide-in-print';
input.onchange = (function(span){ // trick to preserve current value of span
return function()
{
if (span.firstChild) span.removeChild(span.firstChild);
span.appendChild(document.createTextNode(this.value));
}
})(span);
}