I have two span tags that contain content. The first span tag will hold content from the client and the second acts like a "blipping-cursor" (I'm using JavaScript to turn its "display" style from inline to none every 500 milliseconds). Currently, everything works great except for the fact that there is a bit of spacing (just a bit in IE and a TON (one or two spaces worth) in Webkit (nested parenthesis for the win!))) between the content in the first span and the second span.
So my question is simple (well, the question, the answer may or may not be easy), how do I remove this space currently occupying the spot between span one and span two?
Here is a jsFiddle: http://jsfiddle.net/DalexL/6pZB3/
As you can see, there is a highlightable single-space in between the two spans content.
Thanks if you can!
Without seeing any code, I'm going to go out on a limb and say that you have a line break in between the two spans:
<span></span>
<span></span>
That will cause a space sometimes. If you get rid of it, the space should go away:
<span></span><span></span>
Related
I'm making a rich text editor which is like a clone of Google Docs. For reasons I won't get into here, each line in the text editor is wrapped into its own div container. For example, if there's 3 lines of text, there will be 3 child "line nodes" (rendered as an unstyled div) in the text editor. And within each line node there are inline span elements to control styling such as Bold, Italic, etc.
The issue I'm having is I can't understand why there is an unsightly vertical gap of whitespace between each line when selecting text over multiple lines. I am using Draft.js for this, but from what I can see it shouldn't make a difference; there's no styling or margins applied. I've even tried making every line div and its span elements exactly the same height but the problem persists.
My guess is this is caused by some native browser behaviour. All I really care about though is: can I "fix" it? I mean, I know it's possible because Google Docs doesn't have this spacing issue when selecting text... But then again it uses a completely custom rendering engine with custom cursors too. Thanks for any suggestions
edit: so a temporary workaround I've found (see image below) is to reduce the height of each div and span to a fixed value (in this case, height: 16.4px). But for obvious reasons, this isn't an ideal solution. I'm still looking for a "proper" way to implement whatever styling I want and not have these gaps appear between adjacent divs when selecting text
I believe your talking about line-height in which you can control the space between two elements / texts.
Try it out below:
div {
line-height:100px;
}
<div>Hello World!</div>
<div>How are ya?</div>
Thank you for all the suggestions. Turns out this is quite a challenging issue and there's very little (if anything) that can be done with pure CSS. Only the height attribute of div or span elements appear to have any visible impact on text selection. Inspecting the Google Docs elements reveals they use their own custom selection engine:
Closing this because I at least know how a solution might be implemented now, even if it would be very complex and time-consuming. Thanks again for the suggestions.
In a previous question I got some excellent answers for placing 3 boxes in a row:
Can I place boxes three in each row, equally spaced and glued to container on left and right?
There is a nagging problem there. For the solution to work I have to put font-size:0 on the container. Which means I have to specify absolute values for fonts in the boxes.
Not really what I always want. Can I avoid that font-size:0?
Here is a new fiddle: http://jsfiddle.net/lborgman/BUYZ3/2/
Yes, you can avoid it by not leaving any whitespace in the markup between those elements..
One way to do that is to use html comments between the elements (in order to keep the code formatting you want)
<div id="container"><!--
--><div>one</div><!--
--><div></div><!--
--><div>three</div><!--
--><div>four</div><!--
--><div>five</div><!--
--></div>
demo at http://jsfiddle.net/BUYZ3/4/
The other is to just remove the whitespace
<div id="container"><div>one</div><div></div><div>three</div><div>four</div><div>five</div></div>
demo at http://jsfiddle.net/BUYZ3/5/
For this specific example you could also (more appropriate really..) float the elements..
float:left;
http://jsfiddle.net/BUYZ3/6/
We are trying to create a menu style layout. I'm using a css-columns properties to achieve the effect of columns. The content is variable, so we'd like to stick to this solution because we want the browser to organise the content for best fit.
In the example below we are seeing some odd behaviour in Chrome (Version 32.0.1700.77) and some different (but equally odd) issue in Firefox (Version 24.0) so I'm assuming it's our implementation.
In Chrome, we see a large gap underneath the first column as if it's placing the 3rd LI there to start off with, then moving it to the top of the second column at some point in the render process.
In Firefox, we see the H3 "scrambled egg" being left at the bottom of the first column, when the rest of the 3rd LI's content moved to the top of the second column.
Live Example: http://codepen.io/daviddarnes/pen/BeEIp
Speculations:
- We are using "break-inside: avoid;" on every element inside the OL. This could be causing the issue, but we can't seem to rectify it.
- Based on the H3 issue... might be something to do with that? Or the elements near to this H3 tag.
The point of the page-break properties is not to shrink content to fit on a page, but to help decide the optimal place for a page break to occur.
So, if you use 'page-break-inside:avoid' on an element, and there's not enough space on the current page to fit the entire element, the browser will consider inserting a break so as to force the element onto a new page, theoretically giving it more space.
However, if the element is so big that moving it onto a new page won't help, then there's nothing to be done (in terms of page breaks at least).
If you know in advance that your content will need to be shrunk when printing, you could try adding a scale transform on the problem elements (restricted to the print media type), so that they're a more manageable size.
Is this of any help to you?
I'm trying to build a 2 column layout with a consistent vertical rhythm (aligned baselines). The calculations for this are pretty straightforward, and I have them working fine. My question is this:
When two columns of text sit side by side, is it possible to have vertical rhythm maintained (or regained) when the vertical-margins in the columns are not 'whole lines'.
In this example: http://jsfiddle.net/beejamin/PMCXt/ I have an unordered list, where both the list, and the list items have 'half a line' of margin-bottom. When there are an even number of list items, the margins add up to a whole line, and the rhythm is kept (that's good!). When there are an odd number though, the baselines are thrown out, and can't ever join up again (unless I get lucky and another odd-numbered list comes along).
Setting whole-line margins on list items is too much (especially with a long list), and setting no margin is not enough.
Is there any way I can avoid/mitigate this? I won't know the number of lines in advance, and I don't want to use javascript for this (I'm trying to build a generic scheme that I can re-use).
OK, so here's a pure CSS solution. It relies on :nth-child and :last-child selectors, so only browsers that support those selectors will do it. That's good enough for me, seeing as it's really just a nice piece of polish. It would be easy enough to apply for older browsers with some javascript, too.
Here's the working example: http://jsfiddle.net/beejamin/DpSzW/
The key is this selector:
li:nth-child(odd):last-child { margin-bottom: 1.6em /* One full line */}
This adds a full line's margin to the last-child of a list, whenever the last-child is also an odd-numbered child. The full line margin replaces the half-line the item would normally have, and so the vertical rhythm is restored. Basically, it makes any list always take up an whole number of lines.
When a list has an even number of items, the selector does nothing, and everything stays nice.
Not 100% sure, as I didn't test in all conditions, but this seems to work.
Keep the line-height the same.
keep the margins the same as the line-height.
keep the font-size the same.
Example: http://jsfiddle.net/jasongennaro/PMCXt/1/
Page in question: http://www.rjlacount.com/public/lander/
I'm probably just doing something stupid, but I'm trying to indent the second line of wrapping text inside the form (with "Your account: test#test.com" at the top) and I can't seem to get anything to work.
I would think the solution is:
form span {padding-left:1.5em;text-indent:-1.5em;}
but this only seems to indent the first line of each section.
Another look at this would be much appreciated, thanks!
If the element is inline it will indent the first line, otherwise if it's a block element it will indent the rest of the lines, which is just like Briguy37 said, since that's the difference between DIV and SPAN.
I just wanted to clear out that it's not a "problem with span".
For some reason, this works with a DIV, but not with a SPAN. Not really sure why, but here's a fiddle with the same CSS for both.
spans are handled as inline elements.
Considering them as actual characters helps to conceptualize the changes. A space after a span is retained because it's like a space between characters. You adjust height by line-height rather than simply height. etc etc
Usually if this is causing a problem you can just use a div and set display:inline-block; if you need horizontal alignment.