>> Well, your problems are manyfold. >> >> Firstly, you're depending on behaviour that was never >> mandated in the >> specs, that being that a height of 100% means 100% of the >> available >> window area or available area.
> I don't think he's "depending" on this behavior. He's > lamenting the fact > that CSS doesn't support a mechanism for sizing elements > relative to the > available space. In HTML all heights and widths are based > on the available > area, not the size of the containing block. I dunno -- I was giving him the benefit of the doubt, 'cause I was hoping he would prove me wrong. :P The issue of positioning is related to it, but only really occurs because of the desire for sizing. > I also think he's hoping that someone will prove him > wrong. :) It would be nice. :) >> You'll get this behaviour *without* the doctype because >> that's how it >> was treated by browsers in the past. This is quirks mode, >> and there be >> funkiness. > I think Isaac's aware of this. Yep, had already covered that front -- and applied the standard-mode doctype and height & width 100% to both the html and body element in the style sheet (as seems to be the general recommendation from css gurus). >> If IE wasn't so braindead, it'd support fixed >> positioning. In this case, >> you could position your elements wherever you liked >> relative to the four >> sides of the screen. This is possible in Firefox, but not >> in IE, because >> MS have slowly let IE die. > Fixed positioning is possible in Internet Explorer. It is > even possible in > versions of Internet Explorer which pre-date the Mozilla > project. Again, > this is not about positioning, it's about sizing elements. I thought IE supported fixed positioning... I was giving him the benefit of the doubt that there was something wrong with MS implementation of it and his email was merely worded in a confusing manner. > Also, Microsoft has not let Internet Explorer die. They > are going to tie > Internet Explorer upgrades to new releases of the > operating system. > Personally, I wish they hadn't made this decision, but > that's their > currently announced intention. Unfortunately it's easier for them that way -- and I suspect it precedes another round of large numbers of heavily IE only, non-standard features for use with the new XML in Longhorne. Doesn't Mozilla do something similar with XUL now tho? The big difference being that Mozilla isn't selling it as the only way to integrate with a monolithic operating system that dominates a good share of the business market. At least as far as I know -- I could be completely off-base, just been my impression from what I've read/heard. >> Your problem isn't with the spec--and definitely not with >> the box model, >> which doesn't even come up here--but with a lack of >> implementation of >> the spec. > I think you've misunderstood the nature of the problem. It > is most > definitely an issue with the spec. Whether or not you > consider it to be a > fault of the spec (I do), is up for debate. > Here's a few links on the subject: > http://www.quirksmode.org/css/100percheight.html > http://www.webmasterworld.com/forum83/200.htm Thanks for the links... First one I've read... second one... well... dunno... I'm just not ready to drop $90 for 6 months of access to a site I don't know if I'll use much. > However, none of the solutions mentioned in these articles > completely solves > Isaac's problem. In fact, Isaac only got as far as he did > because he mixed > html table tags with divs. That was my experience. > Isaac, I've included some code below which seems to solve > at least part of > the problem I think you were running into. I've added > height and widths to > the html and body elements (I think you were already doing > this). I've also > added them to each element all the way down. > The theory is that if you don't specify either height or > width on one > element, that element will default to auto. Auto > translates to the size of > the content. Since this can't be calculated until after > the element is > rendered, any element within it can't use relative sizes. > However, I was unable to eliminate the vertical scroll > bar. I'm not even > quite sure where this is coming from. My guess is it's the > window chrome. > Perhaps you could set the height of the body tag onload > with JavaScript? Thanks Ben! Not bad at all! Much better than I was able to accomplish... I think I'm going to stick with the frames for this particular page (in spite of other issues caused by that solution), but I'm definately putting this in my queue of important development notes for reference. IE still has problems when you shrink the window vertically (it swallows the footer images under the lower edge of the window), though the scroll bar on the parent document could be eliminated I think with overflow: hide (?) on the body element -- I don't remember, I only ever use "auto" to create scrollable div's anyway. But I think the overflow property can be used to eliminate that scrollbar and in spite of how people feel about scroll="no" in frames I think that would make sense in this context with the content being a pair of iframes which consume most of the display so the only parts that wouldn't scroll anyway would be the fixed header & footer. Incidentally -- in case you were curious -- the issue caused by the frameset is that the content frame populates a "breadcrumbs" trail in the header using DOM. In order to prevent the race condition in which the content loads before the header frame and the div containing the breadcrumbs is then not available to be populated, I'm loading the header first and then using DOM in the header frame to load the content frame to make sure the header div is available before the content frame loads. I'm not entirely happy with this scenario, but it's working -- and it lets the user resize the navigation frame, so it has its advantages. s. isaac dealey 954.927.5117 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://macromedia.breezecentral.com/p49777853/ http://www.sys-con.com/story/?storyid=44477&DE=1 http://www.sys-con.com/story/?storyid=45569&DE=1 http://www.fusiontap.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Special thanks to the CF Community Suite Silver Sponsor - New Atlanta http://www.newatlanta.com Message: http://www.houseoffusion.com/lists.cfm/link=i:4:188341 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=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
