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
Related
I have a huge div with size of 33,554,432x33,554,432 px on a page with absolute position. There are two divs inside it with these styles:
position: absolute;
left: calc(64.2571% - 1px);
top: 100px;
width: 46px;
height: 10px;
and
position: absolute;
left: calc(64.2571% + 1px);
top: 111px;
width: 46px;
height: 10px;
which should be placed 2 pixels different from each other, but there's absolutely no difference between the left position of them.
If I change the left properties to calc(64.2571% - 2px); and calc(64.2571% + 2px);, it's working fine.
I tried to post a fiddle with those conditions but at jsfiddle it works fine. I'm worried it's a silly problem, but I checked everything and can't solve it.
I'm using Chrome Version 51.0.2704.103 m.
I've just managed to make a similar fiddle.
I would believe this has to do with the way Chrome handles very large sizes, or possibly how other browsers handle them.
Even though you specify that you want the wrapper element to be 33554432px wide (more than 33 million pixels!!) Firefox only creates a space of 17895700 pixels (almost half). This is visible in your fiddle (slightly edited version, added console logs) when you open up the dev tools. After some digging, I found out that Gecko-based browsers do put these limits. Other browsers most definitely also have them in place (to prevent memory issues I presume), but for Geckos, it's at 17,895,700 pixels.
More precisely, as this website puts it:
Gecko-based browsers like Firefox show an interesting behavior when
trying to make the site any higher than 18.939583 kilometers,
“shrinking” or “collapsing” its main container.
If you convert that value to cm (a valid web unit), and set the item to this width (18939583cm) you'll see that this indeed agrees with the width in pixels I showed previously.
The point is that, even though your code should theoretically work on Chrome, it doesn't (probably because something goes wrong with the number crunching/rounding). That sucks. The upside is, though that it doesn't work on Firefox either - at least not in full, as it shrinks down the page. As a consequence it is probably better to find another way to achieve what you are doing -- instead of creating a canvas of more than 33 million pixels wide.
What comes to mind is ajax loading of content, and only showing the necessary parts (e.g. 1000px overflow in each direction). This will ensure a good loading time as well, though it may be harder to SEO optimise and implement.
EDIT: I didn't notice at first, but from the given fiddle it is also clear that Chrome puts a limit on the size! It's set at 33,554,428 pixels, which is almost the size you want.
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 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;
}
I am having a problem with the following page in plunker. I also have tested it outside of plunker and I get the same result. My problem is that the following CSS get lost somehow. When I look at the computed CSS in chrome the width and height are different even when I can see that it recognized that rule. I am using bootstrap CSS.
table.scroll {
width: 40px;
height: 40px;
overflow: scroll;
}
EDIT:
The intention was to make the table scroll-able. But there no scroll bar appears. The CSS looks correct but apparently it does not work on tables. And the browser just ignores the CSS.
According to the W3C, user agents may reflow tables if the width of their cells is greater than the width that the author specifies. Chrome cannot possibly fit all of that data in a 40x40 table, so it scales it up to fit.
There are some ways to fix the width of the area containing a table, but it will probably require extra markup.
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)