I have the following fiddle: http://jsfiddle.net/VyXWp/1/
#wizard li {
display: inline;
min-width:100px;
float:left;
}
The second divs width should be calculated based on the text width.
In IE7 and IE8 it is messed up.
For some reason the 'a' element gets the width of the span2 div instead of the text.
Edit:
After more digging i noticed that the problem was not width but float. If i set no width, the float doesn't work. It doesn't limit the width to that of the text.
Edit 2:
Couldn't find any pure css solution that worked and kept the width auto, so in the end i calculate the width with javascript.
The CSS width property takes a fixed parameter when passing precise values, but in terms of percentage, if you set the width of an element to 50% or 100% it will take the percentage of the width its parent element is.
so if you have a div with a width of 500px and p tag inside with a width at 50% the p tag would be 250px, vice versa with a 100%.
i short my suggestion is to make sure that the parent element either has a fixed width or percentage
you might also find this helpful
http://learnlayout.com/percent.html
Couldn't find any pure css solution that worked and kept the width auto, so in the end i calculate the width with javascript for old browsers.
Related
I'm having a problem on a website with Safari 7 (on OSX).
The website address is:
<Edit: Address not valid anymore. Sorry.>
If you click on vertical newsletter button, on the right edge of the content box, an overlay will pop-up.
This overlay looks good on most browser, but there is a problem with safari.
The overlay content is an absolutely positioned box of fixed width. It contains a div with the class "bg", which is a div with CSS position set to fixed and CSS top, right, bottom left set to 0.
The desired (and normally obtained) effect, is that this bg box sizes up to the width and height of the viewport. In safari, it just behaves as if it had it's position set to "absolute" - it just sizes up to the width and height of the container div.
Is this a known issue with Safari? Is there a bug filed? An update?
I could probably fix that by rewriting small parts of the HTML, CSS and JavaScript (if someone has an easier solution, you're welcome to share it!) but I'd like to understand what's happening at first.
I'm not sure what's going on with that positioning thing, but here was my approach to get the same result across the browsers:
#overlays .overlay { /* line 1081 */
...
width: 100%;
height:100%;
...
}
#overlays .overlay .content.text { /* line 1185 */
...
margin:0 auto;
...
}
You could use Z-index but Z-index is not reliable with position:fixed, as shown in this fiddle: http://jsfiddle.net/mZMkE/2/ use translateZ transformation instead.
transform:translateZ(1px);
on your page elements.
EDIT: In your code, Add this css:
.bla, .projects, .contact {
-webkit-transform:translateZ(1px);
-moz-transform:translateZ(1px);
-o-transform:translateZ(1px);
transform:translateZ(1px);
}
and then remove z-index refs from those elements and .intro.
Also You can try in other browsers as well
The problems can be seen here: http://www.skicoloradorentals.com/secondary.html
1) the gap below the contentBorderImg
2) contentBorderImg reduces to 69 pixel height instead of 87 (18 px diff = same as gap)
3) the content div doesn't sit over the contentBorderImg even though I assigned a high z-index to it
contentBorder - this is the wrapper/border for the content area with a 1-px border
contentBorderImg - this is the rounded corner image which is displayed over the top part of the wrapper
.content - actual content div that I want to reside over the contentBorderImg
I was able to make the same concept work in the left column. I tried duplicating that code to no avail. I appreciate your help immensely.
Try giving contentBorderImg's
Z-index = -1;
and then for #contentBorder use
border-radius:9px 9px 0px 0px;
I have used border-radius to mold the border as per the rounded corner image.
Back story: I have an SVG canvas with some polylines on it. I also have some HTML <span> and <textarea> elements that need to be positioned precisely in relation to those polylines.
I started by putting the HTML elements in the SVG in <foreignElement> tags, but I had a problem there because IE doesn't see them at all and Firefox doesn't see the <textarea>s. So I took them out of the SVG and now every browser sees them.
So far so good. Now the only way I know to make sure they position correctly with the polylines is to give both the HTML elements and the SVG canvas absolute positions with CSS.
Here's my problem. Above all these elements is a header div. I want the whole SVG business to sit at a reasonable distance below the header. Say 15px. But since the SVG is absolutely positioned, I need to know the height of that header div to get the SVG and related HTML elements into the right place.
I've tried jQuery's .height() method and some related methods. The problem with all of them is that Firefox and Chrome give two different results. I know this doesn't reflect a real pixel height difference between the two, because I can see visually that the header is slightly taller in FF, yet FF gives a smaller height reading.
How can I get a browser-consistent height reading for my header div? Or at least one that I can use to absolutely position other elements at the same distance below it in every browser.
You could try with this function
function getHeight() {
return Math.min(
Math.min(document.body.scrollHeight, document.documentElement.scrollHeight),
Math.min(document.body.offsetHeight, document.documentElement.offsetHeight),
Math.min(document.body.clientHeight, document.documentElement.clientHeight)
);
}
or simply with document.documentElement.clientHeight, which usually does the trick for me in all the browsers I use for testing (Chrome, Firefox, Safari and Opera)
[edit] The function above returns the width and height of the body, in order to use it for any div, use this one
function getHeight(div) {
return Math.min(div.scrollHeight, div.offsetHeight, div.clientHeight);
}
You can use it like this
var myDiv = document.getElementById('myDivId');
console.log('the height is ' + getHeight(myDiv));
[edit2]Keep in mind that the divs might actually have a different size depending on the browser.
Let's say this is google chrome and the green bar at top is the navigation bar, with a height of 75px. You have it at 100%, filling up your screen, who has 1000px height, and you place an 100 pixels div to the top and also stick an 100px div to the bottom of the screen (with blue). The purple div between them will have an 725px height.
And this below is firefox. It's placed on the same 1000px screen, also at 100%, but its navigation bar has 100px height. With the same 100px blue divs to the top and the bottom, the purple div will have a height of 700px here, different from chrome.
Of course, this is a very, very simple example and I doubt this is your case. But you might have a similar problem with div placements and it's something you should try to check.
I noticed a strange behavior with the default font size option (I'm NOT speaking about the minimum font size under the advanced tab) under Firefox :
go to this page http://fr-region.xb83studio.ch/2012/lachen/ and put a default font size of 44px or higher. Can somebody explain why the second list drops under the first one ?
The texts inside have a font size specified, hence they aren't modified by the default font size feature.
At first the problem occurred with a default font size of 17 pixels and higher. I reduced the width by 3px and it now works up to 40px. But I still don't understand why this problem arises. I would really appreciate an explanation.
BTW, I'm running Firefox 12.0 under Windows 7 Professional SP1
Thanks for your ideas
René
You have two inline-block elements with width 207px and left-margin 32px each. They're in a container with width 488px (573px width div containing a section with auto width, a 55px left margin, and a 30px right margin). In your markup, there is whitespace between the </ul> for the first inline-block and the <ul> for the second one, so in the rendering there is a space between them, just like between any two characters separated by whitespace. The width of that space is the width of a space character in the container's font.
So the second list will wrap under the first one once 488px-2*(207px+32px) = 10px is smaller than the width of a space character in the container's font.
If you earlier had your inline-blocks at 210px width, then the wrapping would happen once the width of a space is more than 6px; somewhere around a 17px font size sounds about right for that for typical variable-width Western fonts.
I just discovered strange behaviour of Firefox.
If I have a table cell of 100px height, and add 20px padding to it - it's total height should become 140px.
All browsers act correctly, Firefox 8.0 ignores the padding:
http://jsfiddle.net/8wDde/
Anyone knowing a fix?
It seems the best cross browser solution may be to set the full height of the table row equal to height and padding of the cell:
tr {height: 140px;}
See: http://jsfiddle.net/8wDde/19/
that is a strange behave. add display:block; can fix the problem. tested in FF8.01 see:
http://jsfiddle.net/8wDde/1/
But I also do not know why?
I searched in https://developer.mozilla.org/en-US/search?q=table+padding, but did not find anything. May be you can also try to search in there.
UPDATE:
http://jsfiddle.net/8wDde/7/
add overflow:hidden to avoid the td change line.
I couldn't find any information about this on Google, so one way to fix it for Firefox would be to use a CSS hack.
#-moz-document url-prefix() {
td{
height:140px !important;
}
}
Obviously, if the height was 200px, then you'd change that to 240px to account for the missing 20px on top and on bottom.
That targets all Firefox versions, I'm not sure if theres a FF8 specific css hack.
You can see this demo here: http://jsfiddle.net/charlescarver/8wDde/2/
Edit: I like Giberno's answer more
This is a fuller description of a couple of comments I made on another question, hopefully a little bit clearer. Note that Opera has the same behaviour as Firefox.
In the diagram above, the total cell area is the dark box, and the text My Text is the content of the td, and it is that that defines the Cell Box (C).
Now, the CSS 2.1 spec says:
The height of a 'table-row' element's box is calculated once the user
agent has all the cells in the row available: it is the maximum of the
row's computed 'height', the computed 'height' of each cell in the
row, and the minimum height (MIN) required by the cells. A 'height'
value of 'auto' for a 'table-row' means the row height used for layout
is MIN. MIN depends on cell box heights and cell box alignment (much
like the calculation of a line box height). ...
In CSS 2.1, the height of a cell box is the minimum height required by
the content. The table cell's 'height' property can influence the
height of the row (see above), but it does not increase the height of
the cell box.
So td { height:100px; } affects the Row Height (R) (it will be at least 100px high) but does not effect the Cell Box (C).
On the other hand, td { padding:20px; } applies to the Cell Box (C), so if the height of (C) + Top Padding + Bottom Padding is less than 100px, the row height is not affected and is still 100px.
If (C) + Top Padding + Bottom Padding is greater that 100px, the row height will expand to accommodate the full height of (C) + Top Padding + Bottom Padding.
Then td { background-color:blue } applies to the full row height (R) and cell width.
You can see this in action at http://jsfiddle.net/Ez7xz/
The final confusing factor is the value of the computed height of the td in Firebug. What seems to be happening here is that it is assuming that the height is the result of content-box box sizing, and reporting the value of R less the top and bottom padding. While this seems odd, it's not obvious what other value it could reasonably report.