My button looks fine in all browsers(Firefox, Safari, Chrome) except IE 10 (I tested on two different computers with windows 8.1). The image appears to be a bit lower in IE while other browsers have it right in the middle.
IE:
Firefox:
CSS:
#checkout {
background-image: url(../img/checkout.jpg);
border: 1px solid #D6D6D6;
float: right;
width: 184px;
height: 29px;
}
HTML:
<input type='submit' id='checkout' class='jcart-button' value='' />
I have tried using:
line-height: 29px;
Also, I noticed it works fine when I use input type='image' but the problem with that is, I need the ability to have a different image on hover. onMouseClick does the trick but doesn't work without javascript. I need something that works without javascript as well.
Edit:
Removed all my css except the #checkout part but I am still encountering the problem. So I think it is a problem with the #checkout css or the HTML part.
demo: link
Found my answer after hours of debugging :)
All I had to do was remove the border from the image and use:
border: none;
I hope that helps others!
That's probably because all browsers have quite different user agent settings for input element.
Those differences are found in margins, padding, border and god knows what else.
Open DevTools (F12) and you can see all the rules involved with the input and input[type="submit"] element.
To be absolutely cross-browser-sure you have to set all those rules manually for #checkout in the CSS.
UPDATE:
Could also be that you didn't set the width and height of the button correct.
The way you have it now it's actually not perfectly in the middle. As you can also see in your screenshots, the left/top of the button has a white edge, the right/bottom doesn't.
If I change it to width:186px; and height:31px;, it is perfect.
(With any luck that also fixes your problem in Win8.1/IE10, or at least makes it less obvious)
Related
[EDIT]: This question has been solved - see the comments
I’ve modified the Slick arrows within my main style.css file. I’ve added:
.slick-prev:before,
.slick-next:before {
color: gray;
font-size: 80px;
}
This works as desired in Chrome. The arrows become larger and their color is changed from white to grey. In Firefox and Safari though, the navigation and hover effects of the arrows break. If I delete this CSS rule, the arrows work properly in all browsers (but they are tiny and white).
In Firefox: hover state ceases to work (arrows are supposed to become more opaque on hover). The navigation only applies to the original 20px font-size, so only the top corner of the arrow is clickable. In Safari: hover state is even more broken (most of the arrow disappears on hover, only the original 20px size at the top corner remains), and the navigation randomly works properly at times and (mostly) doesn’t work at others.
I’ve tried modifying my CSS rule to include:
.slick-prev:before,
.slick-next:before {
color: gray;
font-size: 80px;
-webkit-font-size: 80px;
-moz-font-size: 80px;
}
But this does not fix the problem. I’ve also tried changing these CSS values directly in the slick-theme.css file (which you’re not really supposed to do) and this also did not work.
Here’s the website if you want to test for yourself: https://kylevassella.github.io/JC-Realty
My problem is an Internet Explorer issue. I have an element, basically just a block, with the css:
md-card{
min-width: 80%;
background-color: #fff;
}
And this element is full of data elements consisting of an icon and text.
Each one is either a file or folder, and clicking a folder just navigates to that folder's contents.
These elements are using data binding and are dynamically updated when you click a folder (so it removes the current contents and replaces the data with the opened folders new contents) and for some reason this causes a problem in IE
The md-card element despite having min-width set to 80% will sometimes squash down to like an inch big on the screen when a folder is opened. Sometimes this happens only for an instant, and it resizes, and sometimes it sticks. But resizing the page will cause it to resize back to the intentded width.
I was thinking it was some weird interaction between angularjs and IE but I'm wondering if this is an issue anyone has encountered or and ideas on why this is happening.
Edit: On further inspection it seems to involve the min-width: 80% attribute.
Changing it to min-width: 600pxeliminates the problem.
The problem with Internet Explorer is always bugging but I figured out the solution please add this line to md-card CSS sheet . As you mentioned that it is basically a block , consider this .
md-card{
display: block ; /*Add this line*/
min-width: 80%;
background-color: #fff;
}
Internet Explorer is not as intelligent as chrome or Firefox , so the default is always display:inline ;
Therefore the layout problem occurs .
It seems I am having a strange issue in Chrome, with "width: 0px".
I am setting the width to 0, in order to partially hide a link. On mouseover I am displaying the link, with a simple animation.
While Firefox and Opera behave nicely, in Chrome I see the link's text displayed, even though the width is set to 0. (in IE and Safari I cannot test right now)
For your convenience, I added the code in a fiddle, here: http://jsfiddle.net/mihaidoru/yNzSH/
QUESTION: How can I make Chrome display the same thing as Firefox, CSS only, if possible.
NOTE: the menu should respect the CSS: "position: fixed; right: 0px".
Any help will be greatly appreciated.
Thank you.
Set the links to be overflow: hidden.
I have set the width to 1px instead of 0px. It makes it so that the green background appears and when you hover over it it expands as expected. I also changed it to 1px in your jQuery.
updated fiddle
You can use the css overflow property
overflow: hidden;
overflow: hidden does not work for me, try display:none; javascript reads ok.
I'm attempting to animate the slide-out of a menu with script. To do this, I need to animate the marginTop property of an element and increment it from -30px to 0px.
However, in IE8, the animation simply does nothing. I've traced this down to the fact that setting marginTop in script seems to have no effect. In Chrome and Firefox, this works fine.
Here's an example that will work with Chrome/Firefox, but not IE:
http://jsfiddle.net/rm58T/2/
Is this an IE bug, and if so, are there any workarounds for this behavior? Thanks!
Update:
Here's some screen shots of the bug.
In Chrome, my Fiddle looks like this (You can see the "Name of new menu" text, since we changed the margin with script)
In IE8/Vista, it looks like this. I can confirm in Developer Tools that topMargin is actually 0px as expected, however the elements were not re-drawn:
Another Update:
This bug repros (at least for me) on IE8 running on Windows 7, and also IE8 running on Windows 2008 Server. It does NOT repro for me on IE7 running on WinXP. I do not have any IE9 machines to test it.
Yet Another Update:
I found one potential work-around. If I set p.newmenu to position: absolute; instead of position: relative; then it works. However, in my case I'm hosting this entire thing in a popup menu and need this control to push out the bottom of the modal dialog, so absolutely positioning it is not an option. However, perhaps this knowledge can help in finding a workable solution. An example of this work around can be found here.
Would You Believe Another Update?:
I did find a workaround for now. If I use top: -30px; instead of a negative top margin, then everything works. top behaves a bit differently than a margin, though, and makes the UI not look quite as nice. In particular, when you use top: -30px, then you'll have 30px of whitespace under your element since relative positioning doesn't affect other page flow.
I'd greatly like to figure out why I can't use a negative top margin on IE like I can with other browsers, so I'm still hoping someone can provide an answer that will provide all the benefits of a negative top margin but also work with IE8.
The trigger for this behaviour is how IE8 handles the fieldset element.
You can work around it by setting the display for fieldset to inline (or inline-block).
div.modal.addmenu fieldset {
display: inline;
}
This isn't exactly a bug; it is just based on the fact that (to keep up in performance comparisons) IE was built since version 5.5 with a minimized preset of static definitions;
That means: Instead of spending any Element the whole and correct definition (depending on which god of specifications you hail out for ...) for the type it is, IE is using less.
TODO:
Give back what should be credited for acting as a top-model paragraph relatively positioned; DISPLAY it accordingly to its talents; any super-paragraph should do the catwalk inline, even if it is a block-head, you might try using sugar and whiplashes to remember your nasty P of its origin as a inline-block. It's a frenzy P, give some respect to its talents…
DOJO:
In fact, you as a rune-reading script-javalchemist be the one who has to have to take control over the brew the browser serves. Or it makes boom, silently ...
GODO:
Necessary things to do if you want to use negative-margins in browsers which don't play legally:
remember the elements you want to use of their display's origin; don't believe in browser-vendors that they would have done that already for you
IF you are just out for IE 7+ use display:inline-block;
IF you want to get negative-margins to effect on all notable browsers, but can forget about NS4, then use display:inline; or display:block;
Do not forget to build the foundation for your negative-margins: set position:relative;
MOJO:
If IE-Betas and older ones like 5.5 or 6 are in your point of interest, you have to ensure that your relative-positioned negative-margin paragraph has values for width and height; Depending on what you are trying to achieve, sometimes a height:auto; helps out.
I am trying to override the default page setup margins for my users. The document that I need them to print needs to have the margins gone. After TONS of looking, I found the following, and IT WORKS IN GOOGLE CHROME:
#page{
margin-left: 5px;
margin-right: 5px;
margin-top: 5px;
margin-bottom: 5px;
}
When I print this to PDF in Chrome, it prints a document with virtually no margins around the side. However, when I do the exact same thing in FF4 and IE9, it prints a document with large default margins.
Any ideas on how to make this work for IE9 and FF too? Supposedly the #page CSS stuff was part of the CSS2.1 spec, which all browsers IE8 and later support. So, I am not sure why it isn't working for these pieces, and why Chrome is the only browser that has it.
dont use the px
The page context has no notion of fonts, so 'em' and 'ex' units are not allowed. Percentage values on the margin properties are relative to the dimensions of the page box; for left and right margins, they refer to the width of the page box while for top and bottom margins, they refer to the height of the page box. All other units associated with the respective CSS 2.1 properties are allowed.
Specs