I'm just wondering if there is a nice clean way in which to negate the letter-spacing property slight problem when you need to center text. Note to best see the problem, make the jsfiddle preview window small enough so the text wraps on to two lines.
HTML
<div class="centered--element">
<div class="center--line"></div>
<h1>This is a example here</h1>
</div>
CSS
.centered--element{
background: #f2f2f2;
text-align: center;
text-transform: uppercase;
}
/* problem property.. */
h1{ letter-spacing: 20px }
I've made this to demonstrate the problem: http://jsfiddle.net/tq3Gh/1/
Perhaps it's just me, but it's not looking 100% central. Please see:
However, removing the letter-spacing and it sits as one would expect. So to me there is an issue..
Here is the same example, but without letter spacing set:
Update
I've a better idea of the problem therefore I'm updating the question to make more sense and sum the problem up a whole lot better.
Ok so after much playing the problem is letter-spacing adds spacing to the right of each letter, INCLUDING the last letter, hence why I'm getting this issue. So, in order to negate this I'm going to try simply using margin-right: -(width of my letter spacing). I'm not sure if this will cause problems, but it beats another option where I could wrap spans around the elements I want to have letter-spacing — but that's far too ugly for me.
So my update CSS would look like:
h1{ letter-spacing: 20px; margin-right: -20px; }
ok, so actually its not a problem. Your center--element is 100% wide so actually the texts goes behind the the 2 columns in the side.
to show that I tired reducing opacity of side elements here
and when you actually give margin to the center--element it solves your problem here
.centered--element{
background: rgba(0, 0, 0, 0.1);
text-align: center;
text-transform: uppercase;
margin-left:90px;
margin-right:90px;
}
Final Solution
It seems you need to indent the text by the same amount as the letter-spacing. The first letter does not have the spacing applied to the left side
.spacing2 {
letter-spacing:0.9em;
text-align: center;
text-indent: 0.9em;
}
Final DEMO
The issue does indeed stem from using letter-spacing. According to the standard, when you increase the letter spacing the layout engine considers that extra space after the letter to be part of the letter's width. So that extra space you see on the right is, in a way, what you asked for.
What it seems you want is for the letter spacing to put the actual letter in the middle, and surround each letter on both sides with letter-spacing/2. But I'm not sure that's a feature of CSS. In fact, the letter spacing algorithms are user agent-dependent, so this may even work in different ways on different browsers.
So you're left with ways to hack around this problem, like adding a -1em right margin/padding, but probably without a "true" solution.
I have edited your css and added margin to left and right:
CSS:
.centered--element{
background: #f2f2f2;
text-align: center;
text-transform: uppercase;
margin-left:90px;
margin-right:90px;
}
Also I have mentioned in the DEMO , how to dynamically set letter spacing :
JS:
document.getElementById("myHeading").style.letterSpacing="15px";
Hope this helps.
I've made a javascript function to correct this behaviour. It takes the last letter of the matched elements text and creates a span with no letter spacing, and then compensates the width adding an extra margin (equal to the original letter spacing).
You may need to limit it's input to leaf nodes, but it works really well, specially if you need to underline the text.
var fixLetterSpacing = function(selector) {
$(selector).each(function() {
var that = $(this);
var text = that.text();
var last = text.substr(-1);
that.text(text.substr(0, text.length-1))
.append($('<span>').text(last).css({ letterSpacing: 0 }))
.css({ marginRight: that.css('letter-spacing') });
});
};
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've been helping a friend change the layout of his site (mostly css changes) at the moment I'm just fine tuning it a bit and have run into a problem. To begin with, here is a sample of the site. The problem is the titles for the posts, i want there to be less padding on the top and the bottom so that the background isn't taller than the text when you hover on them. I've tried changing margins, and padding, pretty much tried everything. Increasing the padding works fine but i can't seem to get it less than it is at the moment. I know it should work because it's modelled after the titles in another site. Can anybody see where the problem lies? Thanks
If I'm understanding correctly, you want to change the amount of empty space around the main post title. If so, adjust line-height:
#content .post .title h3 a {
text-align: left;
-webkit-transition: color 0.25s linear;
font-size: 36px;
letter-spacing: -1px;
font-weight: 750;
line-height: 50px; /* Change this */
color: #444444;
text-decoration: none;
padding:0px 0px;
}
Example with line-height (overly) reduced: http://jsfiddle.net/AH9VP/3/
See also: http://www.w3.org/wiki/CSS/Properties/line-height
However...Note that in spite of changing line-height (which definitely reduces spacing), there seems be a limit on how much the browser will constrain the box when you hover on the text. This is (I think) because the browser is allowing space for glyphs at the top/bottom (like the tail of the "y" in "usually").
This topic is somewhat related: https://stackoverflow.com/a/11857786/453277
I know it should work because it's modelled after the titles in
another site.
It would be helpful to see the other site, in case I've missed something.
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.
The problem is that Firefox and WebKit based browsers seem to align text vertically in different ways when contained in an element that has an even height/line-height and the font-size is uneven (or vice versa). I have looked at some similar threads, but I haven't really seen any great explanations for my question.
Consider the following example:
.box {
font-size: 15px;
font-family: Helvetica, Arial;
background-color: Blue;
height: 20px;
width: 60px;
color: White;
line-height: 20px;
}
<div class="box">
A text.
</div>
Is there any way to fix this? Is there any "text-align" property or something that I missed?
This is due to differences in how browsers handle subpixel text positioning. If your line-height is 20 pixels but font-size is 15 pixels, then the text needs to be positioned 2.5 pixels from the top of the line box. Gecko actually does that (and then antialiases or snaps to the pixel grid as needed on painting). WebKit just rounds positions to integer pixels during layout. In some cases, the two approaches give answers that differ by a pixel. Unless you're comparing them side-by-side, how can you even tell there's a difference?
In any case, making sure that your half-leading is an integer (i.e. that line-height minus font-size is even) will make the rendering more consistent if you really need that.
This is browser rendering issue. Use line-height 1px less than the given height, for example:
.box
{
background-color: Blue;
color: White;
font-family: Helvetica,Arial;
font-size: 15px;
height: 18px;
line-height: 17px;
width: 60px;
}
If you are looking for a way to do an exact vertical align, check out Stack Overflow question Problem with vertical-align: middle; - I described a solution there.
If you want an answer why Firebug and Chrome display this differently, this will be a bit more complicated. Line-height alignment is based on font-line rendering and fonts can be handled in a very different way across the browsers. For example, font-smoothing and font-weight can really mess with your page.
Also, are you using CSS reset for this page? It contains font related adjustments as well, and it may help you to overcome cross-browser issues. Refer to CSS Tools: Reset CSS.
Ugh, terrible but true! I just ran into this trying to create tiny count bubbles on an icon - so small that I had to get right next to text so every pixel counted. Making the line-height 1x less than text-size leveled the display field between FF and Chrome.
I'm having a strange issue with some #font-face text where there is some strange padding (or at least vertical space) included with the text. It is causing problems because I want to text to be positioned a certain way but can't have it overlapping other things. Here is a picture of what is occurring:
As you can see when the text is selected, the text overlaps some of the navigation bar above it. I have tried adjusting the line height and padding, margins, anything I can think of. Here is the relevant CSS, does anybody have a suggestion as to how I can get the height of the line to be around the height of the actual text.
*{ margin: 0; padding: 0; }
h1#logo { font: 350px/.95 'Bebas Neue'; color: #DDD; text-align: center; margin: 1px 0; }
EDIT: Here is a live example of the problem: http://codezroz.com/stuff/hello.html
never seen the /.95 syntax before, but after a few tests now i belive it works like:
line-height = 0.95 * font-size = 332.5
so i think that's your problem, the font is taller than the line
adding overflow: hidden; on the H1 should be enough
Well, applying overflow: hidden to h1#logo stopped the selection highlight from bleeding into areas that were outside the element.
Also remember that you can use the :selection pseudo-element to change the color of the selected text.