How to get a tab character? - html

In HTML, there is no character for a tab, but I am confused as to why I can copy and paste one here: " " (You can't see the full width of it, but if you click to edit my question, you will see the character.) If I can copy and paste a tab character, there should be a unicode equivalent that can be coded into html. I know it doesn't exist, but this is a mystery I've never been able to grasp.
So my question is: why is there not a unicode character for a tab even if I can copy and paste it?

Sure there's an entity for tabs:
(The tab is ASCII character 9, or Unicode U+0009.)
However, just like literal tabs (ones you type in to your text editor), all tab characters are treated as whitespace by HTML parsers and collapsed into a single space except those within a <pre> block, where literal tabs will be rendered as 8 spaces in a monospace font.

Try  
as per the docs :
The character entities   and   denote an en space and an em
space respectively, where an en space is half the point size and an em
space is equal to the point size of the current font. For fixed pitch
fonts, the user agent can treat the en space as being equivalent to A
space character, and the em space as being equuivalent to two space
characters.
Docs link : https://www.w3.org/MarkUp/html3/specialchars.html

put it in between <pre></pre> tags then use this characters
it would not work without the <pre></pre> tags

Posting another alternative to be more complete. When I tried the "pre" based answers, they added extra vertical line breaks as well.
Each tab can be converted to a sequence non-breaking spaces which require no wrapping.
" "
This is not recommended for repeated/extensive use within a page. A div margin/padding approach would appear much cleaner.

I use <span style="display: inline-block; width: 2ch;"> </span> for a two characters wide tab.

Tab is [HT], or character number 9, in the unicode library.

As mentioned, for efficiency reasons sequential spaces are consolidated into one space the browser actually displays. Remember what the ML in HTML stand for. It's a Mark-up Language, designed to control how text is displayed.. not whitespace :p
Still, you can pretend the browser respects tabs since all the TAB does is prepend 4 spaces, and that's easy with CSS. either in line like ...
<div style="padding-left:4.00em;">Indenented text </div>
Or as a regular class in a style sheet
.tabbed {padding-left:4.00em;}
Then the HTML might look like
<p>regular paragraph regular paragraph regular paragraph</p>
<p class="tabbed">Indented text Indented text Indented text</p>
<p>regular paragraph regular paragraph regular paragraph</p>

Related

spaces and do not have the same width?

I have a div and a textarea exactly overlapped, I type in the textarea and that text is converted to spans that have varying text colors (syntax highlighting) and are then shown in the div, so it looks like you're typing in the div, but you're actually typing in the transparent textarea. At the moment I simply put a space between the spans where a space exists in the text input, but if I add more spaces in series it doesn't work (only one will show). So I tried using instead of spaces but I was surprised to find out the width of it is different from regular spaces. What is the point of then?
To the point, how can I add spaces that have the same width as regular spaces if doesn't?
And here's an example of what should be two exactly matching lines (but aren't).
<span>Hello</span> <span>World</span>
<span>Hello</span> <span>World</span>
Note: I'm using the font "FontinSmallCaps", it's possible that's the reason for the discrepancy, but I am not willing to do away with it. Would rather filter the user input to never have two consecutive spaces. Although that would be a last resort.
If anything is unclear or needs elaboration, let me know.
Thanks in advance!
Not exactly sure of your HTML structure, but whatever wraps the HTML you have shown could have white-space: pre set, then the spaces will all remain. No need to convert them.
<div style="white-space:pre"><span style="white-space: pre;">Hello</span> <span>World</span></div>
is Non-breaking space and the other is considered as normal string by browser. A non-breaking space means that the line should not be wrapped at that point, just like it wouldn’t be wrapped in the middle of a word. are also non-collapsing, that's probably the most significant aspect of their use (at least, that's how I tend to use them, pad stuff out, quick and easy)

HTML emsp entity exact behavior

