I have this html:
<dl>
<dt>some text</dt>
<dd>12.45</dd>
<dt>some larger text</dt>
<dd>46.05</dd>
<dt>some even larger text</dt>
<dd>46.05</dd>
<div style="clear:both;"></div>
</dl>
...and this CSS:
dl {
width: 120px;
}
dt {
float: left;
clear: both;
}
dd {
float: right;
}
And it's producing this (I added some unimportant extra styles to show what's going on):
The problem is, the last dd is not aligned to the last dt. How can I make the number align to the last line of the text? (The second dt/dd is fine)
Here is a jsfiddle with my predicament.
EDIT: To be perfectly clear, this is what I want:
Brief moan
A flexible approach to this has been a known gap in CSS for 15 years. It would be solved but for a 15-year-old Firefox bug relating to CSS 2, and may have been possible if the tab-stops specification suggested 17 years ago ever got off the ground. See the updates below for more details if you're interested.
A limited solution
I found a few different ways of doing this without changing the markup by using pseudo-elements. All of them have significant drawbacks, but if you can reliably establish a maximum width for the dd text, this is probably the best way:
dl {
line-height: 1.3em;
overflow: auto;
width: 140px;
}
dt {
float: left;
width: 100%;
}
dd {
float: right;
margin-top: -1.3em; /* i.e. minus line-height */
}
dt:after{
content: '';
display: inline-block;
width: 3.5em; /* Max width of a dd element */
}
Example: http://jsfiddle.net/Jordan/p4mMa/3/
Here, the :after pseudo-element takes up extra space in each dt, causing it to break onto a new line if there won't be enough room for the dd element to fit on the end of the current one. (You will also need to reset your margins and padding on the elements, I've left that stuff out for concision.)
Alternatives
Other approaches I considered included display: inline on the dt and using the :before pseudo-element with display: block to break the line (WebKit doesn't like this) and the same approach, but using display: inline-block and width: 100% to appease WebKit browsers (works, but you have indelible empty lines before each dt).
It bears mentioning that IE7 and IE8 are out, since they don't support pseudo-elements. If you're up for progressive enhancement, just remove the negative margin on the dd element in a conditional stylesheet and the prices will always be displayed on a separate line in those browsers.
UPDATE (2013-04-18): I know this is an old answer, but a recent Twitter conversation reminded me of something I think is worth mentioning. There's another way of doing this that doesn't require guesstimating a width for the dd: the little-known display: run-in essentially allows you to treat a block-level element as inline content of its next sibling. The only compromise is wrapping your dd content with a span; other than that, it's a relatively elegant solution that works in most modern browsers—and even IE8!
The problem? A 15-year-old Firefox bug, filed on Christmas Eve 1998 and unlikely to be addressed any time soon.
It's understandable: run-in boxes are "horribly underspecified", there aren't so many use cases and there are more important/useful things to work on. Still, it seems to have slipped through the cracks to an extent, and I can't help but wonder if more people would use it given reliable support.
UPDATE (2013-11-13): This exact use case was described on a list of suggested extensions to CSS published by the W3C in December 1998. Also, way back in January 1997, Dave Raggett authored proposal for a tab-stops property that would have worked admirably here. Sadly, neither the use case nor the proposal gained much traction.
Your problem becomes no problem if you don't mind switching to ul/li/span:
http://jsbin.com/acunew/3/edit#html,live
<ul>
<li>some text <span>12.45</span></li>
<li>some larger text <span>46.05</span></li>
<li>some even larger text <span>46.05</span></li>
</ul>
The new HTML isn't quite as semantic as yours was, but I think it's fine.
The CSS is almost the same:
ul {
width: 120px;
padding: 0;
list-style: none;
overflow: hidden;
}
li {
clear: both;
}
span {
float: right;
}
I think Zuazua's on the right track. I would add some javascript to detect which dt has a width that's greater than 120px. Then I would apply Zuazua's class to its sibling dd. Of course, I would change the name of the class to better suit your needs.
I think j08691 was very close to the answer, you just need to use position relative and a negative margin.
http://jsfiddle.net/3UyKG/
Related
A few other questions have already addressed how best to apply text-align: justify to get inline-block elements to spread out evenly… for example, How do I *really* justify a horizontal menu in HTML+CSS?
However, the 100% width element that "clears" the line of inline-block elements is given its own line by the browser. I can't figure out how to get rid of that empty vertical space without using line-height: 0; on the parent element.
For an example of the problem, see this fiddle
For my solution that uses line-height: 0;, see this fiddle
The solution I'm using requires that a new line-height be applied to the child elements, but any previously set line-height is lost. Is anyone aware of a better solution? I want to avoid tables so that the elements can wrap when necessary, and also flexbox because the browser support isn't there yet. I also want to avoid floats because the number of elements being spaced out will be arbitrary.
Updated the "Future" solution info below; still not yet fully supported.
Present Workaround (IE8+, FF, Chrome Tested)
See this fiddle.
Relevant CSS
.prevNext {
text-align: justify;
}
.prevNext a {
display: inline-block;
position: relative;
top: 1.2em; /* your line-height */
}
.prevNext:before{
content: '';
display: block;
width: 100%;
margin-bottom: -1.2em; /* your line-height */
}
.prevNext:after {
content: '';
display: inline-block;
width: 100%;
}
Explanation
The display: block on the :before element with the negative bottom margin pulls the lines of text up one line height which eliminates the extra line, but displaces the text. Then with the position: relative on the inline-block elements the displacement is counteracted, but without adding the additional line back.
Though css cannot directly access a line-height "unit" per se, the use of em in the margin-bottom and top settings easily accommodates any line-height given as one of the multiplier values. So 1.2, 120%, or 1.2em are all equal in calculation with respect to line-height, which makes the use of em a good choice here, as even if line-height: 1.2 is set, then 1.2em for margin-bottom and top will match. Good coding to normalize the look of a site means at some point line-height should be defined explicitly, so if any of the multiplier methods are used, then the equivalent em unit will give the same value as the line-height. And if line-height is set to a non-em length, such as px, that instead could be set.
Definitely having a variable or mixin using a css preprocessor such as LESS or SCSS could help keep these values matching the appropriate line-height, or javascript could be used to dynamically read such, but really, the line-height should be known in the context of where this is being used, and the appropriate settings here made.
UPDATE for minified text (no spaces) issue
Kubi's comment noted that a minification of the html that removes the spaces between the <a> elements causes the justification to fail. A pseudo-space within the <a> tag does not help (but that is expected, as the space is happening inside the inline-block element), a <wbr> added between the <a> tags does not help (probably because a break is not necessary to the next line), so if minification is desired, then the solution is a hard coded non-breaking space character --other space characters like thin space and en space did not work (surprisingly).
Nearing a Future Clean Solution
A solution in which webkit was behind the times (as of first writing this) was:
.prevNext {
text-align: justify;
-moz-text-align-last: justify;
-webkit-text-align-last: justify; /* not implemented yet, and will not be */
text-align-last: justify; /* IE */
}
It works in FF 12.0+ and IE8+ (buggy in IE7).
For Webkit, as of version 39 (at least, might have crept in earlier) it does support it without the -webkit- extension but only if the user has enabled the experimental features (which can be done at chrome://flags/#enable-experimental-web-platform-features). Rumor is that version 41 or 42 should see full support. Since it is not seamlessly supported by webkit yet, it is still only a partial solution. However, I thought I should post it as it can be useful for some.
Consider the following:
.prevNext {
display: table;
width: 100%
}
.prevNext a {
display: table-cell;
text-align: center
}
(Also see the edited fiddle.) Is that what you are looking for? The advantage of this technique is that you can add more items and they will all be centered automatically. Supported by all modern Web browsers.
First off, I like the approach of the pseudo-element in order to keep the markup semantic. I think you should stick with the overall approach. It's far better than resorting to tables, unnecessary markup, or over the top scripts to grab the positioning data.
For everyone stressed about text-align being hacky - c'mon! It's better that the html be semantic at the expense of the CSS than vice versa.
So, from my understanding, you're trying to achieve this justified inline-block effect without having to worry about resetting the line-height every time right? I contend that you simply add
.prevNext *{
line-height: 1.2; /* or normal */
}
Then you can go about coding as though nothing happened. Here's Paul Irish's quote about the * selector if you're worried about performance:
"...you are not allowed to care about the performance of * unless you concatenate all your javascript, have it at the bottom, minify your css and js, gzip all your assets, and losslessly compress all your images. If you aren't getting 90+ Page Speed scores, it's way too early to be thinking about selector optimization."
Hope this helps!
-J Cole Morrison
Attempting to text-align for this problem is pretty hackish. The text-align property is meant to align inline content of a block (specifically text) -- it is not meant to align html elements.
I understand that you are trying to avoid floats, but in my opinion floats are the best way to accomplish what you are trying to do.
In your example you have line-height:1.2, without a unit. This may cause issues. If you're not using borders you could give the parent and the children a line-height of 0.
The other options I can think of are:
Use display:table on the parent and display:table-cell on the children to simulate table like behaviour. And you align the first item left, and the last one right. See this fiddle.
Use javascript to do a count of the nav children and then give them a equally distributed width. eg. 4 children, 25% width each. And align the first and last items left and right respectively.
There is a way to evenly distribute the items but is a convoluted method that requires some non breaking spaces to be carefully placed in the html along with a negative margin and text-align:justify. You could try and adapt it the the nav element. See example here.
Your fiddle is awfully specific. It seems to me for your case this CSS would work well:
.prevNext {
border: 1px solid #ccc;
position: relative;
height: 1.5em;
}
.prevNext a {
display: block;
position: absolute;
top: 0;
}
.prevNext a:first-child {
left: 0;
text-align: left;
}
.prevNext a:last-child {
right: 0;
text-align: right;
}
As stated by #Scotts, the following has been implemented inside Chrome, without the -webkit part , which I really loved btw, specially since we need to get rid of the -browser-specific-shǐt real soon.
.prevNext {
text-align: justify;
-moz-text-align-last: justify;
-webkit-text-align-last: justify; /* not implemented yet, and will not be */
text-align-last: justify; /* IE + Chrome */
}
Note: Though still the Safari and Opera don't support it yet (08-SEPT-16).
I think the best way would be to create the clickable element with a specific class/id and then assign float:left or float:right accordingly. Hope that helps.
I have designed a navbar for my website; you can see it at http://jsfiddle.net/ToddStyles/D2tZH/.
What CSS I would use to change the spacing between them? I used an unordered list to make it and changed the display to inline.
When you are displaying elements inline, HTML will parse any whitespace as a spacebar character. So, you can either comment out the space between list items, i.e.:
<li>...</li><!--
--><li>...</li>
Or, display them as block level elements and float them:
ul {
overflow: hidden; /* To prevent collapse */
}
ul li {
display: block;
float: left;
}
With regards to the Fiddle you have posted, you have used the <img> tag incorrectly. It is self-closing, and it should not be used to nest anything.
p/s: And please, don't use link shortener just because SO prevents you from posting a Fiddle link due to a lack of code. The rule is there for a reason — providing us code gives your question context.
If you’re looking to increase the width, you can apply a left margin to consecutive <li>s easily:
#navbar li + li {
margin-left: 0.2em;
}
Here’s your fiddle back. I fixed it to use inline-block to make the layout break less when it inevitably wraps on a smaller screen. And do take into account that we can’t see images on your computer across the internet.
A few other questions have already addressed how best to apply text-align: justify to get inline-block elements to spread out evenly… for example, How do I *really* justify a horizontal menu in HTML+CSS?
However, the 100% width element that "clears" the line of inline-block elements is given its own line by the browser. I can't figure out how to get rid of that empty vertical space without using line-height: 0; on the parent element.
For an example of the problem, see this fiddle
For my solution that uses line-height: 0;, see this fiddle
The solution I'm using requires that a new line-height be applied to the child elements, but any previously set line-height is lost. Is anyone aware of a better solution? I want to avoid tables so that the elements can wrap when necessary, and also flexbox because the browser support isn't there yet. I also want to avoid floats because the number of elements being spaced out will be arbitrary.
Updated the "Future" solution info below; still not yet fully supported.
Present Workaround (IE8+, FF, Chrome Tested)
See this fiddle.
Relevant CSS
.prevNext {
text-align: justify;
}
.prevNext a {
display: inline-block;
position: relative;
top: 1.2em; /* your line-height */
}
.prevNext:before{
content: '';
display: block;
width: 100%;
margin-bottom: -1.2em; /* your line-height */
}
.prevNext:after {
content: '';
display: inline-block;
width: 100%;
}
Explanation
The display: block on the :before element with the negative bottom margin pulls the lines of text up one line height which eliminates the extra line, but displaces the text. Then with the position: relative on the inline-block elements the displacement is counteracted, but without adding the additional line back.
Though css cannot directly access a line-height "unit" per se, the use of em in the margin-bottom and top settings easily accommodates any line-height given as one of the multiplier values. So 1.2, 120%, or 1.2em are all equal in calculation with respect to line-height, which makes the use of em a good choice here, as even if line-height: 1.2 is set, then 1.2em for margin-bottom and top will match. Good coding to normalize the look of a site means at some point line-height should be defined explicitly, so if any of the multiplier methods are used, then the equivalent em unit will give the same value as the line-height. And if line-height is set to a non-em length, such as px, that instead could be set.
Definitely having a variable or mixin using a css preprocessor such as LESS or SCSS could help keep these values matching the appropriate line-height, or javascript could be used to dynamically read such, but really, the line-height should be known in the context of where this is being used, and the appropriate settings here made.
UPDATE for minified text (no spaces) issue
Kubi's comment noted that a minification of the html that removes the spaces between the <a> elements causes the justification to fail. A pseudo-space within the <a> tag does not help (but that is expected, as the space is happening inside the inline-block element), a <wbr> added between the <a> tags does not help (probably because a break is not necessary to the next line), so if minification is desired, then the solution is a hard coded non-breaking space character --other space characters like thin space and en space did not work (surprisingly).
Nearing a Future Clean Solution
A solution in which webkit was behind the times (as of first writing this) was:
.prevNext {
text-align: justify;
-moz-text-align-last: justify;
-webkit-text-align-last: justify; /* not implemented yet, and will not be */
text-align-last: justify; /* IE */
}
It works in FF 12.0+ and IE8+ (buggy in IE7).
For Webkit, as of version 39 (at least, might have crept in earlier) it does support it without the -webkit- extension but only if the user has enabled the experimental features (which can be done at chrome://flags/#enable-experimental-web-platform-features). Rumor is that version 41 or 42 should see full support. Since it is not seamlessly supported by webkit yet, it is still only a partial solution. However, I thought I should post it as it can be useful for some.
Consider the following:
.prevNext {
display: table;
width: 100%
}
.prevNext a {
display: table-cell;
text-align: center
}
(Also see the edited fiddle.) Is that what you are looking for? The advantage of this technique is that you can add more items and they will all be centered automatically. Supported by all modern Web browsers.
First off, I like the approach of the pseudo-element in order to keep the markup semantic. I think you should stick with the overall approach. It's far better than resorting to tables, unnecessary markup, or over the top scripts to grab the positioning data.
For everyone stressed about text-align being hacky - c'mon! It's better that the html be semantic at the expense of the CSS than vice versa.
So, from my understanding, you're trying to achieve this justified inline-block effect without having to worry about resetting the line-height every time right? I contend that you simply add
.prevNext *{
line-height: 1.2; /* or normal */
}
Then you can go about coding as though nothing happened. Here's Paul Irish's quote about the * selector if you're worried about performance:
"...you are not allowed to care about the performance of * unless you concatenate all your javascript, have it at the bottom, minify your css and js, gzip all your assets, and losslessly compress all your images. If you aren't getting 90+ Page Speed scores, it's way too early to be thinking about selector optimization."
Hope this helps!
-J Cole Morrison
Attempting to text-align for this problem is pretty hackish. The text-align property is meant to align inline content of a block (specifically text) -- it is not meant to align html elements.
I understand that you are trying to avoid floats, but in my opinion floats are the best way to accomplish what you are trying to do.
In your example you have line-height:1.2, without a unit. This may cause issues. If you're not using borders you could give the parent and the children a line-height of 0.
The other options I can think of are:
Use display:table on the parent and display:table-cell on the children to simulate table like behaviour. And you align the first item left, and the last one right. See this fiddle.
Use javascript to do a count of the nav children and then give them a equally distributed width. eg. 4 children, 25% width each. And align the first and last items left and right respectively.
There is a way to evenly distribute the items but is a convoluted method that requires some non breaking spaces to be carefully placed in the html along with a negative margin and text-align:justify. You could try and adapt it the the nav element. See example here.
Your fiddle is awfully specific. It seems to me for your case this CSS would work well:
.prevNext {
border: 1px solid #ccc;
position: relative;
height: 1.5em;
}
.prevNext a {
display: block;
position: absolute;
top: 0;
}
.prevNext a:first-child {
left: 0;
text-align: left;
}
.prevNext a:last-child {
right: 0;
text-align: right;
}
As stated by #Scotts, the following has been implemented inside Chrome, without the -webkit part , which I really loved btw, specially since we need to get rid of the -browser-specific-shǐt real soon.
.prevNext {
text-align: justify;
-moz-text-align-last: justify;
-webkit-text-align-last: justify; /* not implemented yet, and will not be */
text-align-last: justify; /* IE + Chrome */
}
Note: Though still the Safari and Opera don't support it yet (08-SEPT-16).
I think the best way would be to create the clickable element with a specific class/id and then assign float:left or float:right accordingly. Hope that helps.
This question already has answers here:
Image inside div has extra space below the image
(10 answers)
Closed 7 years ago.
In Firefox only my video thumbnails are displaying mysterious 2-3 pixels of white space between the bottom of my image and its border (see below).
I've tried everything I can think of in Firebug with no luck.
How can I remove this white space?
You're seeing the space for descenders (the bits that hang off the bottom of 'y' and 'p') because img is an inline element by default. This removes the gap:
.youtube-thumb img { display: block; }
You can use code below if you don't want to modify block mode:
img{vertical-align:text-bottom}
Or you can use following as Stuart suggests:
img{vertical-align:bottom}
If you would like to preserve the image as inline you can put vertical-align: top or vertical-align: bottom on it. By default it is aligned on the baseline hence the few pixels beneath it.
I've set up a JSFiddle to test several different solutions to this problem. Based on the [vague] criteria of
1) Maximum flexibility
2) No weird behavior
The accepted answer here of
img { display: block; }
which is recommended by a lot of people (such as in this excellent article), actually ranks fourth.
1st, 2nd, and 3rd place are all a toss-up between these three solutions:
1) The solution given by #Dave Kok and #Hasan Gursoy:
img { vertical-align: top; } /* or bottom */
pros:
All display values work on both the parent and img.
No very strange behavior; any siblings of the img fall where you'd expect them to.
Very efficient.
cons:
In the [perfectly valid] case of both the parent and img having `display: inline`, the value of this property can determine the position of the img's parent (a bit strange).
2) Setting font-size: 0; on the parent element:
.parent {
font-size: 0;
vertical-align: top;
}
.parent > * {
font-size: 16px;
vertical-align: top;
}
Since this one [kind of] requires vertical-align: top on the img, this is basically an extension of the 1st solution.
pros:
All display values work on both the parent and img.
No very strange behavior; any siblings of the img fall where you'd expect them to.
Fixes the inline whitespace problem for any siblings of the img.
Although this still moves the position of the parent in the case of the parent and img both having `display: inline`, at least you can't see the parent anymore.
cons:
Less efficient code.
This assumes "correct" markup; if the img has text node siblings, they won't show up.
3) Setting line-height: 0 on the parent element:
.parent {
line-height: 0;
vertical-align: top;
}
.parent > * {
line-height: 1.15;
vertical-align: top;
}
Similar to the 2nd solution in that, to make it fully flexible, it basically becomes an extension of the 1st.
pros:
Behaves like the first two solutions on all display combinations except when the parent and img have `display: inline`.
cons:
Less efficient code.
In the case of both the parent and img having `display: inline`, we get all sorts of crazy. (Maybe playing with the `line-height` property isn't the best idea...)
So there you have it. I hope this helps some poor soul.
I found this question and none of the solutions here worked for me. I found another solution that got rid of the gaps below images in Chrome. I had to add line-height:0; to the img selector in my CSS and the gaps below images went away.
Crazy that this problem persists in browsers in 2013.
Had this prob, found perfect solution elsewhere if you dont want you use block just add
img { vertical-align: top }
.youtube-thumb img {display:block;} or .youtube-thumb img {float:left;}
Give the height of the div .youtube-thumb the height of the image. That should set the problem in Firefox browser.
.youtube-thumb{ height: 106px }
As stated before, the image is treated as text, so the bottom is to accommodate for those pesky: "p,q,y,g,j"; the easiest solution is to assign the img display:block; in your css.
But this does inhibit the standard image behavior of flowing with the text. To keep that behavior and eliminate the space. I recommend wrapping the image with something like this.
<style>
.imageHolder
{
display: inline-block;
}
img.noSpace
{
display: block;
}
</style>
<div class="imageHolder"><img src="myimg.png" class="noSpace"/></div>
Just a quick question regarding CSS positioning. I have several "segments" on my site which are 100% wide (fills the screen), and I want them floated next to each other. So only the first one will be visible, the other ones will be off-screen. I've tried playing around with positions and the overflow property without luck. Right now they just pop down below each other instead of floating.
This would work perfectly if the elements did not exceed the screen width, but as they do, they just pop down as I said earlier. I've tried setting a huge width to the "wrapper", something like 99999px. And then setting the segments to 100%, but that will just fill the whole 99999px width instead of the screen.
Any ideas?
JSFiddle example: http://jsfiddle.net/9xGPb/
Do you mean like this?
Example Fiddle: here
I used my favourite alternative to floats, inline-blocks
if you actually take it out of the fiddle it has some pretty (gaudy?) colours which show that it allows for the min-width: 900px; on the centered_content div to work too, and I removed the absolute positioning for the menu so the content would go below it, for demo only but you may find it useful..
let me know if any good or if you have any questions
Updated with some jQuery and to make corrections for default word-spacing
New Example: here
re: the IE6/7 hack rightly mentioned in the comments;
.segment {
display: inline-block;
overflow: hidden;
width: 0;
}
.segment {display: inline !ie7;}
needn't be a "parse hack" if that's your preference as long as that second rule is given to [lte IE 7] somehow, and separately at that it cannot be combined into the original rule with the * hack or anything, it won't work.. has to be in a separate ruleset.
I discovered word-spacing might be a problem if relying on width to hide, the natural behaviour of inline blocks is to put 3-4px between the elements like the space in between words, the workaround to this is to correct the word-spacing on the wrapper
.segment-wrapper {
white-space: nowrap;
word-spacing: -4px;
}
then restore it normal for the actual content divs, same place as you would restore the normal wrapping behaviour
.centered_content {
width: 900px;
margin: 0px auto;
background: #fcf;
white-space: normal;
word-spacing: 0;
}
and last, apart from this was fun.. there's 2 effects in that new fiddle - uncomment and comment the other.. forgive me I was playing! :)
The meaning of float is to try to float to the right or left unless there is not room for it.
This means that you cannot ever float an element off the page.
If you need to keep the element off the page, you will need to use a different positioning mechanism like position: absolute.
It sounds like you're creating a horizontal one-page portfolio. I've recently been working on something similar.
Using your fiddle I've set the .segment class to
.segment {width:90%;height:90%;position:absolute;}
and then offset each left positioning further off the screen
#home {background-color:red;left:5%;}
#work {background-color:yellow;left:105%;}
#portfolio {background-color:green;left:205%;}
#contact {background-color:blue;left:305%;}
http://jsfiddle.net/9xGPb/2/
I also added some jQuery logic to switch views for the divs.
I'm still not entirely sure which segments you want to start off the page but this jsfiddle uses positioning to shove the #two div off to the right: http://jsfiddle.net/EdAZP/1/
Which part of your example did you want to start off the page?
Did you try to just hide the other elements and toggle them with some javascript (jQuery is much easier)?
http://api.jquery.com/toggle/