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.
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.
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.
I had some problems with vertical spacing in Firefox and IE for an embarrassingly long time.
I am using a * selector in my css to apply margins to everything within a certain container element. Works fine in Chrome, however in FF and IE I was getting mysterious extra padding seemingly coming from nowhere, as you can observe here: http://jsfiddle.net/XrVXF/3/.
It turns out I had two separate problems. One is that non-Chrome browsers will select elements with the * selector and apply the margins and the margins show up in the browser! even though the element is invisible to things like Firebug. Should this be considered a bug? You may be asking what business is a link element doing inside the body tag. Well I could probably avoid it but it is the easiest way to do some things on my site. This page says that the * selector should only apply to block level elements in HTML5, which I am using, so in that sense it seems to me that Firefox at least is bugging out, and IE too if they are supposed to have proper HTML5 support yet. Now that I know this I can work around it but maybe there are other elements I should worry about too? (Doesn't seem to apply to script or style tags.) Would I be better off applying margins to a large list of html elements instead of *?
The other weird thing, which you can observe in the fiddle I linked is that the clearfix on the bottom (which is not necessary in the example, but is on my site) also picks up the margins and applies them in FF and IE but not in Chrome. Which is the 'right' behaviour? Strangely, I noticed that turning off overflow:hidden, prevents the clearfix from taking up space, and doesn't seem to have any detrimental effect on my site. What is overflow set to hidden for?
Correction: Oops, I was using .clear when I meant to be using .clearfix (which appends content after your floated stuff), which seems to work fine and doesn't have margin issues.
Should this be considered a bug?
Considering you're applying styles to elements that are in places that they shouldn't be in the first place (link in body???), this is anybody's guess. The likely reason why they don't show up in Firebug is because Firebug isn't expecting them to be there.
In all seriousness, my best guess as to what's going on in your fiddle is:
Chrome has a UA style for link elements to display: none. I imagine it does the same for any other elements that belong in the head element and not body.
Other browsers have no default display style for link elements, instead relying on head to have display: none to hide everything that belongs in the head element as well. So when you place a link within body, it shows up with the margins because it's showing up with the initial value of display: inline.
FWIW, if you give it a style of display: block, its margins will collapse and it'll have the same apparent effect as if it had display: none as in Chrome.
Again, this is based on invalid markup in your fiddle, so I can't say which browser, if any, is right or wrong since all the spec says is that the page head should not be rendered. Also, cue arguments/debates on whether this is a reason not to use the * selector, or a reason not to write invalid HTML, or both...
In all major browsers: as the question states, a parent <div> container (whose height is not set) over-sizes its height to fit a child <img> element (for instance, a 300-pixel tall image that is the only thing inside the div). The over-sizing is usually about 3 to 5 pixels, and appears at first as img margin-bottom or div padding-bottom might look.
However, using absolute positioning, it is clearly demonstrated that the bottom of the div is below the bottom of the imgby a few pixels. It might not ruin a website's design, but it is a hurdle to overcome in certain situations. I have made a fairly detailed fiddle demonstrating this issue here.
Why is this standard practice in web browsers?
Is this meant to compensate for something? It seems unnecessary.
Is this a bug, or a soon-to-be antiquated feature?
EDIT: Thanks to the answerers/commentators below, I know the reason is that an <img> is treated by default as CSS
display:inline which preserves whitespace around the element.
Changing it to display:block completely fixes the problem by
eliminating whitespace around the element.
Notes: This over-sizing can be averted by giving the image child element a CSS property of float:left or float:right, etc., but this is a workaround, and as such is not the answer to the question. One reason this can be problematic is if you already have other float elements layered in front of the div child image (float overlap not allowed Firefox, Opera, IE. float overlapping only seems allowed in Chrome and Safari using CSS position settings). Thanks!
Add display:block to your image. I think that will fix the problem.
I'm using an image which must auto-scale inside a div whose height is defined by the root div.
The scaling is fine in all major browsers, using height: 100% on the image itself.
But it seems that on some browsers, the image container doesn't adapt its width accordingly to its content (the image).
Check by yourself the live demo.
This demo uses an image container with a blue background.
Expected behavior: This background shouldn't display since the container width and height should be the same as its content (the image).
Actual behavior:
On Chrome 11, Safari 5 and IE9, the behavior is as expected.
(source: imgh.us)
On Firefox 3.6/4.0 and Opera 11, the behavior is not as expected: the blue background is displayed.
(source: imgh.us)
What is the root cause of this strong difference between major browsers?
In the case of Firefox, this looks like a bug. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=653739
You can work around by removing the overflow:hidden unless you actually need it.
Those later browsers interpret inline-block more strictly (correctly).
That is, your element is positioned inline (like a span), but the element's contents are laid out as if the element were a block.