I have a multi-line text box. When users simply type away, the text box wraps the text, and it's saved as a single line. It's also possible that users may enter line breaks, for example when entering a "bulleted" lists like:
Here are some suggestions:
- fix this
- remove that
- and another thing
Now, the problem occurs when I try to display the value of this field. In order to preserve the formatting, I currently wrap the presentation in <pre> - this works to preserve user-supplied breaks, but when there's a lot of text saved as a single line, it displays the whole text block as single line, resulting in horizontal scrolling being needed to see everything.
Is there a graceful way to handle both of these cases?
The easiest way of dealing with this is turning all line breaks \n into <br> line breaks. In PHP for example, this is done using the nl2br() function.
If you want something a bit more fancy - like the list you quote getting converted into an actual HTML <ul> for example - you could consider a simple "language" like Markdown that SO uses. It comes with natural, simple rules like
# Heading 1
## Heading 2
### Heading 3
* Unordered List item
* Unordered List item
1. Numbered List item
2. Numbered List item
etc....
You can use the php function nl2br() It transforms line breaks into elements
Convert newline characters to <br /> tags explicitly, and let the browser word-wrap the text normally. That preserves the breaks the visitor entered, without harming other paragraphs.
You could replace line breaks with HTML line breaks.
Replace "\r\n" or "\n" (depending on the browser and platform, check first for longer one) with <br/>.
I would normally replace all CR/LF with LF, and then replace all LF with <br />. You can then render this text inside any HTML container you want and let it flow naturally.
Related
When i'm trying to add extra spaces to html textarea to make my text be indented and wrapped in a right way I need, textarea trims these spaces and wraps text in it's own way.
Lets assume that dot (.) is a space. In this case things go in a way, I want them. The line '....some.........texts........here' will be displayed in text area of size (cols: 13) with monospace font as:
here we have a string in text area of max 13 chars length. And the string indented with one tab that represented with 4 chars at the beginning. So there are additional dots at the end of the lines, to make next part of string be on the next line in text area. And it works.
But if I use spaces instead of these dots, so the initial line is:
' some texts here'
in the same text as before it will look like
So textarea trimmed additional spaces in all places where it wrapped the string. Is there any way to avoid it?
UPD: Looks like this topic is highlighted here.
An HTML text area works fine with new lines ("\n") when they're after any other content in the text area, whether it be whitespace characters like spaces or tabs ("\t") or not.
However, when text area content begins with a new line (for example, "\ntest"), that new line gets cut off on display.
Any ideas on what causes this/how to remedy it?
This seems to be by the spec.
A single newline may be placed immediately after the start tag of pre and textarea elements. If the element's contents are intended to start with a newline, two consecutive newlines thus need to be included by the author.
Note that in the past there were some bugs in the various browsers regarding leading new lines in elements:
https://bugzilla.mozilla.org/show_bug.cgi?id=591988
https://bugs.chromium.org/p/chromium/issues/detail?id=62901
I am using sphinx to build latex and HTML documents with a lot of figures and enumerated lists. When I use figures in the middle of text outside of enumerated lists, the spacing is fine in both latex and HTML with and without captions. There is about a line of space above and below, which is acceptable. However When I try to use a figure within enumerated lists, such as the example below, the spacing is bad in HTML.
#. Here is an item in the list, above the figure
.. figure:: _images/myimage.png
:align: center
:width: 80 %
#. Here is another item below the figure.
The result of the above code is the bottom of the figure is right up against the next item in the list. There is no spacing between them, and this looks bad. This can be fixed in HTML by using the | character at the end of the figure to add a little space, but in the LaTeX output, this causes a DUlineblock environment that adds way too much space in the pdf.
Is there a way to simply add a single blank line after the figure in both HTML and Latex?
You can enter empty lines with:
text
|
text
I found that the replacement:
.. |br| raw:: html
<br />
Works well for adding a black line after a figure in enumerated lists. Since its a raw substitution it only affects html and the figure spacing in latex is fine without modification.
Is it possible to make sublime text consider all code within backticks to be a single word? I am including inline code in a markdown document, and it keeps breaking when I wrap a paragraph and inserts a newline in the midst of a code chunk. For example
This is the text I am writing and `r this_is_some_code`
If the line is long, and a newline falls between `r and the final backtick, then the code doesn't work correctly. Is it possible to make that whole region be considered a single word? then it would not wrap at the ruler at all.
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?