> No, I think we actually agree, it's just that we're misunderstanding one > another. I'd better explain what I'm talking about. Roll on ASCII art!
Sorry about the confusion. I wasn't referring to how the size of a box is calculated in either the W3C box model or the pre-Internet Explorer 6 box model. Nevertheless, that ASCII art was pretty impressive! I'm not sure that there is a specific term for what we're talking about. Here's the situation though... When you specify a relative size (50%) for a block element in CSS, the size is calculated based the total size of the containing block. If the container is set to auto, then the size of the container is unknown until the container has been completely rendered. In such situations, the relative size is ignored, defaulting instead to auto. This means that you have to know the size of all the box elements in the hierarchy to specify a relative size on one. You can read more about this behavior here: http://www.quirksmode.org/css/100percheight.html "The spec says: 'If the height of the containing block is not specified explicitly (i.e., it depends on content height), the value is interpreted like "auto".' This means that if you do not define any height at all for the containing block, a percentual height of any contained block doesn't work: the block becomes once again exactly as high as it needs to be. Even though this rule may in a few cases save the browser work in calculating the correct heights of elements, I still think that it is far too restrictive and it's caused by bad thinking on the part of the standard makers and the browser vendors. Counter-intuitive and unnecessary rules like this one make our beautiful CSS too hard to work with." Anyway, that's problem number one. To further complicate things, relative sizes are calculated based on the size of the containing block. This means that you have to know the size and width of all the elements within the containing block (all of the adjacent blocks) when specifying the relative size of an element. For example, I've found that trying to approximate the following layout in CSS is very difficult: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"> <html> <head> <title></title> </head> <body> <table width="100%"> <tr> <td colspan="3" bgcolor="#eeeeee"> header <div style="height:100px;"></div> </td> </tr> <tr> <td width="150" valign="top" bgcolor="#dddddd"> left column </td> <td valign="top"> center column <div style="height:400px;"></div> </td> <td width="150" valign="top" bgcolor="#cccccc"> right column </td> </tr> <tr> <td colspan="3" bgcolor="#bbbbbb"> footer <div style="height:100px;"></div> </td> </tr> </table> </body> </html> The layout has the following properties: - A header which spans all three columns and has a liquid height and liquid width - A right column with a liquid height and fixed width. - A center column with a liquid height and liquid width. - A left column with a liquid height and fixed width. - A footer which spans all three columns and has a Liquid height and liquid width. In addition, each element has (or can have) it's own background color specified at the element level. Mostly, I just included the background colors to highlight the fact that each element lines up with one another regardless in the different content sizes (which I'm artificially controlling with the divs). The closest thing I've found is this page: http://www.positioniseverything.net/guests/3colcomplex.html They fudge the center column by giving it margins equal to the width of the left and right columns. They don't include a liquid footer that expands across all three columns. In addition, they had to rely on some common tricks to give the left and right columns a background color. Specifically, the left column is given a transparent background color, inheriting the background from the body element. The right most column uses a repeating background image. > The box model specifies the elements of a box, and how its dimensions > should be specified. The W3C box model is: Here's a link to save you from typing so much in the future. :) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html /cssenhancements.asp > The real problem is that CSS needs a way of saying "if my parent has any > free space, give that to me". "auto" means "give me just what I mean", > "100%" means "make me fill my parent", but what we need is a "remaining" > height, so if you specified: Heh, I thought that's what this entire thread has been about. I'm not sure where the IE vs. W3C box model came from, but the whole point I've been trying to make is that you can't specify the size of a block relative to the available content area. > <div style="height:100px"> > <div style="height:remaining">Blah!</div> > <div style="height:remaining">Blah!</div> > </div> I don't think it should be implemented this way because I want to be able to specify percentages of the "remaining" content area. If, in HTML, I specified width="50%" on a table, it would take 50% of the "remaining" area or what I've been referring to as the "available content area". > The height would be distributed evenly across both. A way to specify the > proportion of the remaining space would be nice too. > > BTW, this addition to CSS would solve Isaac's problem as regards sizing. ...which has been our point all along. > You see, it's not that the spec is bad, just lacking. Well, I think we've at least ended up at the same spot. Personally, I think it was a huge oversight of the designers of the CSS2 spec. They failed in a very fundamental way to provide backwards compatibility with HTML. Perhaps "backwards compatibility" is the wrong term. They failed to fully duplicate the layout functionality of HTML and failed to provide adequate alternatives. For proof of this, I'll cite the many sites all dedicated to helping people build 2 and 3 column layouts with and without headers and footers. They use hacks like those mentioned above (transparent backgrounds, tiled background images, etc.) to accomplish something that was trivial in HTML. I posted links to several such sites earlier in this thread. > If you're using ems, it's height will expand. However, and this applies > to any kind of layout system that doesn't allow you to specify > constraints based on the interrelationship between adjacent elements, if > the line wraps, you're screwed. Ems will take care of size increases for > the most part, but not, unfortunately, linewrapping. I don't usually use ems. I'll have to look into them a bit more. CSS is the way of the future, so I have to give up old habits, no matter how much I may prefer them over newer alternatives. So, if ems solve part of my problem, then I should definitely be using them. > Nope, with positioning, you can't do that. There's no way to specify the > constraints. OK, I'm glad I wasn't missing something there. I would have had to throw myself out a window if I'd missed this all this time. > > In this case, the available content area happens to be the view port. > > No, the viewport's just that: a view of the page. The only aspect of the > viewport that ought to impact on the page is its width. The available > content area is the page itself. I think our definitions were a little off. When I refer to "available content area" I'm referring to what you called the "remaining" area. If there's a word for this, I'd love to know because a standard terminology would really save us a lot of trouble. :) Anyway, the point of my comment was that your fixed positioning example works because the view port happens to equal the available content area. I gave an example of where this would not be the case. In that example, fixed positioning would not work because fixed positioning is, by definition, tied to the viewport. > No, but there's ways of doing it. If you show me what you're trying to > do, I could probably come up with a solution. I posted a simple table example, but don't feel obliged to come up with a CSS2 equivalent. I was just trying to better explain what I see as the fundamental issue here. > Almost. It does everything except expand the height of the "ladder" (a > breadcrumb trail?) if it breaks onto two or more lines. Other than that, > it works perfectly. That pretty much sums up my experience with CSS. It works for all but one piece of the design. I still use tables in just about every single design because there's always that one thing that doesn't work right. Ben Rogers http://www.c4.net v.508.240.0051 f.508.240.0057 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Special thanks to the CF Community Suite Gold Sponsor - CFHosting.net http://www.cfhosting.net Message: http://www.houseoffusion.com/lists.cfm/link=i:4:188491 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
