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.
Related
Seeing a very strange glitch with a large drop shadow on a site that is in development. Only seems to happen in Chrome. Glitch will disappear and reappear as window is re-sized.
url: https://w3stage.com/pok/order/
img: drop shadow issue
css:
.set-container {
background: #f7f7f7;
border-radius: 7px 7px 0 0;
padding: 30px;
text-align: center;
max-width: 900px;
margin: 0 auto;
width: 90%;
box-shadow: 0 70px 70px rgba(0,0,0,1);
display: flex;
align-items: center;
align-content: center;
}
edit: i am on macOS, Chrome Version 81.0.4044.138 (Official Build) (64-bit)
I managed to get the same result in specific window sizes.
I played around a little bit and what seemed to cancel this issue was removing the border-radius definition from the .set-container class definition.
I am not sure why it worked, but I have seen in my experience that shadows and border-radiuses sometimes have issues. You could consider restructuring that part or just removing the border-radius.
Just as additional info, I was able to reproduce the issue on:
Chrome 83.0.4103.61 (64-bit)
Window size: 936 <= Width < 1200 and 701 < Height < 763.
I am not sure if there's something specific about those dimensions in your case, but that's where I seem to get the extra shadow.
UPDATE
I did test something else that does not have issues (as far as I am aware) with the border-radius.
I switched from box-shadow to filter: drop-shadow. The end result is this line:
filter: drop-shadow(0 70px 70px black);
It looks a little bit different than the box-shadow rule, but does the trick and doesn't have issues with the border-radius.
I am also seeing this aberration in Chrome v86 on a PC and in Chrome v86 on an iPad. I found that I could reliably make the effect half as large (huh?) by eliminating overflow: hidden from the parent div to my image (which has the drop shadow).
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 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)
Rounded corners on my jQuery sliders only work in Firefox.
Renders correctly in Firefox 17.0.1 (see image below)
Not rendering correctly in Safari Version 6.0.2 (8536.26.17) (see image below)
Not rendering correctly in Chrome Version 23.0.1271.101 (see image below)
Here is the jsfiddle build: http://jsfiddle.net/plasticmonument/TCVH5/1/ (note, I only gave full path url's to the slider images, everything else will be missing)
My HTML:
enter code here
My CSS:
.hero-wrapper {
position: relative;
z-index: 2;
float: left;
width: 100%;
height: 429px;
border-radius: 10px;
border-top-left-radius: 0;
-webkit-border-radius: 10px;
-webkit-border-top-left-radius: 0;
-webkit-border-bottom-right-radius: 10px;
-moz-border-radius: 10px;
-moz-border-top-left-radius: 0;
-o-border-radius: 10px;
-o-border-top-left-radius: 0;
-ms-border-radius: 10px;
-ms-border-top-left-radius: 0;
overflow: hidden
}
#feature-slider ul.slider {
position: absolute;
top: 0;
left: 0;
width: 900000px
}
My guess is that it's the old "foreground images aren't clipped" bug.
In some browsers, a border radius may be applied, but foreground images of the elements with border-radius aren't restrained by the radius.
I was under the impression that this was something that had been dealt with by the major browsers, but it's not something I've looked into for a while, so I may be mistaken in that. It certainly looks like it's what you're seeing. I remember it was quite a big issue back in the days of Firefox 3.x, but if I recall correctly, the FF team sorted it out somewhere between v4 and v8.
To prove it, add an actual border (eg border:solid black 2px;) to the element, and see what happens. If the border disappears under the image at the corners as it follows the radius, then this is the bug you're seeing.
If this is the problem, then the solutions are:
Use a background image instead; this won't be clipped.
Add an additional layer of markup -- eg a <div> with the existing <img> inside it, and put the border radius on the <div> instead of the <img>.
Ignore it, and wait for browser vendors to fix the issue.
I've been working on a print page for a client. After playing around for awhile I've found I get an extra blank page. The unusual thing is that if I select "Outline Block Level Elements" in Web Developer for chrome, the extra page disappears. This is all the CSS being used on that page right now:
#page
{
size: auto; /* auto is the initial value */
margin: 0mm; /* this affects the margin in the printer settings */
}
body
{
background-color:#FFFFFF;
height: 296mm;
border: 1px solid black;
margin: 0px; /* this affects the margin on the content before sending to printer */
}
.print_A4 {
margin: 0mm;
padding: 0mm;
height: 270mm; /*A4 Size*/
width: 210mm; /*A4 Size*/
}
.A4_content {
margin-left: auto;
margin-right: auto;
margin-top: 44mm;
height: 210mm;
width: 165mm;
}
I've done a lot of googling but I can't see anything related to this. The body border clearly shows the div ending before the end of the first page, however I still get an extra blank page for some reason.
Could it be there is something adding only 1 pixel somewhere? Since you define the page to use full 270 mm height. Even one margin/padding/border would add a new page.
Does it still happen if you decrease this value? If not, then I suggest you take a small bit off this value (you don't use full height anyway.) You can add page-break: after to .print_A4 to prevent a next page from taking the little space left on the previous page.
Really late answer, but I think my contribute can help someone with the same issue I came across making use of CSS to setup a page for printing:
creating a dynamic html content and appending it to the body element with the purpose to print only such content, I realize that only Chrome (version 46) and Opera (version 32) creates an extra blank page at beginning while printing, this only happened when the content height was greater than the page height.
The solution provided by #mewiki solved me a 2-days-of-research-and-test problem.
Indeed Chrome and Opera seemed to have default margins and setting the following rule:
body {
margin: 0 0 0 0;
}
solved the frustrating behavior which was not encountered in other browsers.
Old question, but for people with the same problem here is my solution that fixed it for me.
I found out that the margin-bottom of the body must be set explicitly to zero (Chrome and Safari seem to have a default margin).
body
{
margin: 0px 0px 0px 0px;
}
div.page {
margin: 10px 10px 10px 10px;
page-break-before: none;
page-break-after: none;
page-break-inside: avoid;
}
For each to be printed page start with a <div class="page"> and set the page margins there so the page looks nice.
So because 27.9cm turns into something like 1423.03px I suspect it's causing the print renderer to display an additional pixel. Adding this to my page fixed the issue.
.page-a4 {
width: 21cm;
height: calc(27.9cm - 1px);
}
For anyone dealing with multiple pages. I added each page content in sections then used this:
section {
margin: 0;
width: 100vw;
height: 100vh;
overflow: hidden;
}
I had a similar problem where the introduction of a page break caused a blank page.
I don't have enough reputation to comment on wiredolphin's post, but using that suggestion, the following worked for me
html, body {
margin: 0 0 0 0;
height: 99% !important;
}
.page {
height: 100vh;
page-break-after: always;
}
I know this doesn't answer the original poster's question, but it's pretty old, and this might help someone.
Also, thanks wiredolphin! You led me in the right direction.
#page {
size: auto; /* auto is the initial value */
margin: 12px; /* this affects the margin in the printer settings */
}
I was facing the same issue and Neograph734's answer gave me an important hint.
I was also getting extra blank pages, and the only thing that worked for me was adding this rule to my css (for print)
*
{
box-sizing: border-box;
}
Then I no longer need to worry about having an extra pixel added when using margin, padding or border.
Once I've added that rule, I only had to adjust the boxes positions and everything worked flawlessly.