Is it possible to ignore white space between characters inside a text input field
let's say a user types in "bri an" instead of "brian.
Is there a way that white space is ignore and treated it as one word?
One of many ways is to use the TextField.restrict property. Simply prevent spaces from being typed into your textfield in the first place by doing this:
myTextField.restrict = "^ ";
The ^ means to disallow the following characters (in this case we are disallowing a space).
I put an example on wonderfl http://wonderfl.net/c/teOC
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.
See the description before Example 6 in the CommonMark spec at: http://spec.commonmark.org/0.27/#example-5
I am trying to understand how the following code leads to a code-block starting with two spaces.
>→→foo
Example 6 shows that this would translate to the following.
<blockquote>
<pre><code> foo
</code></pre>
</blockquote>
But Section 2.2 clearly states:
However, in contexts where whitespace helps to define block structure, tabs behave as if they were replaced by spaces with a tab stop of 4 characters.
So as per my understanding, the above Markdown behaves like the following (I denote a space with a dot).
>........foo
Since, one optional space is allowed after >, and 4 spaces are used to indent code block, we are left with,
>...foo
That's a code-block starting with three spaces. How does CommonMark claim then that it should lead to a code-block starting with two spaces? What am I missing?
The key is in the very first paragraph of the Tabs section (emphasis added):
Tabs in lines are not expanded to spaces. However, in contexts where whitespace helps to define block structure, tabs behave as if they were replaced by spaces with a tab stop of 4 characters.
Notice that is says "4 characters" not 4 spaces.
If you configure your text editor to use a tab stop of length four and to replace tabs with spaces (any good text editor should offer this setting), the text editor will use columns that are four characters wide. When you press the tab key, it will forward the cursor to the next column, which will only every be four characters wide. If the column already contains any characters, then only as many spaces are added to total four characters, which, in this case would be less than four spaces.
For example, if you type an angle bracket (>) character in your editor and then press tab, you will get the following (when configured to replace tabs with spaces):
>···
Therefore the angle bracket plus the tab moves forward to the end of the column (four characters) for a total of three spaces. As we are now at the beginning of the next column, pressing tab a second time would move us to the next column (4 more spaces) for a total of 7 spaces:
>·······
We can confirm this is the correct interpretation with a more recent change to the spec committed in 3bc01c5dc (which apparently hasn't made it it to a release yet). As the commit comment suggests, the clarification helps the math make more sense (emphasis added):
Normally the > that begins a block quote may be followed
optionally by a space, which is not considered part of the
content. In the following case > is followed by a tab,
which is treated as if it were expanded into three spaces.
Since one of these spaces is considered part of the
delimiter, foo is considered to be indented six spaces
inside the block quote context, so we get an indented
code block starting with two spaces.
Notice the added sentence (in bold) which confirms that the first tab only adds "three spaces".
Therefore, as we have now established, we start with an angle bracket plus seven spaces. So first we break off the blockquote deliminator, which consists of the angle bracket and the first space (in the following examples the | is used to indicate where the parser breaks the string and should not be counted as characters):
>·|······
The text contained in the blockquote is now indented six spaces. Four of them are the code block deliminator:
>·|····|··
Which leaves two spaces at the start of the code block.
Of course, as stated back at the beginning (of the section in the spec), the tabs aren't actually replaced with spaces, it just behaves as if they were. And that can be confusing at times. It may help to configure your text editor to always replace tabs with spaces and then you can avoid this confusion.
I've got textbox in SSRS report. Textbox consists of 2 placeholders. Second one is long enough for line to be split several times. I want text to be wrapped on spaces, but it's wrapped on plus and minus signs instead. I need "a-b+" and "Ss-+" to be kept together.
Text is fetched from database, I have full control but can't predict exact length or particular order.
My guess is that engineers who've implemented wrapping thought of plus and minus signs as a part of math formula. That's wrong in my case.
So far I've tried to add HTML tags: makes each block occupy whole line and makes no effect. I need something like display: inline-block
I've tried creating several placeholders for each non-breaking value - no effect.
If I replace plus and minus signs with letters, placeholder wraps text just fine:
One obvious solution would be to calculate required character length to add manual line breaks (vbcrlf). But it can't be done easily since it's not a monospaced font.
Is it possible to prevent word wrapping on plus and minus signs?
I'm writing a basic text generator and in some of the fields, I needed to allow the user to write more than a single line. I know that doesn't allow multiple lines so I had to use but I was wondering if there was a benefit to using <input>.
Thanks in advance!
There is a large number of functional differences between input and textarea elements. For example, for input, you can specify the required pattern of input data or to provide a set of author-supplied alternatives in addition to letting the use enter his own choice.
However, if you need to let the user enter an unlimited number of input lines and to type a long piece of text in a reasonable way, you more or less need to switch from input to textarea (or to a contenteditable block).
On the other hand, if the input consists of separate lines, like a postal address or a list on entries, one entry per line, rather than freely flowing text, input elements may be more practical.
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.