I have this annoying problem with Chrome (or FF?). I haven't checked on IE yet.
There is one pixel difference in rendering and I have no idea where I can dig for more. I've used all inspectors for the three browsers (FF, Opera, Chrome) to see, if there is anything to tweak, with no success. It is either a bug, or I am blind for this error.
See an example here: www.vanwright.com/catalogue/le-kex-walking-kids/
The problem refers to the left margin of the first images from the left in both rows. Chrome shows 2px border, while other browsers show 1px, which is what I am after.
Is it caused by nth-of-type selector?
Probably not, because here: www.vanwright.com/collections/ it seems to have the same problem (margin-left: -10px shows with a 1px line in Chrome, while there is no space in FF/Opera).
I am lost. Any ideas?
Thanks,
pop
Option 1
To fix and maintain 960px layout:
remove all the :nth-of-type css on .pi-pad
change the css for .pi-pad to read: .pi-pad {margin: 1px 1px 1px 0; width: 318px; padding: 0px;}
Fix background to math 960px layout ( I think it is currently designed for a 979px layout);
Option 2
Expand current layout to match background. (which is clunky, because the background's width is no divisible by 3)
CSS for .container and .span-12 should specify width: 979px
Change either the .pi-pad:nth-of-type(3n+1) or .pi-pad:nth-of-type(3n) CSS to read width: 325px; and remove the other.
Change the .pi-pad CSS to read .pi-pad {margin: 1px 1px 1px 0; width: 324px; padding: 0px;}
=========EDIT=========
I posted this before I saw your replies above, and I also forgot to hide your overflow.
Using option 2, and now that I know for sure it is 980px (it looked like 979 when I measured)
.container and .span-12 should have width: 980px;
Change the .pi-pad CSS to read .pi-pad {overflow: hidden; margin: 1px 1px 1px 0; width: 325px; padding: 0px;}
Use .pi-pad:nth-of-type(3n) OR .pi-pad:nth-of-type(3n+1) should specify width: 326px; and delete the other.
It's a Chrome bug. Thanks to runspired for taking time. Sorry for anyone trying to fix the unfixable.
Background center with chrome (bug)
Related
I have a table, that for one of its cells I am using the rule
border-right: 3px solid #000 !important;
It works fine on Chrome but in Firefox the border is invisible. I say invisible because if I deactivate the rule I can see the cells' contents move slightly.
-moz-box-sizing: border-box;
Did not help in any way as far as I can see.
So if you were to run this small example in Chrome, it would look fine. In Firefox you can spot some errors though (be sure to view at a wider width to see the error)
I have tried various other suggested option with no good results. The one closer to solving the issue was removing border-collapse altogether, but that makes all borders visible as can be seen from the image below:
Is this common for Firefox, and how can I overcome the issue.
One thing to try would be to add another block element inside of the table cell and apply your border style to that element. For example, you might try to do something like this:
<table>
<tr>
<td>
<div style="border-right: 3px solid #000;">My Content</div>
</td>
</tr>
</table>
Table cells like <td> and <th> are sized differently than regular block, inline block, or inline elements and so the borders might also get computed slightly differently depending on available space.
By using a <div> inside of your table cell, you can set it's width to 100% and it's height to 100% so that it covers the entire available table cell, then you can apply any border you like to the div and with box-sizing:border-box set on the div element, it should look the way you want. For example:
<div style="border-right: 3px solid #000; width: 100%; height: 100%; box-sizing: border-box;">My Content</div>
Here is more info on table sizing / box model quirks
I have updated your original jsfiddle https://jsfiddle.net/sfodcjkz/4/ with some of the minor tweaks
https://jsfiddle.net/sfodcjkz/18/.
The changes I carried over your fiddle are:
Removed empty <tbody> elements. Best practice is to group the body rows inside a <tbody>. Some modern browsers may auto correct the errors, but not all browsers are smart enough. So for consistency, we can avoid being dependent on smarter browsers.
Next I had problems with these css:
Line:349
.responsive-table thead {
clip: auto;
height: auto;
overflow: auto;
position: relative;
width: auto;
}
Line:258
.responsive-table thead {
border: 0 none;
clip: rect(1px, 1px, 1px, 1px);
height: 1px;
overflow: hidden;
padding: 0;
position: absolute;
width: 1px;
}
Simply removed those css styles and you can see a cleaner look.
It's a known 'bug' in Firefox. It's being caused by setting the border-collapse to collapse. One solution is to set the border-collapse to separate.
I have a question on something weird that is rendering on the latest IE and Chrome browsers. I have a div that is supposed to span 100% of a parent. So clumsily, I gave it - width: 100%px; as a CSS property. Here is my entire item:
.loc_vendiv{
position: relative;
margin-top: 5px;
left: 0px;
width: 100%px;
height: 120px;
border: 1px solid #333;
background-color: #fff;
}
The weird thing - that worked perfectly. So much so, that I just noticed today that this was wrong. Not wanting an ugly style sheet, I removed the px from the end. And... the div was two pixels too wide. Any explanation as to why this is happening? Here is the parent div:
#loc_catlist{
position: absolute;
width: 612px;
height: 720px;
top: 50px;
left: 0px;
background-color: #eee;
overflow-y: auto;
overflow-x: hidden;
}
I'm mildly annoyed, as the bad code works, yet the correct code doesn't do what I want. I don't think I can leave it, though. I don't like little hiccups like this...
It's because of your border.
Try adding :
box-sizing: border-box;
to your .loc_vendiv class, it will take the border in account.
Browsers usually ignore invalid css rules like width: 100%px; which means that to get the style you had with the mistake. you only have to remove the width rule.
2px too wide is likely caused because you have a width of 100% in addition to a border of 1px (all around adds up to 2px width).
A fix can be found here from "Paul Irish" about
box-sizing
what happens is that when the width value is wrong (100%px;) this part of the CSS is simply ignored by the browser. If this part of the css was deleted, the result would be the same.
About the 2 extra pixels, this happens because of the border set to the div.loc_vendiv.
The width of div.loc_vendiv is equal to the width of div#loc_catlist and to this is added the border value (1px for the left border and 1px for the right border = 2px).
Remember that the border width is added to the size of the object while the padding creates an internal space.
I'm seeing a rendering issue for a 2px dotted border similar to CSS dotted border issue in adjacent columns in a table rendered as dash in Chrome but on desktop Safari and Chrome. I tried several widths and it happens in all of them
This is a sample:
the vertical line ending has the same issue but it's out of the picture.
Sample:
http://jsfiddle.net/bcdQQ/
This issue happens if the width is not divisible by the border-width.
This works:
http://jsfiddle.net/bcdQQ/5/ (i made it a little bit bigger, for better sight)
#prodpre {
border-bottom: #555 5px dotted;
height: 20px;
margin: 0px 0px 2px 0px;
padding-bottom: 10px;
width: 505px;
}
So, the only possibility to catch this issue, would be a javascript solution, which corrects the width of the div, so it is divisible by the border-width (cause it is dynamically in your example).
could you put it in a smaller container div with overflow hidden?
on the following page:
http://dreamdeals.rnmtest.co.uk/
the login box on the right displays fine in firefox, ie8, safari, chrome etc but in ie7 & 6 the contents overflow. I have tried everything such as setting a height for the inputs but cant get it right. Anyone got any ideas?
I know this idea seems to at first glance make about as much sense as chopping off your own arms, but:
On #whyjoin input, instead of border: none, try using border: 0.
Here's a reference to the problem you're having:
http://bitesizebugs.wordpress.com/2009/08/17/border-none-not-working-on-text-input-in-internet-explorer/
So, despite border: 0 being the same as border: none, it's better use 0 because it's shorter and to avoid this bug.
I should probably go post that here.
In my IE8 (7 compatibilty mode), it's work fine ; But try to modify your height like this:
#whyjoin {
background-image: url(../images/whyjoinback.jpg);
background-repeat: no-repeat;
padding: 30px 5px 0 5px;
height: 70px; /* BG Image (100px) = 70px + 30px (padding) */
margin-top: -55px;
position: relative;
}
I Suggest you to place the #cardclip in absolute to not poluate the #rightcol.
I'm attempting to provide a consistent width per line in pixels inside of a textarea across IE8, Firefox and Safari, so that text content wraps lines as predictably and consistently as possible.
Firefox is doing something a little bit odd: it has an extra pixel of padding eating out of the content space of the textarea vs the other two browsers, and vs a similarly equipped div block.
When applying this class to both a textarea and a div the difference is visible, with the text in the div touching the outer left edge of the red background but the text in the textarea have 1 px padding-like offset in spite of padding being zero:
.testbox{
padding:0;
margin:0;
border:0;
background: red;
width: 40px;
height: 40px;
font-size: 12px;
line-height: 16px;
}
Other values for padding wind up displaying one extra pixel of offset vs a div.
Any ideas on if there's a way to trick Firefox to render a textarea as if it were a div, or to adjust this not-padding-but-looks-like-padding property for a textarea?
I have recently been doing some researching on the problem described by OP for a similar question on SO. It seems that a bug in Firefox is causing the rendering of this so called "not-padding-but-looks-like-padding" on textarea elements.
Usually this extra padding is not really an issue, but it becomes an issue when you want to keep two elements the same width, and you care about getting its content to wrap the same way in both elements.
Getting textarea's to wrap content the same as e.g. div elements in Firefox
It seems to be impossible to get rid of this 1.5px wide padding on the textarea in Firefox, so if you want to ensure that the content wrapping inside a div in Firefox behaves exactly the same as the content wrapping inside a textarea in Firefox, the best approach seems to be to add an additional 1.5px of padding on the right and the left hand side inside the div, but only in Firefox. You can accomplish this by setting the following vendor specific prefixed CSS properties on your div:
-moz-box-sizing: border-box;
-moz-padding-end: 1.5px;
-moz-padding-start: 1.5px;
The first ensures that the padding set on the div does not increase the width of the div, and the next two ensure that 1.5px of padding will be set on the right and the left hand side of the div.
This approach does not affect the rendering of the div's in any other browsers, it doesn't need to, as textarea's in other browsers don't render any extra padding. But it ensures that there are no content wrapping differences between div's and textarea's inside Firefox as long as they share the same font-family and font-size properties and so on.
Here's a jsFiddle for demonstration purposes.
Getting textarea's to wrap content consistently across browsers
If you only wanted to ensure that a textarea in Firefox has the same width and wrapping behaviour as a textarea in other browsers, you can set its box-sizing to border-box, add a padding on both sides of 5.5px and set -moz-padding-end and -moz-padding-start to 0px.
textarea {
padding: 0 5.5px 0 5.5px;
-moz-padding-end: 0px;
-moz-padding-start: 0px;
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
box-sizing: border-box;
}
Here's a jsFiddle showing this approach.
Wow, I don't know the answer yet but I did try some stuff, and it appears as though a textarea, when you apply borders, margins and padding to it, doesn't change its width but puts the borders etc. on the inside. Try this:
.testbox {
padding: 10;
margin: 10;
border: 5px solid black;
background: red;
width: 40px;
height: 40px;
font-size: 12px;
line-height: 16px;
}
You could work around this by using something like this:
<div class="testbox">
<textarea class="testarea"></textarea>
</div>
css:
.testbox {
padding: 0;
margin: 0;
border: 0;
background: red;
width: 40px;
height: 40px;
font-size: 12px;
line-height: 16px;
}
.testarea {
padding: 0;
margin: 0 -1px;
border: 0;
background: red;
width: 100%;
height: 100%;
font-size: 12px;
line-height: 16px;
}
This also seems to work in IE, except for the -1px, which throws the layout off (by one).
This is a bug in firefox which got fixed a few days ago. The fix will be released with Firefox 29.
I already tried the latest nightly build and the textara bug is gone!
I was facing the same problem and although my solution seemed like bending backwards too much for that one pixle, but it fixed the problem, here goes: To unify the width because of this weird behavior, Instead of using a div, i used a disabled textarea with a white background and a default cursor to act as a mimic the div.
I was having a similar problem, a link tag with a background image and padding did not display well on firefox. The padding and background seemed to apply to the line of text, not the block of text, when multiline. I tested out a few things, and ended up using a "display:block;" on the element css. Worked for me.