I have a title which is displayed in uppercase letters. I would like to have just 2 pixels between this title and the framed box below.
If the text contains lowercase letters like ’g’, there is no space below, but once all ’g’, ’y’ and ’j’ letters are gone, it appears.
Is there any cross-browser method of getting rid of that space? Apparently browsers display different amount of empty space: https://jsfiddle.net/5o94va6p/13/, so tricks like line-height: 0.7 work in Firefox but eat too much space in Safari.
Safari and chrome look similar in terms of empty space. The browser that looks different is Firefox. I would only specify line height for it using CSS. This way, Firefox will look good, and it will not effect the look in other browsers.
Try this code which will target only Firefox:
#-moz-document url-prefix() {
h1 {
line-height: 0.7
}
}
The space below the baseline which is needed for letter like y, g, p etc. is ALWAYS there, it's part of the line-height - this is the reason for your problem. You can't change that unless you define a negative margin-bottom value, like
.my_heading {
margin-bottom: -4px;
}
try using this -
.box{
margin-top: 2px;
position: fixed;
}
Related
I have a page with an emoji followed by a space and some text. For example, "👥 Friends" (character is "busts in silhouette", U+1F465). In Safari and Firefox on macOS, it renders with a space between the emoji and the following text as expected.
In Chrome, however, the space appears as if it's absent:
If I remove the space, Chrome renders the text overlapping with the emoji. It seems like the width of emojis as rendered in Chrome is less than the actual character width.
Is there any way I can get the desired appearance (a normal-width space) cross browser without resorting to an image or icon font? I've tried messing with some CSS properties like text-rendering without success.
<style>
.friends {
font-family: Helvetica, Arial, sans-serif;
}
</style>
<span class="friends">👥 Friends</span>
JSFiddle
I had the same issue, and found out that it happened on non-retina screens only.
To fix it, we applied a margin through a media-query like this:
<span class="friends"><span class="emoji">👥</span> Friends</span>
<style>
#media
not screen and (min-device-pixel-ratio: 2),
not screen and (min-resolution: 192dpi) {
span.emoji {
margin-right: 5px;
}
}
</style>
This is a pretty minimal media-query. You should probably use a more complete one like https://stackoverflow.com/a/31578187/1907212.
This is a Chrome bug (See detail here)
This is related to displaying emojis in Mac Chrome on a non-retina screen. My monitor had a non-retina screen (where the spacing / cursor position were info), but were absolutely fine on my Mac.
It's February, 2020, and this issue still very much exists (link to open Chrome bug). Chrome 88.0.4324.150 on MacOS X 10.15.7 on a 2019 16" MacBook Pro: dragging a browser window between the internal Retina monitor and an external ultrawide monitor changes the rendering of the emoji.
As an alternative to Julien's answer, instead of selectively specifying a margin-right to correct an imbalance, we can "force" the width of the actual emoji character(s) to be equal in a cross-browser way using letter-spacing.
In essence, our issue is that most characters with the Roman alphabet don't have a height-to-width ratio of 1:1, but most emojis (roughly) do have a height-to-width ratio of 1:1. This is one way of describing what we're seeing with the spacing between emojis and ANSI characters.
See example screenshot here
letter-spacing sets the horizontal spacing behavior between text characters. When paired with CSS em units, we can use this property to "force" each character/emoji to render in a roughly 1:1 box. This might need to be adjusted depending on the font or character set you use.
According to the sources below, a Roman character is often roughly 0.5 as wide as it is tall, so we can simply do:
span.emoji {
letter-spacing: 0.5em;
}
<span class="friends"><span class="emoji">👥</span> Friends</span>
<style>
span.emoji {
letter-spacing: 0.5em;
}
</style>
This method means that in browsers that render emojis correctly, we aren't adding an extra margin-right.
https://graphicdesign.stackexchange.com/a/114955
https://web.archive.org/web/20210118205344/https://www.lifewire.com/aspect-ratio-table-common-fonts-3467385
What I would do is add another span within the .friends span that contains the emoji, have it use a right margin, and not have a space after it:
.friends {
font-family: Helvetica, Arial, sans-serif;
}
.friends span {
margin-right: 10px;
}
<span class="friends"><span>👥</span>Friends</span>
That way you don't have to worry about space rendering ;)
Hope this helps! :)
Removing BlinkMacSystemFont from font-family fixed issue for me, you need to close and reopen tab to see effect.
As of (at latest) Chrome 79, this issue no longer exists.
This problem still exists on Chrome 83 on MacOS 🤨
I think I found the solution
[data-emoji] {
font-style: normal;
font-weight: normal;
}
[data-emoji]:before {
content: attr(data-emoji);
margin-right: .125em;
}
This is a question I belive has been asked before but I haven't found any solution.
Open my jsfiddle in both Firefox and Chrome (Or Safari instead of Chrome). If you look carefully at the letter 'y', you can see that there are one or two extra pixels between the letter and the lower border of the section1-div, in Firefox compared to one of the other two.
I have set padding and margin top/bottom to 0px on the most elements in order to reset the styling to som extent.
Why is that and what measures should I take in order to prevent this?
UPDATE: Using Chrome 17.0.963.56, FF 11 and Mac.
I'm not really sure why this problem happend. It was not working. In my own code I could relate it to the padding. Chrome/Safari and Firefox is handling the padding differently. By adding som padding to the standard css and making an exception for Firefox I did get the expected result. This doesn't help the jsfiddle example (it could actually be that there isn't any problem in the example, could be that the font is displayed a bit different and it looks like there are differen number of pixels between the letter and the border...).
#adminmenu a{
padding-bottom: 2px;
}
#-moz-document url-prefix() {
#adminmenu a{ padding-bottom: 0px; }
}
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.
I recently noticed in several webpages, and some of my own, that when they are displayed in Internet Explorer 9, when its not on Quirks Mode, it renders a white line, about 1px, in the bottom of the page. It's like the html tag was with padding-bottom:1px and wrapped in another element with white background (but it's not, and it has no padding). It looks like the differences between IE9 standards and quirks mode shows when determining a wrapping element's width, but vertically. It also feels like the content of an element gets pushed 1px by a previous element, like their content, but, not margins or borders, were overlapping the next element dimensions.
I can't determine exactly what causes it. Sometimes, a page contains 2 tables and everything is fine. Then you need to add a third one, and the line shows up. Doesn't even need to be tables btw.
Sometimes, reseting css solves it. Setting the same line-height we have on body to links:
body {
line-height: 1
}
a, links, visited {
line-height: 1
}
fixes it, but not always. Only thing i can do, is check element by element, disabling/enabling their css rules till it's gone.
I noticed that when there are elements like tables, inputs, textareas, this issue is more likely to happen. 'resetting' their attributes, sometimes, solves it too.
I know it would be easier to provide a code as an example, but like i said, i coudn't determine a pattern for it. I can give you some examples of sites/urls i notice that error (you gotta look at the very bottom of the page and see the difference between IE and another browser, like Firefox):
casinosdelmundo.info, gatosabido.com.br, espanol.yahoo.com, en.wikipedia.org/wiki/Bruce_Beutler, ea.com/command-and-conquer-4, facebook.com (the ones with white, or almost white bg, change body background with f12, developer's tool, and you'll see). I found an example even here at stackoverflow (as today, the main page stackoverflow.com is showing that line too, but that can change since, sometimes the issue appears or disappears when new elements show up or are removed):
this question has the white-line:
Make link in table cell fill the entire row height
this one has not:
FireFox 3 line-height
Check this screenshot, if you still didn't see what im talking about:
the presence of this issue on very established (or not) sites makes me feel it's a IE9 bug and the only definitive fix for it is always use white background, so nobody will notice the white line (the line will still be there though). but thats obviously not the best option. I never found this white line in Chrome or Safari.
So, has anyone faced the same problem and got a better solution?
I'm not sure, cause there is no HTML here, but it is very resemble to standard browser behavior, when it displays inline content. It is due to the fact, that when text is displayed browser needs to leave some space at the bottom for letters and symbols such as: "," , "y" , "p" and so on, cause in that letters there is a part which protrudes to the bottom. You can better understand what I'm talking about when you look at this picture:
example of how inline content is displayed
so if you have some markup like
<body>
<div></div>
<textarea></textarea>
</body>
you'll get that extra space at the bottom. To get rid off it you have to use there either block element, or set to your inline-element a css style 'display: block'
I found a solution to the problem, if an idiotic one: set the toggle of your browser window's Maximize/Restore down to Maximize (= tooltip text; this indicates that the window is in a nonmaximal state). Make the browser window actually smaller than screen fit. Press F11 in this state and there is no white line at the bottom of your screen (Win7 x32 & x64). (BTW, FF dose not have this problem and is the best alternative.)
It happens when you use fractional font-sizes.
For example, stackoverflow uses h2 {font-size: 140%;} body { font-size:80%;}, which results in an total font-size of 112% for h2. Apply that to 16px default size, and you get 17.93px (including rounding errors, hooray!)
Try it yourself: getComputedStyle(document.querySelector('h2')).fontSize
Browsers have a hard time rendering fractional pixels, and thus may get confused and add a pixel at the bottom.
By the way, Firefox has some trouble too. The spacing between the footer lines is off by a pixel.
The fix is obvious: Use integer pixels to declare font-sizes.
Another way would be to apply a :after content to your body only for IE and Edge.
This way you will get rid of the extra white line.
We may require some jQuery too so that the content applies only when you are at the bottom of the page.
body{
position:relative;
width:100%;
}
body:after{
content: "";
display:block;
background-color: #000;
height: 1px;
bottom: 0px;
position: fixed;
width: 100%;
}
jQuery
//add a border to internet explorer
if (bowser.name == "Microsoft Edge" || bowser.name == "Internet Explorer") {
//console.log(" iam inside");
$(window).scroll(function () {
if ($(window).scrollTop() + $(window).height() > $(document).height() - 100) {
$("body").addClass("end-border");
}
else {
$("body").removeClass("end-border");
}
});
}
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.