I am having trouble finding an exact reference of the behavior of the HTML emsp entity. I have looked at W3.org, MDN, W3schools, and here, but I have not yet found a description that describes its breaking or wrapping behavior in HTML that does not have any special styling applied.
The code below shows an experiment I resorted to, but I am still a bit confused about when it will and will not wrap. Is there a good reference?
<!DOCTYPE html>
<html>
<style>
body {
font-size: 20px; font-family: Courier, fixed;
}
</style>
<body>
<p>Following is some text with some embedded emsp entities.<br>Here is one mid-word: sam ple. <br>And here is one on each side of a dash: lock - step.<br>Then, how about one after a period?<br>Right after the next period is one and then a normal space.  How about the standard space and then the emsp?<br>That sequence follows this sample sentence.  (Note that since the regular space came first, this can cause this text after it to become indented, whereas the emsp-then-regular space occurrence just before will never do that, I think.) As long as I'm looking at them after the end of a sentence, we should try putting just one emsp after a sentence instead of the regular space caracter.<br>I thought that would stick the two sentences together, but it does not do so here. Indeed, this is consistent with its behavior mid-word. Okay, how about multiple occurrences of it?<br>There are 3 in the brackets here: [   ] and so on. I played with that last one a bit and I cannot get it to break after the 3 emsps. Here, they seem to keep their width (they are not combined into one) and they are not breakable, not even either before the first or after the last one. So, I seem to only be able to get the "[" and never the "]" as the first character on a new line.<br>Okay, more extremely, trying brackets around 5 emsp chars, a word, and 5 more emsp chars: [     word     ] .<br>There we seem able to break before "word", but still never before "]". What's going on there?
</p>
<p>From the examples above, I think the mystery around emsp characters is mostly resolved for me.</p>
<p>Consider the standard behavior for a regular space character. Here, first remember that multiple occurrences of regular whitespace characters are all compressed as if they were a single regular space character. Then, of course, the regular space character takes a certain width, and lines are never broken just before the regular space, only after it. And the space normally allocated for a regular space character does not need to be rendered at the right edge of a box.</p>
<p>Similarly, text can break after an emsp character, but will not do so before. It is wider than a regular space character, but mostly behaves like it. Where it differs is if you have multiple emsp entities right next to each other. In that case, no break will occur before, within, or after the group (unless there is whitespace before or after it, in which case the whitespace is the location of the break). But if a set of multiple emsp characters are placed directly between two non-white characters (as in the bracket example above) then they are not compressed and no breaking occurs. That's all I'm thinking of at the moment ...</p>
</body>
</html>
emsp is a white space having the same width as the letter "M"
I found a brief description at http://opencoder.net/emsp.html
Whether it is a breaking or a non-breaking space, I would say the easiest way to find out is to test it.

Mysterious space after img tag before href

I have a mysterious space coming up between an img and href tag. My link, forwarding to a word document is preceded by a space after a small icon, that should actually not be there. Curiously the space only appears if the extension of the link is .doc but disappears when I change it to .docx, or to an .html extension.
This code...
<img src="../images/icon/wordicon_small.gif" />
template</p>
<br/>
<img src="../images/icon/wordicon_small.gif" />
template
transalates into:
I am really confused. Don’t even know where to begin. My CSS specifications seem ok and did not arouse suspicion on my side. Anybody has any idea what the problem could be?
You have a few spaces before your first <a href>
By removing the spaces the problem should be fixed.
If the spaces are generated from a script to html then you need to check the differences of handling doc and docx links between a few statements in your script.
You have white space characters (spaces, line breaks, etc.) between the images and links, so there should be a space between them, but that should only be a single space, just like between the second set of elements. Multiple white space characters in a row collapse into a single space.
Try to retype the spaces between the first image and link. My guess is that you have a non-breaking space (ASCII 160) in there somewhere. That doesn't count as a white space character, so it doesn't collapse into a single space with the spaces and line breaks.
Sometimes non-breaking spaces are used to cause extra spacing between text or elements, as they don't collapse, for example:
Price: $0.99
displays as:
Price: $0.99
The is the HTML entity for the non-breaking space, but you can also type it as a regular character. How you do that depends on the editor, but ctrl+space is used in some.

How prevent connecting Farsi Characters?

I have a problem, but maybe this is not a problem actually! Why below HTML markup is generating a result which seems to be incorrect even using Standard Fonts like Arial?
<span>سلام</span><span>خداحافظ</span>
سلامخداحافظ
Above output shouldn't be this? (ignore space used for simulation)
سلام خداحافظ
Also i have used margin for a tag but same problem.
Thanks in advance ;)
HTML elements do not necessarily break words. There are many legitimate reasons for that.
For instance, you might want to put emphasis on a letter in medial form by wrapping it in a <strong> or <em> element. If that element was considered as a single word, the letter would switch to its isolated form, which would probably not be the effect you're looking for.
Inserting either a non-breaking space ( ) or a zero-width non-breaking space (​) between the <span> elements fixes your problem.
You can see the results in this fiddle.
As i know span tag doesnt have href. I assume that u mean a tag.
u can use a space character between a tags to get desired result:
سلام خداحافظ
You can also enter an space between the to tags like. there is no need to use html codes:
سلام خداحافظ

What's the difference between " " and " "?

