This little fiddle shows the problem I'm having.
The login form on the right looks fine under firefox (And even IE6) but when viewed in IE7+ or chrome/chromium there is a size difference.
This isn't an actual size difference, but an illusion created by some of the inputs becoming positioned lower than the others, and the overflow on the div cutting them off.
I thought it could be some invisible value such as firefoxes dotted lines but setting outline: none doesn't work either.
I've been debugging this all day and I don't know why it's not working.
Edit: Screenshot
Replace height with line-height.
http://jsfiddle.net/gnxRG/1/
Apparently vertical-align applies to the object relative to it's parent, not the objects children relative to the object. Setting vertical-align on the inputs to top fixes the problem (But I still don't know what caused it in the first place, odd)
http://jsfiddle.net/gnxRG/2/
Related
I'm running into an issue in desktop Safari (haven't checked mobile) where the top part of an input element's content is being cut off. There is no padding on the parent element and the styles render correctly in other browsers.
I believe the issue is due to a shadow div element that Safari has added that is the direct child of the input, as the calculated style for this shadow div has font-size 12px, while the actual size of the font specified on the input is 16px. When I type, the cursor has height 12px.
I'm not able to target the shadow div to overwrite the font-size. Any styles I try to apply are ignored. Any idea what this shadow element uses to calculate its styles, or how I can target would be greatly appreciated. Thanks!!
UPDATE: Happily, a simple solution. Applying a line-height to the input element solved the issue.
Interestingly, on both my branch with this bug and another branch without it, the value returned by getComputedStyle() for lineHeight was the same: 'normal'. I suppose it helps to be explicit with CSS. Hope this helps someone else.
If you were to look at the following website in Chrome, you would see the printers in 2 rows. Which is how it is supposed to be. But in FireFox and Internet Explorer the 4th product is aligned on the right by itself.
I have tried everything I can think of, and scoured the web. I would really welcome any help anybody can give me regarding this issue.
http://www.thewideformatgroup.co.uk/Products/general-office-use
Change float: left to display: inline-block on the items (.shop-main li, to be exact).
If you float items to do this, then the height of the items needs to be exactly the same. In this case, the items are rendered in such a fashion that the 3rd item is slightly less high than the second. That is causing the fourth item to float next to the second as well.
If a bit exaggerated, it looks like this. Notice how 3 is slightly less high, causing 4 to be stuck behind 2 as well.
This might be caused by a weird scaling of the product image, for instance, or by any other rounding difference. Also, it might look good at first, but change as soon as a user starts zooming in or out, or messes with their font settings.
By using inline-block, you basically create a long text-line of items, that will wrap as soon as the line is full. It is a better approach when you want a wrapping list of items like this, because you won't at all be affected by the rounding problems I mentioned above.
Now, you might be tempted to solve this rounding issue so every block is the same size. And you might do that as well, because it might look a bit weird when the red line that appears on hover is shifted a pixel or so. But start by using inline-block, so you prevent incorrect wrapping, so even if some unpredictable rounding errors occur, they surface only in detail and won't mess up your entire page.
Have you tried to make the elements float or give them a relative positioning? The way i'm seeing it is that they inherit their positions from the parent div but on ie and firefox it's rendered differently.
I've had this problem and the solution for me was to make everything float left and give it margins and clearing as needed, the end-result was that it had a certain margin from the top so the elements always remained at a certain distance from the top and each other while maintaining their position
Try adding height to the .inner class:
.shop-product-small .inner {
border-bottom: 3px solid #FFFFFF;
height: 140px;
}
The issue I'm having can be found here:
http://jsfiddle.net/boblauer/5uVrK/
If you look at it in Chrome, you'll notice that when you scroll to the right, it stops immediately at the right edge of the last green box. However, in FF and IE (haven't tried others), it will correctly scroll a bit past the last green box.
Since .lane-container has a width of 2000px and the boxes should take up a width of 1700px, there should be 300px extra to the right of the last box, but in Chrome there is not.
Any ideas on why Chrome behaves differently than the others, and how I can work around it?
Setting the display to inline-block instead of float: left fixed the issue for me. Floating block level elements takes them out of the dom flow. That doesn't really explain why this doesn't work, but this is a workaround. I always prefer inline-block over floating left.
Edit
After some more jsfiddling, it seems chrome isn't showing the container div's full width because it's empty. As soon as you add a border around lane-container it works as expected, although, since you're floating the inner divs left, they aren't in the dom float and lane-container appears to have a height of 0.
If you look at this code: http://jsfiddle.net/b3KaM/2/
in IE7 the <a> tags do not stretch to their parent <li> width even if display: block; is set. You can see the difference with the background color set to red on the list items and yellow on the links.
it obviously work fine in FF/Chrome & friends.
EDIT:
the complication here is that I cannot set a fixed width - the link text should stay on one line and the whole list should expand as needed.
I'm aware that this as been asked before and I've found a few questions on SO but I could not find a valid solution to this issue - any ideas anyone?
If not - is it safe to say that is not possible to achieve the same result on IE7 as on other browsers, i.e. it's an Internet Explorer bug with no workaround?
This problem is caused by a rendering phenomenon in IE7 and lower known as hasLayout.
To fix the problem, you must simply prevent your a elements from "gaining layout".
Unfortunately, there's massive list of stuff that causes an element to "gain layout".
Your a elements currently have overflow: hidden and min-height set. If you remove those properties, it will work in IE7.
With block you have to give the width also for the element.For example:- http://jsfiddle.net/b3KaM/8/
I would like to understand CSS more and now I have an example that renders differently in two browsers and in a program called "explorer". Here is the link to the example page that I tried to clean from any disturbing details: http://csaladterapia.hu/example.html
In the latest Firefox version the image is placed inside the fieldset because it is float:right and the other elements are clear:none. In Chrome and IE the image is placed above the fieldset.
Could you help me understanding the difference?
The interpretation of Firefox is wrong, and even very strange. Floating an element should never place the element on top of other elements - it just takes them out of the document flow, puts them to the left/right on the current line. If the element following the float is not too wide, and has no 'clear' property, it will be placed on the same line.
In your example the following element is the div, which defaults to 100% width, so it can't be placed on the same line.
What Firefox is doing is very strange - even clear:left on the following element has no effect.
Reference:
http://coding.smashingmagazine.com/2007/05/01/css-float-theory-things-you-should-know/
This is a strange one, and i'm not sure what the correct behavior is here. It is due to the width of the fieldset being 95%. Removing this width attribute shows the same behavior in Firefox and Chrome.
If you want the image to appear in the fieldset then move the image to be the first element after the legend, this way you should see consistent behavior in all browsers.
Firefox tries to honor the width of this whilst maintaining the float but it seems Chrome wants to move the fieldset onto a new line due to being block and 95% width.
In this case you can change the mark-up as mentioned.