This is driving me crazy. Firefox text is 1px lower than in chrome and ie. It's not a margin or padding issue on html or body, tried that. Doesn't seem to be a rounding issue either. Here is an image:
First "Hello" is Firefox 13, Second "Hello" is IE9 and "Hello World" is Chrome.
Here is the code (pretty simple):
<!DOCTYPE html>
<html lang="en-us">
<head>
<meta charset="utf-8">
<!-- Always force latest IE rendering engine and chrome frame -->
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
<title>Pixel Bug?</title>
<style type="text/css">
html{
font-size: 100%;
}
body{
font-size: 1em;
line-height: 1.5;
background: white url('images/grid16.png') -4px -6px;
}
p{
margin: 1.5em 0;
}
</style>
</head>
<body>
<p>Hello World!</p>
<p>Hello World 2!</p>
</body>
</html>
Is it just a bug? What is going on here? I don't want a FireFox only work around, I just want to understand why this is happening.
EDIT:
Upon further research it seems to be a rendering bug, but it still confuses me. For example, the height of the text should be 24px. Which shouldn't really cause rounding errors that would cause this. Yet, if I change the line-height to 23px explicitly it lines up. I have no idea why.
EDIT2: Possible reason? https://bugzilla.mozilla.org/show_bug.cgi?id=442139
EDIT3: Lines up using a 20px font and 40px line height. Makes me think this is just so rendering bug. It's sucks cause 16/24 is pretty standard :/
See my earlier answer here::
CSS white-space and list-style-image do not stack in Firefox 11+
You are not using reset.css thus creating problems
Here you can find many links for the reset.css
Reason for using reset.css is because it will make all user-agent(browser) css to a base settings, so that they don't look different in different browsers.
Edit::
As the OP used the reset.css . I can't reproduce the issue. So the other reasons might be
Font rendering issue of different broser engine. No particuar fix Read more
Issue with hardware. Joel talks about it in his blog.
Also, I agree with what #steveax said.
Edit 2::
If you want to go in depth about it .
Raise a bug
Try tuning your browser yourself
Related
I need some help. While I was working on a project in Chrome, I wanted to test it in Firefox and was puzzled as to why it looked so different.
Can anyone explain to me why the green div containing the image doesn't adjust its width relative to the child? Is it a bug? Is it a feature? Is it a bugfeature?
Research
It works, as I expect in Chrome, where it looks like this:
But in Firefox, there is a lot of weird white space (this is the same image as the first):
Also, here is a screenshot of the following browsers (starting from the left) Firefox, Opera and Internet Explorer 11:
As you can see, it works like I expect in Opera, but not in FF and IE11. It doesn't work in Edge either.
My findings
It looks to me like Firefox forgets to recalculate the parent's width after the image has been resized.
Here is a screenshot without height constraints (100% of the parents 200px height):
If I readd the height constraint, it looks like this:
As you can see, the width is the same. Note that the green div's width is 510px. That is the the same as the image (500px) + the padding (5px + 5px).
The code
I tried to add a jsFiddle, for your convenience, but curiously, I were not able to reproduce the error there (it worked as it was supposed to).
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<style>
.wrapper {
height: 200px;
}
.div1 {
float: left;
background-color: green;
}
.div1 img {
height: 100%;
padding: 5px;
}
.div2 {
background-color: blue;
}
</style>
</head>
<body>
<div class="wrapper">
<div class="div1">
<img src="http://placehold.it/500x500">
</div>
<div class="div2">
<h1>Heading</h1>
</div>
</div>
</body>
</html>
I'll answer my own question in hope of helping someone else
TLDR:
I was missing the HTML5 doctype declaration, which looks like this: <!DOCTYPE html>.
Longer version:
While writing this question, it suddenly struck me that it could be caused by the lack of a doctype declaration. A quick test confirmed my suspicion. All I was missing was the <!DOCTYPE html> declaration!
It's safe to say that I'll update my snippet to include a doctype. I used Visual Studio's doc snippet and never gave it another thought. Note that the html snippet already includes a doctype. (In VS: If you type html or doc and hit tab in an HTML document, a quick HTML template will appear)
Why
Without a doctype declaration, the browser renders the page as best it can, in the so called quirks mode. In quirks mode the browser has to guess how the page is supposed to look with primary focus on backwards compabillity. Therefor the result naturally deviates from newer specifications.
The doctypes was invented to differentiate legacy sites from those using newer specs back when IE and Netscape was a thing. You can read more about it on MDN here:
Doctype
Quirks mode
Nice to know:
Make sure you put the DOCTYPE right at the beginning of your HTML document. Anything before the DOCTYPE, like a comment or an XML declaration will trigger quirks mode in Internet Explorer 9 and older.
-MDN
In HTML5, the only purpose of the DOCTYPE is to activate full standards mode.
-MDN
How to see which mode is being used
On Windows, click alt to bring up the good old toolbar, then go to Tools ➡ Page info
I am having issues styling a custom and fancy #font-face on a a link.
The font (Alex Brush) goes outside of its boundaries (by boundaries, I mean the clickable section in this case), which is usually not a problem for browsers. However, I have noticed that when I use a different color for the :hover state, the exceeding section keeps the non-hovered link color.
This appears on Chrom{ium|e} (I am using Chromium 31 on Ubuntu 13.10) but not on Firefox. After further testing, I notice that other strange glitches happen depending on how you play with your mouse and tabs, ...
TL;DR: you can try it online.
Or, here is some HTML you can play with:
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<link rel="stylesheet" href='//fonts.googleapis.com/css?family=Alex+Brush'>
</head>
<body>
<a>!</a>
</body>
</html>
And the corresponding CSS:
a {
font-family: 'Alex Brush';
font-size: 400px;
color: red;
text-decoration: none;
}
a:hover {
color: green;
}
Here is the glitch I get when :hovering the link:
Is it possible to tell the bounding box to include the entire font?
Bonus question: On top of fixing the bounding box for styling purposes, is it possible to fix it once and for all? The use case would be to have a proper clickable section that would include all the text, without using display: block or display: inline-block.
Interesting. I looked at a similar issue last month last month. The exact same bug was addressed there, and I've seen it happen there too.
But in the mean time, this issue seems to be fixed. The current version of Chrome (Versie 32.0.1700.76 m) shows the glyph being properly colored on :hover. Both your example as the example in the link above now work fine. I'm pretty sure the issue will be/has been fixed in Chromium as well.
Check out my original answer if you want to know more about what font-specifics made this bug happen.
Works normally in Chrome
I Don't have Chromium, but I often hear about sites that are buggy on Chromium, I don't know any 'normal' person who uses it which is why I don't test in Chromium
anyway, this is a weird possible solution, but it might work?
a:hover {
color: transparent;
text-shadow: 0 0 green;
}
I had a similar problem in a menu and looked at RoeIn's initial answer, which he linked to, but this put the whole menu alignment out. However, the solution below worked for me:
padding-right: 20px;
margin-right: -20px;
Or whatever dimensions best suit your purpose. As long as the padding equals the negative margin it doesn't put other elements out either.
Ignoring discussions of what a 'normal' person might use for a browser, this problem exists in Safari as well.
I have a web project that just breaks when I run it on Internet Explorer. Here it is, working as I want it to, on jsfiddle.
On IE, the display_area goes up and mixes with the toolbar up top. Also, the posts mixes into the side_display_area instead of them being confined to main_display_area, as is on the jsfiddle.
The problem I had was because IE, by default, uses 'Quirky' mode for its CSS rendering for the sake of compatibility with older code that was written ad hoc for IE. Although IE currently has different standard compliant modes(I can't attest to how compliant, however), it still defaults to this compatibility mode.
The solution is to override, or explicitly set, the rendering mode of IE via the X-UA-Compatible header. You can do this through html tags with:
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
</head>
more info
I think this may help http://css-tricks.com/the-css-overflow-property/
Consider adding some div to you horizontal menu and put some height on that
div.hmenu {
margin-left:auto;
margin-right:auto;
height: 20px;
min-width:1000px;
max-width:90%;
overflow:auto;
}
I just finished designing a webpage for my photography. I used Chrome as my test browser.
But opening my page on IE, nothing was visible. After some trouble, I isolated the problem to the fact that I'm using percentages. I searched online for solutions but everything is about minor variations (related to padding and percentages).
Here is a simple HTML file that works perfectly in Chrome, but not all in IE (the div is a pixel-less box, slightly expanded by the presence of text). Your help is greatly appreciated. If I can't solve this issue, I'll have to completely redesign my site.
<html>
<head>
<title>A test HTML</title>
<style type="text/css">
#currpage
{
position: absolute;
bottom: 18%;
right: 10%;
left: 35%;
top: 15%;
border:2px solid green;
z-index: 240;
}
</style>
</head>
<body>
<div id="currpage" style="visibility: visible; opacity: 1;">
This is just a test.
</div>
</body>
</html>
Have you tried... actually making a well-formed HTML file?
Without a DOCTYPE, the browser renders the page in Quirks Mode. In the case of IE, it renders as it would in IE5.5, which didn't support a lot of now-basic stuff.
Add <!DOCTYPE HTML> to the start of the file.
EDIT: While you're at it, always include a Content-Type <meta> tag (such as <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> so that the browser knows what the encoding is. Also consider adding <meta http-equiv="X-UA-Compatible" content="IE=edge" /> to force IE to use the strictest standards mode it has. These appear on every single one of my pages, even the blank template. The DOCTYPE and Content-Type are required (if you want it to actually work), and the Compatible header is optional (I mainly use it to get rid of the Compatibility Mode button that is annoyingly close to the Refresh button...)
Well, I'm on mac, so I can't check it, but it seems that you don't have a doctype in your HTML, so the IE might be in trouble because he doesn't know how to parse your code.
At the very first line (even before the <html>-Tag write the following:
<!DOCTYPE html>
This is for a HTML5 document.
Edit: ....edit.... forget that point.
Set height and width of the containing element explicitly. I had a similar issue with one of my old pages (worked fine in Firefox and Chrome, went to hell in IE) and what I found that that in that Firefox and Chrome will automatically set the dimensions of the containing element if none are explicitly assigned and then base those percentages off those assumptions. IE makes no such assumptions so when it looks at the percentages it basically says "um 35% of what?"
Certain pages display terribly in IE generally, what is the best approach to solving these issues?
You forgot to add a doctype, so your page is in Quirks Mode.
Add this (the HTML5 doctype) as the very first line:
<!DOCTYPE html>
and it should look better.
Although, changing the Document Mode manually (using Developer Tools; hit F12), it still doesn't look right. There are evidently other problems with the page.
The most pertinent problem (after escaping Quirks Mode) is this:
<body style="margin: 0; padding; 0;background-color: 4DA2CA;">
Internet Explorer is not showing any background colour because you forgot the # before the colour. (And you have padding; 0, with a ; instead of :)
This will work:
<body style="margin: 0; padding: 0; background-color: #4DA2CA">
But you shouldn't be using inline styles in the first place..
This would be better:
<body>
with CSS in your stylesheet:
body {
margin: 0;
padding: 0;
background-color: #4DA2CA
}
you mean that in IE the Div's are smaller.Thats because in IE css border,margin are included in the width declared.So, if you have given a div width of 100px and a margin of 10px both sides then in IE the actual visible width of this div will be 100-10-10=80px.To solve the problem you can use child css decleration.
Considering our example if you want to show this div 100px width in both the browsers do the following
.mydiv{ /*This deceleration will be understood by all the browsers*/
margin:10px;
width:120px;
}
html>body .mydiv{ /*This deceleration will not be understood by IE browsers so other will override the width*/
width:100px;
}
Using this you can uniform the width of your Divs across both IE and non-ie browsers
Instead of pointing out the reason for each element's different way of rendering in IE, I would strongly recommend not re-inventing the wheel each time you create a new page element.
Even in modern standards-complaint browsers, CSS can be very unpredictable, so it's better to use bullet-proof snippets of code from trusted sources such as
CSS the Missing Manual
CSS the Definitive Guide
CSS Cookbook
Start out with working blocks of HTML/CSS and modify them to your liking and test cross-browser from there. The whole process will be much less frustrating.