I asked this question about sub tag:
Using <sub> tag and preserve line-height
So now i use position: relative; and smaller font to "emulate" behaviour of subscript. But I have found that this solution is not pixel perfect. <div> with this emulated sub tag can have bigger height then <div> without this emulated sub tags, even when texts in each line line of divs are exactly the same. I observed this behaviour in Chrome and Firefox, here is the problem shown on live code:
http://jsfiddle.net/FRkQ6/
On my Chrome browser in Mac the output is:
Height of first div is: 163
Height of first div is: 162
This live code works on chrome on mac where both divs have the same lines with same text. On Firefox this demo does not work, because texts in lines are differently rendered. But the problem is similar to Chrome.
Can somebody explain me this behaviour? Is it some bug in browsers or intended behaviour? Can I fix that somehow with CSS (if i subtract height of top and bottom border, which is 2, height should be divisible by line-height, which is 20 in my demo, so I should never get height of 163)?
Even though the span is position:relative the browser is still (wrongly) considering its line height. Adding a line height of zero fixes it...
line-height: 0;
jsFiddle demo
Related
Having this setup:
<div>
<label>...</label><br />
<!-- repeat several times -->
</div>
div {
display:inline-block;
overflow:auto;
max-height:3em; /* short enough to cause overflow */
/* or, in Chrome, this works too: */
padding:1ex;
}
will cause Chrome and Firefox to produce horizontal scrollbar:
JSFiddle
That Opera is Opera Presto, not Opera Blink. Too bad it's abandoned.
Anyway, why would this happen, and how would I get rid of the horizontal scrollbar if I need both max-height (thus auto overflow) and padding?
P.S. I'm using an XP machine (company restriction), if that matters.
P.S.#2 Further testing shows that disabling margin on <label>s puts out the horizontal scrollbar in Firefox, but the content will be crudely cut down to 3 characters length (the shortest label)cut down about 2 characters (the width of scrollbar).
Update #2:
In case people feel ambiguous:
Why would the container <div> shrink to the shortest length of its child (in this case, 3 chars) expand no more than the width of content in Chrome and Firefox, excluding scrollbar, letting long childs overflow?
There's no length info anywhere, so what's the logic here? I purposely added "Zero" so the first child is not the shortest one, but still got the same result.
Opera Presto seems to work as I expected, but that does not seem to be the de facto standard.
And how could I ask <div> to expand to as wide as it should, while still keeping a max-height and auto scroll?
Update #1:
The direct cause of scrollbar is of course content horizontally overflowed, so if I brutally apply overflow-x:hidden to <div>, the result will simply be this:
Update #3:
Thanks to #SergiyT., this turns out to be how Chrome and Firefox handles scrollbar, not the shortest child:
JSFiddle
I'm not sure if this is "right" (content has been overflow-ed before the longest child appear), but this seems like a dead end.
Perhaps it is how browsers work with scrollbars. It looks like opera (and maybe IE also) consider width/height without scrollbars but Firefox and Chrome take scrollbars into account. On your screenshot div width in Opera is bigger than in Firefox and Chrome.
This might help you
div.listbox {
overflow-x: hidden;
}
Try
div.listbox{
...
vertical-align: bottom;
}
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 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.
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.
For example, if I make a block of four images that are absolutely positioned with 50% width and 50% height, the result in Internet Explorer looks like this:
http://img716.imageshack.us/img716/8376/96774641.png
The images are placed right next to each-other, as would be expected.
But the same code in Chrome produces this:
http://img560.imageshack.us/img560/7976/chrome.png
The images are shrunken slightely to make room for the spacing in-between.
My styles already include:
border-style: none;
border-width: 0;
padding: 0;
margin: 0;
... so why is Chrome spacing my images apart from each-other, and how can I fix it without altering the display for other browsers that render correctly in the first place?
EDIT: <link removed>
Be aware that the actual page is much more complicated, with over 1,000 <img> elements.
It will load slowly in any browser that is not hardware accelerated.
I have confirmed that FireFox renders it identically to IE8, with the images next to each-other as they should be.
This could be a rounding issue: A width of 50% may well end up as 223.5px for example.
Seeing as you're using images with a fixed size, why not specify the positions in pixels as well?
Are you using a CSS reset? Browser default styles can cause irritating problems like paragraphs with differnt top margin heights or other quirks of layout. This particular case may not be fixed with a CSS reset, but it would eliminate the possibility.
Sadly, the CSS3 option to set a background image scale is not yet available in any reliable way, or you could set the image as a repeating background image scaled to 50%, which of course would have no gaps. That won't be an optin for quite some time, most likely.
Have you tried using the Inspector (right-click on the image, select Inspect element) to trace where that spacing is coming from?