I have used google chrome (webkit) in determining behavior:
<p>Test <span style="margin-left:20px"> </span>test</p>
doesn't add margin-left, but:
<p>Test<span style="margin-left:20px"> </span>test</p>
does.
Why? Is margin-left not applied to empty elements? Why is it considered empty in one case and not the other?
(This is important for a program stripping extra whitespace)
That's because browsers by default merge two and more consecutive white characters (and space is one of them). So in the first example the space within <span> is not visible at all and that's why margin is not applied.
You can proof that using <pre> tag, which stops white character merging. Check the DEMO.
Place the <p>....</p> in between <pre></pre>.
This will shows you exactly what you needed.
Related
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)
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 using an html template to send emails programatically. I know nothing about html, but I've just learned that it will collapse consecutive white space characters, which ruins my formatting(I am emailing a table of numbers). How can I solve this problem?
Just use <pre> tag like so:
<pre>
This is some text with some extra spacing and a
few newlines
thrown in
for good
measure
</pre>
Working Example: jsFiddle
and a Good reference on pre tag.
If you don't want consecutive spaces to collapse. Just set CSS property white-space.
e.g.:
white-space: pre;
<span style="white-space:pre;"> </span>
Check this link for more info: https://developer.mozilla.org/en-US/docs/Web/CSS/white-space
Well, you can use the metacharacter to produce a "non-breaking space." (I used one in-between these two sentences. But I didn't use one here. Notice how the spacing between these sentences is slightly different, and how the last space is twice as wide because I used two tags?)
Fundamentally, I suggest that you should be using <table> tags within your e-mail body, thus identifying the data as "tabular" and giving you a rich array of options (styles, etc ...) for formatting it. It will look much better than anything you could do by means of "ASCII Art ..."
I've been working with contenteditable recently within a HTML5 page and encountering bugs when using it with certain elements, and I'd like to know where and how I can actually safely use it.
I've discovered that making a span element contenteditable results in some buggy behaviour in both Firefox1 and Chrome2. However, making a div or section contenteditable appears completely safe3.
A guideline a couple of people have mentioned is that only block-level elements should be made contenteditable. However, the Mozilla Developer Network lists the heading elements h1 through to h6 as block-level elements, and making a heading element contenteditable is buggy in Firefox4 and can crash the page in Chrome5.
I'd like to be able to use more than just divs and sections, but I'm not clear on what elements I can actually safely make contenteditable. By safely, I mean that using the element under normal conditions, I should be able to perform normal editing tasks without it doing unexpected or buggy things. I should be able to write in it, delete content, cut, copy, paste, and move my text cursor about and highlight text without unexpected or strange behaviour.
So, which elements can I really make contenteditable safely? Is there a specific category? Are there certain criteria the safely-contenteditable element must match?
Bug notes:
Firefox 21 w/ span: Element loses focus if the text cursor is brought to the beginning or end of the element, but not if it got there by deleting content. Highlighting part of the element, cutting and then pasting will split the element in two at that point then insert a blank element between the two parts - without actually putting the text you were trying to paste anywhere.
Chrome 27 w/ span: If the span covers multiple lines e.g. by being wordwrapped, cutting and pasting content will often insert a linebreak after the pasted content.
Unless you make the div display:inline, in which case it can still lose focus as in 1, but apparently only if you bring the text cursor to the end. I don't consider this "normal" usage of the element though.
Firefox 21 w/ heading: Selecting part of the content then cutting and pasting will, similarly to 1, split the heading element in half at that point, and insert a third heading element between the two halves. It will, at least, have your pasted content inside it, but now you have three heading elements where there was originally one.
Chrome 27 w/ heading: Select some content and cut and paste. The page crashes. You get an "Aw snap!" message. That's it.
Demo code
Here's a demo for reproducing the above. It's pretty simple, though at the moment the only thing it isn't reproducing is the lose-focus bug.
[contenteditable=true] {
border: 1px dotted #999;
}
<article style="width: 100px">
<h1 contenteditable="true">Heading</h1>
<p>
<strong>Some adjacent content</strong>
<span contenteditable="true">Span! This is long enough it will spread over multiple lines.</span>
</p>
<div style="display: inline" contenteditable="true">An inline div also with multiple lines.</div>
</article>
In my opinion, I'd say div is the safest bet across the board. Any element you wish to truly edit (be it a span, header, etc), you can place inside the div and edit as if it were just that element. Also, to account for the display:inline issue you mentioned, you could always use float:left or float:right on your editable div to give it an "inline feel" without having it actually be inline.
Hope that helps!
Since this is an evolving feature with, apparent, low priority from the browser vendors support has been sketchy and regressions not uncommon. The current state of affairs is evolving, so check the Googles, CanIUse etc and make sure support is there for your sites visitors, everything else is moot ...
Support in Firefox seems to be solid, at least for some elements, now https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content
It works well in Chrome as well as far as my testing goes.
And CanIUse looks good: http://caniuse.com/#feat=contenteditable
There are a number of different bugs related to the feature in the different browsers though, but for simple use cases it should be ok now, as of August 2016.
When I try to create a navigation with inline-block, I get 4px to the right of each list item.
When I do it by floating each list item, it works fine.
Is there a reason the first option is applying that 4px? I have set EVERYTHING to have a margin of 0px and padding of 0px, I don't understand it. Even Firebug reports it as having 0, yet the gap is still there.
Thanks
Yes, space is by design and should be
Is there a reason for that? Yes it is. What got added is actually a word space. The same as if you'd have two lines of text. Browsers put a space between texts in separate lines so last words don't touch first words of the next line:
<p>
This is my text that's in two lines
inside my HTML source.
</p>
There would be a usual word space between lines and inside so text gets correctly displayed in browser:
This is my text that's in two lines inside my HTML source.
The same happens in your case, because your elements are inline. Your navigation elements are listed one per line in HTML source hence a word break gets added between them.
How to avoid excessive spaces between elements?
There are basically 3 approaches to mitigate this problem. All of them work on the premise to put all elements in the same line as seen by the HTML renderer:
Put all elements unspaced in a single line:
<ul>
<li>First</li><li>Second</li>...<li>Last</li>
</ul>
This one actually puts all elements in one line which may make it harder for people to manipulate these elements. If every LI would have an anchor tag inside (with a long link), this line gets too long to handle.
Comment-out line breaks:
<ul><!--
--><li>First</li><!--
--><li>Second</li><!--
...
--><li>Last</li><!--
--></ul>
Make tags break the line:
<ul
><li>First</li
><li>Second</li
...
><li>Last</li
></ul>
This one is least obtrusive to the eye but may seem confusing to beginners hence other team members (if you work in such environment) may feel tempted to put tag ends back to where they were originally (and usually are). They may feel these were broken by error.
The result of all three of them can be seen in this JSFiddle example.
Pick the one that suits you best. I usually use commenting because it's least distracting in my development editor because comments are very subtle.