I am needing to style sequences of characters in a single paragraph e.g.
<span style="color:red">hello </span><span style="color:blue">world</span>
The paragraph of text flows across multiple lines. The issue is that the spaces at the end of spans are not rendered by browsers and the solutions to force them to display, changes how the lines break. This means that when the text is coloured differently at different positions, words jump from one line to another which isn't acceptable in this app.
The two methods I have tried for displaying terminating spaces that both change line breaks are:
replace terminating spaces with nbsp "\u00a0"
Although this renders the spaces, it means that it changes how rows break across lines.
replace terminating spaces with single space spans that use white-space: pre style
This also renders spaces but causes similar disruption to line breaks.
Is there anything else I can try that will not change line breaks?
Related
A colleague had a text alignment issue on a screen I completed. I was shown the issue on a Win10 PC using Chrome, and some lines of text appeared like this:
Text line 1.
Text line 2 is much longer and wraps to two lines, but the second line
does not have the whitespace added.
Text line 3 does not wrap, and has the same alignment issue.
When I viewed it on my Mac using Chrome, I did not see the issue, so I ingeniously deduced it was most likely a Win-Chrome bug with some bootstrap class, etc.
But, after digging in, the problem ended up being the format of the <p> tag content:
<p>Text line 1.</p>
<p>
Text line 2 is much longer and wraps to two lines, but the second line does not have the whitespace added.
</p>
<p>
Text line 3 does not wrap, and has the whitespace.
</p>
I'm aware that a newline in the middle of a string will infer a space in most browsers (thank god), so that you don't have to add a trailing / leading space when writing multi-line content. However, I've never seen the initial return cause leading whitespace.
The point is that there may be a lot of code formatted this way, and the client will spot the alignment issues, as they test in Win10. Why does this happen, and is it most likely a Win/Chrome bug? Is it a conscious choice by some browser developers?
References would be greatly appreciated, but I personally could not find anything relevant on SO, CSS-Tricks, or Chrome browser documentation.
EDIT:
Another colleague has confirmed that adding a <br /> within the <p> tag (no trailing / leading spaces) also generates a single leading whitespace directly afterwards.
white-space: pre-wrap preserves whitespace, so on word wrap it will not add the extra space since its located at the start of the paragraph.
either try white-space: none; or add some padding/margin if you want the whole paragraph to have that extra space even after word wrapping.
The following snippet renders (assuming) correctly without trailing space underlined in Firefox 59, but in Chromium 65 the bogus space in the end of the line before the explicit line break is rendered:
<div style="width:100px">
This is long link, <br />with a line break
</div>
Screenshot from Chromium 65:
Screenshot from Firefox 59:
The obvious fix for this case is to remove the space in front of the line break, but it is unnatural.
Is not one of the rendering wrong? Is either of the behavior specified by HTML or CSS specification or is this really undefined?
Edit 1: The same behavior as in Firefox can be observed also in the IE, so it looks like the Chromium is the only one.
The problem isn't that Chrome is underlining the trailing space while Firefox isn't. The problem is that Chrome isn't removing the trailing space when wrapping the line (when the wrap originates from a hard <br /> wrap). The space is underlined because it is there, which is inconsistent with how Chrome handles trailing spaces when auto-wrapping text.
The CSS specification on handling trailing spaces on wrapped text states:
4.1.3. Phase II: Trimming and Positioning
As each line is laid out,
A sequence of collapsible spaces at the beginning of a line is removed.
If the tab size is zero, tabs are not rendered. Otherwise, each tab is rendered as a horizontal shift that lines up the start edge of the next glyph with the next tab stop. Tab stops occur at points that are multiples of the tab size from the block’s starting content edge. The tab size is given by the tab-size property.
A sequence of collapsible spaces at the end of a line is removed.
If spaces or tabs at the end of a line are non-collapsible but have white-space set to pre-wrap the UA must either hang the white space or visually collapse the character advance widths of any overflowing spaces such that they don’t take up space in the line. However, if overflow-wrap is set to break-spaces, collapsing their advance width is not allowed, as this would prevent the preserved spaces from wrapping.
The CSS Working Group has discussed the inconsistent handling of trailing white-space on their github repo, specifically mentioning that Firefox's handling of trailing whitespace is the most ideal:
And lastly there's the point that trailing spaces just look bad, and that having a space just inside the closing tag of an inline or before a <br> is a reasonably common unintentional markup pattern that shouldn't have a bad effect on rendering. The preserved trailing space becomes noticeable both when the inline is styled, as in the example given by #palemieux, and also when we chose text alignments other than start. This gives a real-world use case indicating a preference for Firefox's behavior.
From this discussion, the earlier mentioned CSS spec has been updated (in the github repo, but not apparently published yet) to match the Firefox (Gecko) behavior. Specifically updating points 1 and 3 from above to :
A sequence of collapsible spaces at the beginning of a line (ignoring any intervening inline box boundaries) is removed.
A sequence of collapsible spaces at the end of a line (ignoring any intervening inline box boundaries) is removed.
Emphasis on changes added by me.
If we check the specification we can read this:
Underlines, overlines, and line-throughs are applied only to text
(including white space, letter spacing, and word spacing): margins,
borders, and padding are skipped.
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.
It seems to me, that HTML entity for nonbreaking space is not working properly in my code. I use: zvyšováním ceny – ta by negativně but instead of the dash and two words connected together, I see an ugly white space at the beginning of the new line. Do you have any idea how to solve this problem?
I know about about a non-breaking hyphen, but please remember there is the difference between a hyphen and a dash.
This works how it should, a line will break when there is a dash or a hyphen, but not when using a none-breaking hyphen, so by adding a will only prevent a line break at that space, hence called no breaking space ..
.. so as a result it will break at the dash and the following is causing the ugly white space at next line beginning
By removing the 2:nd , like this, it will work fine and no ugly space at next lines beginning
Some text having hyp - pen that should break after the hyphen
and another with the da – sh that should break after the dash
Fiddle demo
And if you don't want it to break, the dupe link has the answers needed, either using the non-breaking hyphen or wrap it and set the wrapper to white-space: nowrap
Dupe link: No line-break after a hyphen
The non-breaking space doesn't prevent the hyphen from being a point at which the word can break, so it effectively forces a space before and after the hyphen.
Use a non-breaking hyphen instead:
zvyšováním ceny‑ta by negativně
I think what you want is U+2060 WORD JOINER. This is intended to suppress line breaks that may otherwise occur, without introducing any spacing.
I noticed in my index.php file if I do:
Versus
There's more of a space between the two when I use a line-break. Where can I read more on this?
In the HTML specifications, any number of white space becomes a single white space when displayed.
Doing:
is identical to
Or any number of carriage returns or spaces inbetween.
If you don't have white space, then the two just run into each other. This allows things such as bolding in the middle of a word.
EDIT
Thanks to insertusernamehere, the exact location in the HTML 4.01 specification is at:
http://www.w3.org/TR/html401/struct/text.html#h-9.1
In particular, the part that says:
Note that a sequence of white spaces between words in the source document may result in an entirely different rendered inter-word spacing (except in the case of the PRE element). In particular, user agents should collapse input white space sequences when producing output inter-word space.
This doesn't technically have anything to do with HTML, which itself is just a way of marking up the page. It's actually the CSS styling that collapses white-space via the white-space property. That property gives you the following options:
normal - This value directs user agents to collapse sequences of white space, and break lines as necessary to fill line boxes.
pre - This value prevents user agents from collapsing sequences of white space. Lines are only broken at preserved newline characters.
nowrap - This value collapses white space as for 'normal', but suppresses line breaks within text.
pre-wrap - This value prevents user agents from collapsing sequences of white space. Lines are broken at preserved newline characters, and as necessary to fill line boxes.
pre-line - This value directs user agents to collapse sequences of white space. Lines are broken at preserved newline characters, and as necessary to fill line boxes.
By default, it is set to normal. This will cause a browser to collapse any sequence of white-space into a single visible space when rendering the HTML structure. Since line breaks are a form of white-space, they also get collapsed.
See 16.6 White space: the 'white-space' property
In PHP, much like HTML, a line-break/carriage return is generally just used to make your text more legible. This is so that future code edits are simple an easy to make.
Not sure if this is completely relevant but I've found another post which relates to PHP formatting: PHP Coding style - Best practices