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.
Related
Here's a CodePen: https://codepen.io/neezer/pen/eWvLrm
Load that pen in Chrome (I'm running 57.0.2987.133).
Change the width of the <table> to 150px using a style attribute. Don't do this in the code (as it will cause a refresh--that's specific to CodePen and not my issue), but instead change it programmatically through the console or in the web inspector.
Note how Chrome resizes the table and does the proper overflow for the td/th elements:
Load that pen in Safari (I'm running 10.1 (12603.1.30.0.34)).
Change the width of the <table> to 150px using a style attribute. Don't do this in the code (as it will cause a refresh--that's specific to CodePen and not my issue), but instead change it programmatically through the console or in the web inspector.
Note how Safari does not resize the table to the given dimensions, since the td/th do not appear to shrink smaller than their content.
Why is this different? The only explanation I can think of is that Safari does not repaint the table on style changes, taking table-layout into account. I found this in the MDN docs:
Under the "fixed" layout method, the entire table can be rendered once
the first table row has been downloaded and analyzed. This can speed
up rendering time over the "automatic" layout method, but subsequent
cell content may not fit in the column widths provided. Any cell that
has content that overflows uses the overflow property to determine
whether to clip the overflow content, but only if the table has a
known width, otherwise it won't overflow the cells.
The difference to me seems that Chrome re-evaluates the table when it detects a dimension change on the <table>, but Safari does not, and thus does not overflow the cell.
I can make this problem go away if I ensure that <table> has a set width on initial render, but that's a no-go for my app, which allows the user to dynamically resize table dimensions. Needless to say, it works great in Chrome but not Safari.
Is there anyway to have Safari behave like Chrome here? Some way to force Safari to do the re-evaluation, if that is what's actually happening here?
Do Firefox/IE/Edge suffer from the same problem? Could they benefit from the same solution?
UPDATE: This little experiment in Safari's web inspector seems to confirm my theory: http://d.pr/v/bzhIH
You could wrap your <table> in <div>, set table width to this <div> and width: 100%; to the <table>.
If you want stretch your <table> for the columns content width, you need to replace width: 100%; from <table> and set width: auto; to <div>.
Here's example: https://codepen.io/Izumenko/pen/zaGGRM
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...
I’m making my first full responsive site and I have run into an issue. The site seems to be working as intended in firefox and explorer. The browsers that are giving me issues are chrome and safari.
On the bio/landing page (http://designerdsite.com/new/) toward the bottom of the page are two sections one titled “I Got Skills”, the other titled “and they love me for them”. When I load the page (no matter what size the browser width is) it loads correctly however after the browser width is shrunk and then reopened the layout repositions. In the “skills” section the div on the right side is falling below the div on the left. In the setion “they love me” the text is falling below the pictures. It seems for some reason the width on the container div is not being understood. Perhaps its something else. I am really not sure what is going on here and would very much appreciate any advice anyone has. Thank you!!
I discovered a similiar issue on my site. As far as I could figure this out, it seems that Chrome/ Webkit has a problem with the correct (re-)positioning of floated elements.
So there are 2 (maybe more) options:
1. You may use Javascript to force the Browser to re-render (not reload!!!) these elements (e.g. by changing the display property to none and back to block)
2. Use another positioning variant like 'inline-block' or 'table-cell'
Why don't you use twitter bootstrap that will make your life really easy.
it seems like you used media-query for your site right???...anyway so iguess you know the reason....for example lets assume your last media-query max width was defined as 600px ...then it will work fine upto 600px and below(not far)....when your browser is resized to width:480px (for ex.) then your design like font-size,padding etc are getting very large to fit two divs side by side....so if you want to keep your design intact for microscopic width then lets have one more media query definig that limit max-width:480px;
for example
.fonts{
font-size:18px;
}
#media screen and (max-width:480px){
.fonts{
font-size:10px;
}
}
Seems like an issue with all the percentage widths. I know WebKit can have issues with nested and rounded percentages etc, so when the page is resized both the widths on the images and quotes, as well as padding on the parent element are recalculated.
You'll see if you remove the padding: 0 5% on the max-width class, the problem no longer occurs.
Try wrapping the quotes in a 100% width div:
<div class="quote-wrapper" style="width: 100%;">
<div class="reference clear-both">
<img src="images/monica.jpg" alt="Monica" class="reference-pic">
</div>
<div class="quote">
<p><em>“Paul is the most committed hard working person I've had the pleasure to supervise. If he was unfamiliar with something he did the research to inform himself and others. Paul is one of those rare breed of people who comes to a supervisor with options not just problems.”</em></p>
<p>Monica Luchak, Former Director of Creative Services, BoardSource</p>
</div>
</div>
It has to do with how browsers compute percentages. A quick fix for that is to set a max-width for the left container:
#skills-left {
float: right;
width: 47%;
max-width:411px;
}
I've been working on this site for quite a while, and I've finally got it looking pretty nice I think. But I've noticed a problem with the home page on IE8 (no other browser has this problem that i've used)
in IE8, the site looks like this:
Notice the blue bars on the sides of the far right column, they show how wide the <td> is. the content within is 160px as it should be, but the <td> itself is wider than it should be. As you can see in the HTML analyzer on the left, the width is set to "160", however the HTML in the page says:
<td style="width: 160px;max-width:160px"width="160px"align="center"valign="top">
Out of Desperation I've tried a few things obviously. Why does IE continue to hate me? What code can I write to make IE play nice like the rest of the browsers do?
The actual site URL is http://EpicClanWars.com if you wish to dig into source.
Add table-layout: fixed to the <table>'s style. Without it, applying width to a table cell is interpreted as min-width (a carryover from when min-width didn't exist)
max-width with a percent doesn't seem to work in either IE 8 or Firefox 3. Specific pixel widths work fine. Am I missing something?
I have an input form, and I want to display some explanatory text to the right of it. But I don't want the explanatory text to squash the form.
I haven't used max-width before but it seemed an excellent solution. I wrote this simple CSS style:
div.hint {max-width: 50%; float: right;}
Then I wrote:
<div class=hint>... hint text</div>
<form action=xxx method=post>
... etc ...
The div.hint squashes the form severely to the left.
I tried this with just some text instead of the form. The div.hint takes about 95% of the screen, just gives a small margin on the left, and then the other text is pushed completely below it.
If I change the max-width from a percent to a fixed number of pixels, it appears to work. But I don't want to base it on pixels because I don't know the dimensions of the user's browser.
Does percent not work with max-width despite what I read in documentation, or am I missing something?
In response to Seanmonster's comment: Here, I'll give a trivial but complete web page that illustrates what I thought should work but doesn't:
<html><title>Max width test</title>
<style>
.form {max-width: 75%; float: left;}
.hint {max-width: 50%; float: right;}
</style>
<div class=hint>
<p>Fourscore and seven years ago our forefathers brought forth on this continent a new nation, conceived in liberty and dedicated to the proposition that
all men are created equal. We are now engaged in a great civil war, testing whether that nation, or any nation so conceived and so dedicated,
can long endure. We are met on a great battlefield of that war. We have come to dedicate a portion of that field as a final resting place
for those who here gave their lives that that nation might live. It is altogether fitting and proper that we should do this. Etc.
</div>
<div class=form>
<table>
<tr><th>Label 1 <td>Value 1
<tr><th>Label 2 <td>Value 2
<tr><th>Label 3 <td>Value 3
</table>
</div>
</html>
When I open this page in a browser, I get, not two columns, but the "hint" div taking 100% of the width, and below that the "form" div taking 100% of the width. If I change both the max-width's to "width: 50%", I get two columns as I would expect. Apparently I'm missing something about how max-width is supposed to work, but ... I don't get it.
Max-width works perfectly fine in FF3 and IE8 with percentages. Percentages, however, are based off the parent width. Not children around it.
max-width on IE8 is buggy under multiple scenarios. It is a known issue.
You can find an article on it here. http://edskes.net/ie8overflowandexpandingboxbugs.htm
You need three things to trigger this bug - maxwidth, scrollbars, and float
If you were to float the div.hint and form both to the left and have them both with a max-width of 50%, they shouldn't squish each other.
<div>
<div class="form" style="float:left; max-width:50%">
<form></form>
</div>
<div class="hint" style="float:left; max-width:50%">
</div>
</div>