Must be something basic I'm missing here. I thought that font-weight:bold should not change how much vertical space the text takes. Especially when the line-height is set to be higher than the font-size.
http://jsfiddle.net/Arkkimaagi/7xAyy/
On my OSX chrome those three text heights do not match. The second one with font-weight:bold is 1px higher than the rest. The third div is just an example of fixing the problem (poorly)
I'm trying to set the line-height to something specific (18px) here, to have "vertical rhythm"
My question is, how can I have bold and normal text both with same line-height as in the example?
[edit:]
here's what I see on my mac
Also, here is what I ment by "vertical rhythm": http://www.alistapart.com/articles/settingtypeontheweb
- the baseline grid is more visible in the example: http://www.alistapart.com/d/settingtypeontheweb/example_grid.html
Sometimes adding top vertical align will solve this (depending on font size/family).
strong { vertical-align: top; }
In your fiddle example, because you have set a line height on the container (div), you can simply add the following:
span { line-height: 1em; }
It completely depends on the fonts you are using. Nothing about OSX or Chrome text rendering would ensure that two different fonts (and Helvetica-neue and Helvetica-neue-bold are two different fonts) would have the same vertical space even at the same font-size and line height.
Even though that is too much to ask you might think that two different fonts from the same family might be consistent, and usually they are, but sadly the two fonts you have chosen are not.
Setting an absolute line-height on both the container and the bold text, or giving bold text a line height of 1em (as DaveC says above) both fix this, e.g. from the jsfiddle you just need to add line-height: 1em
.bolded span {
font-weight:bold;
line-height: 1em;
}
Or why not follow HTML standards and use the correct tags instead of bolded spans? E.g.
strong, em { line-height: 1em }
I've encountered very similar problem with Chivo font: http://www.fontsquirrel.com/fonts/chivo. Right now I'm using the ugliest hack (works on current Firefox and Chrome, IE untested yet):
strong { vertical-align: top; position: relative; top: -1px; }
I try not give up on Chivo quite hard as you see ...
I think this is a font issue. I found differing line heights for the italic variant of Nunito (Google Web Font). When I switched to a reworked version of that font called "Nunito Sans" the issue was resolved.
Related
I am using a downloaded font file for use on my website, however it is causing some issues in regards to layout / display.
Most fonts I have used display like this
The font I am currently using displays like this:
The difference is that the 1st font has space above (which is part of the actual text and not my css styling) while the second one has no space at all.
I can solve this issue by simply adding some extra padding to the containing element's top but this is not practical in the future event that I decide to replace the font (meaning I would have to go into every parent and remove the padding-top)
Is there any CSS styling methods I can use to add padding to my font so that it will always have a bit of space up top?
My Code:
CSS:
#font-face {
font-family: "Anakin Mono";
src: url("../fonts/opipik_anakinmono/anakinmono.ttf");
}
#demo {
font-family: "Anakin Mono";
padding: 14px 10px 10px 10px; /* Have to add extra padding to top becuase of font in use */
border: 1px solid black; /* A border helps illuminate whats happening with text alignment - vertically;
}
HTML:
<p id="demo">Some text on my website</p>
Is there any CSS styling methods I can use to add padding to my font so that it will always have a bit of space up top?
Unfortunately the answer to this question as you've outlined it is no, there are no CSS methods to target only a single font.
That said, you can simply assign your mono-spaced font by using a class and easily change the style globally as shown here:
#import url('https://fonts.googleapis.com/css?family=Inconsolata');
.monospace {
font-family: 'Inconsolata', monospace;
padding-top: 4px;
}
<div class="monospace">This element is monospaced font</div>
Any elements which you'd like to use your mono spaced font should be assigned the class monospace. In the future, you can simply change the font-family rule and alter the padding and voila, you've accomplished your change with very little effort.
I realize you've made it clear in the comments that you'd rather take a different approach, but I feel this is the absolute best solution/workaround that will get you what you want with the least amount of effort. At most, it will require you alter your markup to add the monospace class where needed, but this is probably a step in the right direction anyway.
You can make use of line-height. Change your CSS to this:
#demo {
font-family: "Anakin Mono", sans-serif;
line-height: 3;
padding: 0 10px;
border: 1px solid black;
}
You can try different values of line-height. It accepts multiple of original line height. px or em.
Always remember not to use only ONE font in font-family. Use more than 1 font to provide fallback fonts, in case your font is not loaded yet / unable to load.
Also, it's not advised to use self-hosted TTF font unless the file size is small. Try using CDN-hosted web fonts (such as Google Fonts) for better performance.
JSFiddle demo: https://jsfiddle.net/okawrcuf/6/ (I used another font that is available in Google Fonts for demo purpose, as I don't have your font)
I'm working on a project where the height of the content container is limited, and on a few select browsers (mostly Chrome on Android) the text seems to be breaking in different places, even though almost all font properties seem identical, so far I've checked:
Width of the container element
font-size
line-height
font-family
letter-spacing
All of which are identical, both in their given and computed values.
This wouldn't usually be a massive problem, but because of the content container height constraint, these discrepancies are causing me a massive headache.
I've managed to replicate the problem in a fiddle with the following code:
HTML
<p>We are not able to sleep or We cannot sleep.</p>
CSS
p {
font-family: "Times New Roman", serif;
font-size: 11px;
font-style: italic;
letter-spacing: 0;
max-width: 200px;
}
The text in this example renders on one line in the majority of browsers, however in some the last word "sleep." appears on a new line.
You can see screenshots of this example in a number of different browsers at:
http://www.browserstack.com/screenshots/cf75bb4fa9a22db2e660a0073698be86b55becb6
Is there something I'm missing here? Is there any way to ensure the text will render in the same way accross a number of devices and browers?
The details of font rendering vary by browser and platform, and they cannot be controlled in CSS. Besides, different computers may have (slightly) different fonts under the same name, or e.g. lack Times New Roman entirely (most smartphones lack it, for example).
As a workaround, if specific line division is crucial, consider writing the text as preformatted (i.e. dividing it into lines in HTML source the way it should appear in display) and using white-space: pre. The drawback is that some lines might hit or even cross the right edge of the area reserved for the element. But if you do not set a background or border, this will be barely noticeable.
I'm afraid that the only solution here is using an image using width="XXX" or tell the client that is completely impossible to make a web identically on every browsers unless you use disgraceful methods just like using an image instead of text.
I was able to solve the problem in my browser by replacing the max-width with min-width see this http://jsfiddle.net/79j57L8L/4/
p {
font-family:"Times New Roman", serif;
font-size: 11px;
font-style: italic;
min-width: 200px;
}
I can't change my span element line-height, that is defined in body (I've tried using !important, as well as different line-height notation including font/line-height). Here's the code:
body {
font: 16px/1.5 Arial, Helvetica, sans-serif;
}
.pageBody.oferta > .cnt .columns ul span {
font-size: 9px;
line-height: 1;
}
The problem is obviously that my spans line-height is 1.5
More to that web dev tool doesn't show that inheritance from body covers it (it's crossed in web dev tool then). There's lot of code on the site as well, but i don't think that it could affect line-height anyhow (so pasting it would be lot of spam).
Edit: Interesting thing i have found out: when i apply line-height bigger than 2, it starts to apply on the span.
Set line-height on a block container, not on span. For span, or for non-replaced inline elements in general, the height of the content area depends on the font and on the browser and generally makes provisions for descenders and ascenders; see 10.6.1 Inline, non-replaced elements in the CSS 2.1 spec.
Even for a div element or other block element, your chances of tweaking the height down to 9px might be prevented by user settings, such as minimum font size set to something larger (an user option on Firefox; cannot be overridden by authors).
I don’t know how you inferred the line height, but my Firebug says, for a document constructed from your example, the computed line height as 9px but, in the Layout pane, the height as 13px. This is normal, by the CSS 2.1 principles.
span {
line-height: 0.66; /* 66% of 1.5 ~= 1
}
since line-height values are multiplied on nested elements you could obtain this with 0.66. Another way to override the value is setting line-height: normal (but the real value will change depending on the browser)
You are missing unit part of the definiation
Example here
I have a TEXTAREA where spacing is very important. I formatted it as follows:
TEXTAREA {
font-family: Tahoma, Arial;
font-size: 8pt;
letter-spacing: 0px;
line-height: 13px;
}
How, if I enter some text, the line height is not correctly applied: The last line of every paragraph (before pessing enter or shift-enter) is one pixel to high:
This problem only occurs in Internet Explorer 9, not in Firefox 7 or Chrome 14 (haven't tested older versions so far).
Is there a way to get rid of thad?
BTW: It does not happen for the last line of the textarea, unless there is a linebreak behind it.
Regards,
Steffen
I know this may not actually help entirely nor be the full answer, but it may be worth while reading up a little on the use of !important declaration within CSS.
http://www.impressivewebs.com/everything-you-need-to-know-about-the-important-css-declaration/
The only reason why this springs to mind is there may be another style/declaration that is applied after which is causing some sort of problem and this will make sure your textarea has the correct styles applied to it.
You may also want to check that any <p> CSS declarations are not causing conflicts/problems with any bottom or top margin's/paddings? Same goes with span or any other styles that could potentially cause some sort of problems.
Like I said, I'm aware this may not help in the slightest but it could be a possibility.
I have had similar problems with the last line in a textarea in IE8. When my textarea had a line-height of less than 18px, the cursor changed the line-height. The reason I bring this up is your line-height of 13px is quite small. You may want to experiment with larger line-heights to see if the problem goes away.
I just went many many rounds with this issue and finally discovered that IE9 is adding extra padding to textareas. Line height, height, etc had no effect. This did the trick:
padding: 0px !important;
A few days ago I re-skinned my website. Development of this skin was primarily done using safari, and as expected, it all renders fine using firefox and opera. I've had to make a few small tweaks for IE7, but nothing much, except for one problem...
The date indicators for a post are cut off in IE. This problem seems to occur only on nested span tags inside a left floating div. I think I need the floating div's in order to layout text on the left and the right side of the screen.
Do any of you know how to stop IE7 from clipping my text?
Edit: I have sort of given up on this problem. My scripts now check for IE7 and feed it somewhat simplified HTML that its limited engine can handle. It works in IE8, so, for now, just the special case for IE7 will have to do...
In most cases where IE6 or 7 clips off the bottom of text, just add:
line-height: normal;
to the CSS rules concerned. Should fix it nicely, but as you'll understand, it expands the box too.
There's a hack I figured out that fixes the problem of cutting off text in IE. I noticed the last line in my headline was the only one being cut off.
My original CSS which was cutting off the last line in IE7 but looked fine in other browsers:
h2 {
font-size: 22px;
line-height: 1em;
}
See image of problem here: https://skitch.com/pablohart/f4g3i/windows-7-x64
The fix I did included simply adding padding to the bottom and then taking that padding back with negative margin. Like this:
h2 {
font-size: 22px;
line-height: 1em;
padding-bottom: 5px;
margin-bottom: -5px;
}
See picture of fix in this image: https://skitch.com/pablohart/f4g4h/windows-7-x64
The problem with line-height: normal; is that it takes on the default line-height for the font, usually 1.3em.
Try adding overflow: visible; to your .postdate class. Maybe that helps.
I had a similar problem. I changed my span to a div and the problem was resolved. I think IE7 might have an issue processing line-height on a span. Haven't confirmed that to be the issue. There were other CSS elements. (Working on someone else's code.) But changing from span to div (block) resolved the issue.
for the .bigdate class, try replacing margin with padding; seems to me that this has something to do with IE's margin-handling.
Adding a specific height to .title fixes it for me (in IE6):
.title {
PADDING: 0 10px 0 0; MARGIN-top: 0.3em; FLOAT: right; height: 1em;
Despite being unable to test it on my current machine: I would suspect that it's a hasLayout bug. The methods of dealing with it are listed in the "properties" section of that link.
In my experience its invariably the bottom of the text that gets clipped and that too basically because of the overlapping divisions. If you are able to ensure that the divs don't overlap then the issue does get resolved . That apart adding overflow: visible does help at times.
Try adding
div.postmeta { height: 100px; }
div.postdate { height: 75px; }
Arbitrary height value... but you'd know the exact height you want. That should keep the text containers from clipping in IE7.
I think the problem is with the padding. I tried removing a "padding: 3px" style and it worked properly. Previously it was not showing anything. Paul Hart's answer showed me that.
Probably also removing/overriding margin properties may also help.