> Yup, it is, but that's not a problem with the box model--that is, the > way the width, height, padding areas, borders, and margins interact with > one another--but how the spec says heights should be calculated.
Here's where we disagree. I think that sizing in the box model is fundamentally flawed when using relative positioning. Specifically, I would have preferred to see relatively positioned elements sized based on the space available -- as is the case with HTML. That said, I'm sure I'm wrong because the rest of the world seems to disagree with me -- except for maybe Isaac. :) > Yup, because the problem he wants solved doesn't actually involve > sizing, but positioning within the viewport. I guess this depends on how you look at it. If you're switching from HTML to CSS, CSS seems backwards and overly complex. If you're switching from making desktop apps to HTML, I'm sure HTML seems awkward. > Nah, this doesn't break it, though it might give the impression that it > does through my use of pixels. I only did this because the HTML he > originally posted up did that. Really? I'd be interested in seeing an example. It's my understanding that, if an element has a size of auto, the height is not calculated until after the element is rendered. This means that elements within that element cannot be sized relative to the parent. So, I don't understand how you'd accomplish this in CSS. > But his problem is perfect for this kind of fixed positioning. I just > wish you could specify sizes like 2em+3px, which would help with > accessability in a lot of cases. He wants to place things up at the top > and bottom of the viewport, with content in two iframes, so positioning > everything off the borders of the viewport doesn't actually cause any > problems here. The contents of the view ports can still expand, and the > content iframe resizes with the containing iframe. The problem, as I see it, occurs with the second row. What happens to the content in that row if the font size were doubled by the client browser? Better yet, what happens if the content is dynamic and has to wrap? You can clip it or scroll it using CSS. However, I don't believe there's a way to dynamically size it so that the row with iframes will always start immediately below the second row, regardless of how large the second row is. I'd love to be proven wrong. > Yup, that being the viewport, making it a positioning issue. In this case, the available content area happens to be the view port. However, in most cases, I don't believe it is. For instance, I'm working on a design right now in which I'm floating the logo to the left and would like to center the company name between the logo and the right hand side of the page. Fixed positioning does not solve the problem in this context. > Nope, it supports relative (albeit in a slightly broken, but hackable > manner) and absolute positioning. Yeah, I misspoke on this. I reversed fixed and absolute as I was looking through your code. > Who says that they have to make an official statement to make something > true? All they have to do is relegate the IE team to making patches for > security holes in MSHTML. Since IE5.5 and particularly IE6 came out, MS > have been steadily cutting back the size of the IE dev team back from > several hundred developers back to just a few tens of them. When gecko > browsers started to makes inroads into their share, the number of > developers started to increase quite a bit. > > And I'm only going of what MS devs have told me happened. I don't personally know anyone at Microsoft, so I'll defer on this. I'm basing everything off of official announcements and random Microsoft blogs. > With the IE7 JS hacks it is: http://dean.edwards.name/IE7/ I had ignored the IE7 project because I thought it was a collection of hacks. Looking at it now, I see that it's using JavaScript to parse and render the CSS. I'm not as adverse to this as some of the hacks I've seen out there. I might have to look into it more. > I don't think it's unfortunate really, I think that's just what the > solution calls for, and that's part of what fixed positioning is there > for in the first place. Well, assuming that you can accomplish the same effect as your earlier code without the use of exact pixel sizes, content clipping or scrolling, then I'd have to agree. Short of this, I think it's a bloody shame. 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:188477 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