Both of them mean space, but is there any difference?
One is non-breaking space and the other is a regular space. A non-breaking space means that the line should not be wrapped at that point, just like it wouldn’t be wrapped in the middle of a word.
Furthermore as Svend points out in his comment, non-breaking spaces are not collapsed.
The entity produces a non-breaking space, which is used when you don't want an automatic line break at that position. The regular space has the character code 32, while the non-breaking space has the character code 160.
For example when you display numbers with space as thousands separator: 1 234 567, then you use non-breaking spaces so that the number can't be split on separate lines. If you display currency and there is a space between the amount and the currency: 42 SEK, then you use a non-breaking space so that you don't get the amount on one line and the currency on the next.
In addition to the other answers here, non-breaking spaces will not be "collapsed" like regular spaces will. For example:
<!-- Both -->
<p>Word1 Word2</p>
<!-- and -->
<p>Word1 Word2</p>
<!-- will render the same on any browser -->
<!-- While the below one will keep the spaces when rendered. -->
<p>Word1 Word2</p>
Not an answer as much as examples...
Example #1:
<div style="width:45px; height:45px; border: solid thin red; overflow: visible">
Hello There
</div>
Example #2:
<div style="width:45px; height:45px; border: solid thin red; overflow: visible">
Hello There
</div>
And link to the fiddle.
Multiple normal white space characters (space, tabulator and line break) are treated as one single white space character:
For all HTML elements except PRE, sequences of white space separate "words" (we use the term "word" here to mean "sequences of non-white space characters"). When formatting text, user agents should identify these words and lay them out according to the conventions of the particular written language (script) and target medium.
So
foo bar
is displayed as
foo bar
But no-break space is always displayed. So
foo&‍nbsp;&‍nbsp;&‍nbsp;bar
is displayed as
foo bar
You can see a working example here:
http://codepen.io/anon/pen/GJzBxo
and
http://codepen.io/anon/pen/LVqBQo
Same div, same text, different "spaces"
<div style="width: 500px; background: red"> [loooong text with spaces]</div>
vs
<div style="width: 500px; background: red"> [loooong text with ]</div>
As already mentioned, you will not receive a line break where there is a "no-break space".
Also be wary, that elements containing only a " " may show up incorrectly, where will work. In i.e. 6 at least (as far as I remember, IE7 has the same issue), if you have an empty table element, it will not apply styling, for example borders, to the element, if there is no content, or only white space. So the following will not be rendered with borders:
<td></td>
<td> <td>
Whereas the borders will show up in this example:
<td>& nbsp;</td>
Hmm -had to put in a dummy space to get it to render correctly here
The first is not treated as white space by the HTML parser, the second is. As a result the " " is not guaranteed to showup within certain HTML markup, while the non breakable space will always show up.
should be handled as a whitespace.
should be handled as two whitespaces
' ' can be handled as a non interesting whitespace
' ' + ' ' can be handled as a single ' '
is stackable, meaning you can create multiple spaces all together.
HTML will only parse one space '' and it drops the rest...
If you want five spaces, you would place 5 x
#Zoidberg is right,
example:
<h1>title</h1> <h2>date</h2>
will not display space between header markup, with
& nbsp ;
will do space :)
When having line-breaks, the line will not break when you use an $bnsp; because it's a 'non-breaking space'. This can be important if you have certain product-names or such, that always shall be written together.
Can be interesting if you (have to) use a whitespace as delimiter in numbers, like 12344567, that is displayed 12 344 567 in France. Without the the line would break in the middle of the number, very ugly. Test:12 344 567
TLDR; In addition to the accepted answer; One is implicit and one is explicit.
When the HTML you've written or had generated by an application/library/framework is read by your browser it will do it's best to interpret what your HTML meant (which can vary from browser to browser). When you use the HTML entity codes, you are being more specific to the browser. You are explicitly telling it you wish to display a character to the user (and not that you are just spacing your HTML for easier readability for the developer for instance).
To be more concrete, if the output HTML were:
<html>
<title>hello</title>
<body>
<p>
Tell me and I will forget. Teach me and I
may remember. Involve me and I will learn.
</p>
</body>
</html>
The browser would only render one space between all of these words (even the ones that have been indented for better developer readability.
If, however, you put the same thing and only changed the <p> tag to:
<p>Hello There</p>
Then it would render the spaces, as you've instructed it more explicitly. There is some history of using these spaces for styling. This use has somewhat been diminished as CSS has matured. However, there are still valid uses for many of the HTML character entities: avoiding unexpectedly/unintentionally interpretation (e.g. if you wanted to display code). The w3 has a great page to show the other character codes.