Consider the following example:
<!doctype html>
<html>
<head>
<style>
td {
padding: 0;
background: red;
}
img {
display: block;
}
</style>
</head>
<body
><table
><tr
><td
><img src="https://raw.githubusercontent.com/sinatra/sinatra/v1.4.7/lib/sinatra/images/500.png"
></td
></tr
></table
></body>
</html>
There's a red line in chrome on the right of the image. No such line in firefox. It doesn't seem like a space, because the html markup has no spaces between tags. It doesn't seem like a margin, because Developer tools doesn't report any margin.
What is this? How much space could it take?
I'm running chromium-47.0.2526.111 (64-bit), if anything.
UPD I made an example without spaces specifically to show that the red line is not caused by spaces.
Next, it was found the line appears when Zoom is, for instance, 110%. So, everything is supposedly clear now.
It is because of the way <td> elements are displayed. As you can see, they are displayed as:
display: table-cell;
This is because of how table-cell is ment to calculate pixels. Since 1 pixel is not equal to 1 pixel in CSS if you have DPI scaling enabled (or you zoom), it will start to behave weird.
You can either find another approach of your <td> inside <tr> or simply change the display to display: inline;
It's all because of how pixels sizes are calculated. I know it sounds weird, but 1px is not 1 physical pixel. Essentially what happens is your td's background changes according to the size of your image. When your image hits an odd number (because of zooming or DPI scaling), it will either round down or up. This is when the calculation happens and is wrong.
Sources: https://www.w3.org/TR/css3-values/#absolute-lengths
http://www.quirksmode.org/blog/archives/2010/04/a_pixel_is_not.html
There is no red line for me on initial load, however I can see red lines if I zoom in, which begs the question, is your browser set to zoomed in?
Look for the magnifying glass in the url bar of google chrome and make sure you're set to 100%
Causes when not zoomed
Since you have padding set to zero on your td element, that's fine, and the only thing that can make the same effect is to have the margin on the image (the margin on the child element sort of behaves like a padding on the parent element in this case). The margin could be set either by you, or by your browser's stylesheet (I don't see it on mine).
Set img {margin: 0} and it should be gone because you've covered both cases that could cause it.
Zooming problem
If you see it only when zooming, it's because of browser's sub-pixel rendering (when the pixel values become floats and the browser starts rounding or flooring them). And due to the extremely non-power-of-two dimensions of the image (313x161) it's highly likely to get that extra pixel line on various zoom levels when, say at 110% zoom, the calculated width of the td is 313.636 pixels, and the image 312.997 pixels, which become 313 and 312 when floored. That leaves us with the td element being one pixel wider than its child image, which is where the line (the red td background not being "covered" by the image) comes from.
img {width: 100%} fixes this (as Aziz already said in the comments)
This may help you:
td {
padding: 0;
background: none;
}
The correct answer is that for several years Chrome has handled images in tables defectively and no one can comprehend that this the actual problem. You have to take the images out of the table and put them in divs...
Related
I am trying to understand why my HTML elements render in sizes that don't match what is specified by my CSS. As an example I have this declaration in my CSS:
.productselectorslist > div { border-bottom-width: 1px;}
However, when I look at the element in the browser dev tools when the element renders in Google Chrome it shows:
border-bottom-width: 1.1111111640930176px;
This sort of size difference is all over the place in the rendered code. It appears like it only starts in the DOM once I start including borders. Once that happens virtually every element has unusual sizes that don't match what I specified in the CSS.
How can I fix all the sizes to always be integers?
That happens when you zoom out to 90%.
The border is still rendered as a whole pixel while the "logical pixels" are smaller than a whole pixel. The style is adjusted to 1/0.90 = 1.111111 so that it becomes a whole pixel when scaled down.
Although I can't think of any reasons why your borders would render in different sizes, one way of dealing with this issue would be to give a !important at the end of your code.
Now this is a work around, and by no means ideal, it might just resolve your issue for the time being.
div#test{
border-bottom-width: 1.1111111640930176px !important;
}
Let's say hypothetically you have 5 divs. One is a container and the other four are children. You've set each one to be 25% of the container and you've given each one a background separate from the container background.
When you resize the browser your 4 divs at some point in time do not go all the way across, they might be a couple pixels off. Is there a way to stop this form happening? I'm assuming it's happening because it's 'snapping to each pixel' therefore leaving a small gap when resizing the browser.
#container {
width: 100%;
background: #000;
}
.children {
width: 25%;
float: left;
background: #fff;
}
JSFiddle: http://jsfiddle.net/AEvUL/
Screenshot of JSFiddle page in safari: http://cl.ly/image/1o1O2O401E0f
John Resig has a post about this issue that uses this exact case as its example.
http://ejohn.org/blog/sub-pixel-problems-in-css/
Take the following page for example. You have 4 floated divs, each
with a width of 25%, contained within a parent div of width 50px.
Here’s the question: How wide are each of the divs?
The problem lies in the fact that each div should be, approximately,
12.5px wide and since technology isn’t at a level where we can start rendering at the sub-pixel level we tend to have to round off the
number. The problem then becomes: Which way do you round the number?
Up, down, or a mixture of the two? I think the results will surprise
you, as they did me.
There are also several Stack Overflow questions on the subject:
safari rounding down on subpixel calculations
percent (%) width rendered differently in different browser (firefox, safari, opera, chrome)
I have noticed a problem with size of elements in Chrome browser.
I have written a simple code:
<html>
<body>
<table border="1px">
<tbody>
<tr>
<td>
<span style="display: inline-block; width: 5cm">TEXT</span>
<span style="display: inline-block; width: 5cm">TEXT</span>
<span style="display: inline-block; width: 5cm">TEXT</span>
<span style="display: inline-block; width: 5cm">TEXT</span>
</td>
</tr>
</tbody>
</table>
</body>
</html>
I expect to have 4 spans repeated vertically, 5cm each. It works on IE, Firefox, etc.:
IE - Works fine
But Chrome suffers the following problem:
Chrome - Doesn't work
In IE, spans have 189px width each and td has 772px.
In Chrome, spans have 189px width each and td has 771px.
Is this some kind of Chrome issue? Why my td element doesn't fit its content? It's important for me to stay with those span elements (I cannot replace them with i.e. div) and to set width in cm. The issue still exists when I remove table border.
CSS cm units are unreliable if you want a fixed number of pixels. They're also not likely to actually measure 5cm on the screen. The cm unit is intended mainly for printing styles. Yes, it can be used on screen, but don't expect any accuracy from it.
The fact that a 5cm box is rendered as 189 pixels tells us that a cm is not a whole number of pixels. This alone should be enough to tell you that you're unlikely to get accurate pixel-level cross-browser rendering using cm units.
It's just not going to happen. If you want pixel-perfect accuracy, use px units.
You say in the question that you can't change the units. You really should reconsider that if possible, because it's only going to keep giving you these issues.
If you really can't change them, then the one way I can think of to resolve your issue without changing the units is to give the <td> element a white-space:nowrap style. This should force all the spans onto the same line regardless of whether the browser thinks they should be there or not. It should do the trick for you. But it doesn't resolve the underlying problem, and it will likely come back in other ways if you keep using cm units on the screen.
As for what exactly is causing the glitch in the first place, I would guess that Chrome is handling the floating point pixel values slightly differently, and that there is a rounding error when it adds the pixel widths of the spans to work out how wide to make the <td>. If this is the case, then it sounds like a bug in Chrome, and you could report it to them, but given everything I've said above, I can't see them making it a high priority issue.
In Firefox and Chrome and Safari (latest all, on Mac 10.6.8) if I use a browser's developer tools to reduce the font size of the following span, I can watch the height (line-height) of the paragraph increase by a few pixels :
<p style="line-height: 40px; background: red;">
Some sample text some sample text.
<span style="font-size: 100%;">As this span's text size gets smaller, the paragraph gets taller.</span>
</p>
Can someone explain why this happens?
Ok, so I posted your sample html and inline css into js fiddle, here's the link:
http://jsfiddle.net/sauhL/
I then used firebug to change font-size:100%; down to 99, 98 and so forth. You are right, when you go down 1 by 1 for the font-size value, the red box gets a little bigger for a second.
The problem is that you have line-height predetermined as 40px, which causes what you called a 'bug' because line-height applied to different font sizes leads to different height renderings, and in the case of js fiddle, the linebreak is also a factor in the 'rendering' of the red box's height. After going down several points in %, there's no more expanding of the red box but rather a diminishing of size.
This is easily fixed by applying line-height:100% to the span which normalizes the height and makes sure there's no odd increases. You can expect these kinds of 'bugs' or anomalies when mixing fixed values (say 40px for example) with percentual values (100% or whatever).
Hope this solves your question
I'm having trouble with this page: http://seatgeek.com/atlanta-hawks-tickets/. If you zoom out one level from the "normal" setting in Firefox, the page looks like this: . This happens with both versions 3.6 and 4.0 of FF. It does not happen with Webkit.
Clearly the problem lies in the elements within the "list_details" div. The problem can be fixed by decreasing the width of the "col1" or "col2" spans by 1px or by increasing the "vevent" li element by 1px, but these fixes cause the design to render improperly.
If you add up the width of "col1" and "col2", also taking into account their horizontal padding and border, the total width is 647px. But it only displays properly in Firefox (when zoomed out one level) when the "vevent" element, which contains the two, has a width of 648px. Why is that?
as this appears to have been bumped, but the original code is not available, I can say that the difference would have been caused by rounding (or sub pixels), the OP said the problem didn't happen when the div was 648px wide.. an even number can be halved, or split between 2 columns (OP also mentions 2 columns) quite easily no matter the zoom level
However the odd number647px will have been treated differently by Firefox
I cannot say exactly how as I can no longer see the widths of the two columns, but this blog post by John Resig, may explain better
Sub-Pixel Problems in CSS
one possible solution, or at least a helper, is to make sure the available width of the container is always divisible by the number of columns?
removing the margin-right from the following css fixed the zoom out issue
#left_container .search_details .list_details {
margin-right: 1px;
}
Add the margin-right:-1px to the following css. This can fix the zoom out issue.
.team-show .static-sidebar {
line-height: 22px;
margin-right: -1px;
position: relative;
width: 255px;
}
For future reference those looking for a general answer to why zooming can cause layout breaks
http://dev.jeffersonscher.com/resolution.html
Also use relative units to size things
https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/Values_and_units