Forum Moderators: not2easy
So I have a DIV that contains a table that is X wide. I simply want the DIV around the table with a 20px padding and a border. If the DIV is much bigger than the table, the table is centered horizontally in the div using margin auto. I have this working fine with one huge exception. When you shrink the window, the contents of the table simply poke outside the DIV! The DIV keeps shrinking with the window, but the table can't shrink because of its contents!
I do not want the overflow hidden. I do not want it "visible" outside the DIV. I want the DIV to stop shrinking below the width of the content and simply creat a horizontal scroll bar. Why is this so difficult.
The page I am currently looking at (typing this in) is a similar example. There is a form in the middle that simply cannot shrink because of the size of the input elements and its container is width=100%. However, when the window shrinks to much it simply creates a horizontal scrollbar. In CSS, it would stubbornly stick to 100% of the window and the contents would poke out of one side, which is STUPID!
My primary complaint about CSS is that every website you look at, including [csszengarden.com...] looks like CRAP when you shrink it or otherwise has content that doesn't fit. Why doesn't it just stop shrinking and create scroll bars if the contents don't fit!
The closest solution I could find is adding "min-width", but in my case I do not know the width of the content ahead of time (especially across the entire site).
Finally, this is unrelated, but further complaint about CSS. It seems that my layout possibilities are severely limited in creating "alternate" stylesheets because CSS is dependent on the order and nesting of the HTML. The only way I can think fixing this is if you had a way to position something relative to another item(I want this item below this item--regardless of where it is in the HTML). This is possible using javascript...but I haven't found something like this in CSS.
I can assure you I have dealt with a LOT of CSS issues myself and I understand your frustration! However it is always best to post at least a snippet of both the (x)html and css code and then explain what you are trying to achieve from there.
Regardless don't give up! I'm going to give this a crack. Since you are using ASP I'm assuming you're testing this in IE? (George Carlin) Stop that! Get Firefox or Opera, test with them first and THEN use IE conditional comments to fix IE's shortcomings.
Also most people don't resize the browser to see what happens to a page...when they resize their browser. However if it's really a big issue you can use this snippet of code...
<!--
onResize="window.location=window.location;"
//-->
I use dynamic JS generated overflow DIVs to emulate frame scrolling and if you resize my site it correctly renders the page as what I think you're having difficulties with.
Oh daily show is on! Reply and let me know if this alone works out. If not post some code and use [ and ] around quote and /quote to code the code please!
John
<html>
<head>
<title>Reports</title>
<style type="text/css">
<!--
body {background: #ffeeee; padding: 30px;}
table {background: #eeeeee; border: 1px solid red; margin: 0 auto;}
td {border: 1px solid black;}
div {border: 2px solid green; padding: 50px; }
-->
</style>
</head><body>
<div>
<table width="400">
<tr><td>Content 1</td></tr>
<tr><td>Content 2</td></tr>
</table>
</div>
</body>
</html>
Why is this so difficult.
It's actually not. It's just that this particular effect is not automatic, i.e., it's not the default behavior of block level elements in a standards compliant environment.
Some background: As a block level element, the width of a div that is not given an explicit width is calculated by first applying margin, padding and borders, then assigning all the remaining width in the container to the content width of the element. It makes sense, then, that as the viewport shrinks (causing the available space in the container to shrink, as well) the div gets smaller. Eventually, though, shrinking the browser will make the div too small to contain a piece of fixed-width content.
FF, which adheres more closely to the specs than any other browser, allows that table to simply spill out of the div without having any effect on the div's width. This is exactly what is supposed to happen. The browser is simply applying the code, rather than second guessing the code and trying to correct what it perceives (right or wrong) as what you actually wanted (This is what IE does by automatically enclosing elements in their containers.)
Since this is the default behavior, you need to explicitly tell the browser that you do not want the div's width calculated in this way. One way to do this is to assign an explicit width. FF will then respect that width no matter what else happens.
In your case, however, you want the width to be defined by the width of the content. There are two ways to do this: one very stable but slightly more complex and requiring prior knowledge of the content's width; the other simple to apply but (possibly) less stable.
Option One: Calculate the smallest you would like the div to get (content width plus padding, in your example, equals 500px), and apply that as a min-width on the div. The browser will then allow the div to be larger than this when applicable, but will not let the div shrnk any smaller than 500px. Note that IE does not support min-width, but instead treats regular width as if it were the min-width property, so the code required involves setting a width for IE, and then resetting that width to auto and applying min-width for compliant browsers...
div{
width:400px;
border: 2px solid green;
padding: 50px;
}
body>div{
width:auto;
min-width:400px;
}
Replace "body" in the above with the parent element of the div. That code uses the child selector, which IE does not support (noticing a trend?) to deliver FF and other compliant browsers their yummy treats.
Option Two: Float the div. That's it. By floating an element but not giving it an explicit width, you trigger a "shrinkwrapping" behavior which will cause the floats' width to be content defined. However, note two things. One, the specs specifically indicate that floats should have explicit widths, so there may be hidden dangers. And two, you really have to be using content with a fixed width, such as a fixed-width table or an image, otherwise the browser may not be sure what to base the width on and you can get inconsistent results....
div{
float:left;
border: 2px solid green;
padding: 50px;
}
cEM
As for min-width--is impossible to calculate ahead of time and the site needs to run without Javascript. I think I could live with a min-width of 800px or so(which should cover 90% of the cases and still allow small monitors to view the page). However I knew that min-width wasn't supported by IE. Since you say that IE automatically shrink wraps, then perhaps min-width is back on the table.
The floating can make things tricky because then it gets taken out of the flow. Since the item that we are talking about is the "main content" floating would cause the footer to go behind the content instead of being pushed down. Maybe "clearing" the floated main content div will cause the footer to get pushed down again...but I was mainly going against this solution because I read online that floats require a width (just like you said). In addition, I still have to worry about the sidebars and the two caveats you mentioned. But I will give this suggestion another shot also.
Hopefully one of these solutions will work for most modern browsers and platforms.
<RANT>It still goes to show how difficult the shrink wrapping is (atleast in Mozilla). Both float and min-width are just work arounds taking advantage of pecularities in each browser. There doesn't appear to be any specification to handle shrink wrapping and there should be. If you ask me, I think the CSS specification is rather silly at times. I think the only options for overflow should be hidden, scroll, auto-scroll, and auto-grow. Contents spilling outside of a container ("overflow: visible") is just ridiculous and I can't imagine a time that would be appropriate.</RANT>
Contents spilling outside of a container ("overflow: visible") is just ridiculous and I can't imagine a time that would be appropriate.
Content spills out of a container because the only other option is to change the dimensions of the container. This is exactly what IE's autoenclosing behavior does, and it is one of the top banes of website development, IMO. Think about it: you build a site layout based on widths so that the peices fit together as intended. Then you add content that is wider than a container. If the container expands to contain that content, the widths you used to layout your page elements are changed, resulting in a layout that no longer fits and breaks apart.
The option (what compliant browsers do) is to maintain the designers specified width no matter what. This way the layout cannot be broken or altered by the introduction of poorly formatted content. But the content must do SOMETHING, and the option is to simply let it spill out of the container. In this way accessibility is maintained (the content is still there and readable) and layout is maintained, rather than sacrificing one in order to save the other.
both of the suggestions I have thought of and tried
They both work, so perhaps it was an implementation error and worth a second try.
cEM
As for the spilling out, what I meant is that I don't see why spilling out would be preferred over scrolling, hiding, or growing/shrink wrapping. I'm not saying that growing should always be preferred, just that overlaying seems pretty nasty all around. Maybe accessibility is where it comes in--but IMHO text rendered on top of other text seems pretty inaccessible.
