Ben Rogers wrote: >> What I meant by depending is that while such behaviour isn't specified >> in the spec, it is available in a fair few browsers in their quirks >> mode, but not in their standards mode. > > I think we're referring to two separate behaviors here. I was referring to > sizing relative to available area as opposed to the containing block. > Specifically, I was referring to its absence in standards mode, which I > think is unfortunate.
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. >>Well, I was trying to show that he was trying to put in a screw with a >>hammer rather than a screwdriver: it might kinda work, but it's not the >>right way, seeing as his problem was really a positioning one rather >>than > > I see what you're saying. However, I interpreted Isaac's original post as > blowing off steam. In other words, I think he was lamenting the fact that > CSS (at any level) does not support sizing relative to the available content > area. Isaac, let me know if I misunderstood this. > > My question to you is, all other things being equal, do you really think > that fixed positioning is a better way to solve this problem than relative > sizing? Yup, because the problem he wants solved doesn't actually involve sizing, but positioning within the viewport. He's got two content frames, both of which have their own > One of the great things about HTML is that elements are allowed to > flow. Users can change their default font and size, disable images, etc., > and the page just adapts. > > Fixed positioning in general -- and your proposed solution specifically -- > break this very badly. As a developer, I now have to know the exact pixel > size of every element on the page and position objects off the > top/bottom/left/right accordingly. Worse, I have to know these at design > time as opposed to runtime. 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. Believe me, I'm a complete nut when it comes this kind of thing. I prefer to leave as much up to the client as possible. One of the things that irks me at work--hi, guys!--is that the other lads go for the whole I-must-have-complete-control-pixels-pixels-pixels. I don't. There's not been a layout that I've come across that I haven't been able to do in a reasonable way with CSS, holly hacks aside for IE, and I'm no size nazi, far from it. 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. Don't panic, I wouldn't to anything nasty like that unless I'd a metaphorical gun to my head. > I just don't understand how this can be considered an improvement? > >>But what he's trying to do *is* positioning, not sizing. > > Correction, what he's trying to accomplish is sizing relative to the > available content area. Yup, that being the viewport, making it a positioning issue. > The only way to approximate it in CSS 2 compliant > browsers is to use fixed positioning. There's two ways of viewing it: you can view the problem as a sizing issue, but that only leads to pain because he's trying to do sizing relative to the viewport. But the viewport's never going to overflow because all the content's in the iframes, so if you look at it from a positioning point of view, the problem simplifies to almost nothing. It's a bit like the sorting problem in column one of Programming Pearls: from one point of view, a problem can seem nigh impossible (doing sizing being the way this was tackled), but if you know the constraints (that sizing is being done relative to the size of the viewport, it never overflows the viewport, and always fills it), the solution becomes simple (use fixed positioning!). > To my knowledge, there is no way to > accomplish it in CSS 1 compliant browsers (sans-html formatting). Yup, but CSS1 browsers bearly tackly anything more than formatting. >>I know he's >>talking about sizing, but what I'm trying to get across is that *his* >>particular problem isn't with sizing, and not with the differences >>between the MS and W3C box models. >> >>And IE doesn't support fixed positioning, nor has it ever done so. > > Uhg. Yes it does. Internet Explorer 6 supports CSS level 1 fixed > positioning. Earlier versions of IE also supported it, albeit with the > broken box model. Nope, it supports relative (albeit in a slightly broken, but hackable manner) and absolute positioning. >>Try >>the code below in IE6, Firefox, Opera, and any other browsers you can >>lay your hands on if you don't believe me. > > You really need to qualify some of your statements. The code you posted uses > CSS level 2 fixed positioning. Specifically, the "bottom" and "right" > properties are part of the level 2 spec. Internet Explorer does not support > CSS level 2: Not all of it, but a huge chunk. It supports, like all modern browsers, most of the part of the CSS-2 spec known as CSS-P, and some extra bits. > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html > /cssenhancements.asp > > "Building on top of the functionality of previous versions, > Internet Explorer 6 now provides full support for CSS > Level 1" If it only supported CSS-1, it wouldn't be able to do positioning at all! There's no positioning in the CSS-1 spec <url:http://w3.org/TR/CSS1>, just the box model, and formatting. Browser manufacturers pick and choose whatever parts of the specs they want. They can implement chunks of CSS-2 without implementing all of CSS-1. >>And there only doing that because another strong contender appeared on the >>scene in their primary market. They *had* let it die, but now they're >>resurrecting it. > > Really? I've never seen anything official from Microsoft that said they were > discontinuing development of Internet Explorer. All the official stuff I've > seen simply said that they were not going to continue to develop Internet > Explorer as a separate product. 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. >>And my argument is that he's attacking the problem with the wrong tools. >>Positioning is what he want. It's a pity IE just doesn't support it >>completely enough. > > Fair enough, and I agree that it's a shame that Internet Explorer 6 does not > support CSS level 2. It does, but only partly. > The standard is old enough that support for it could > have made it into Internet Explorer 6. Nevertheless, since Internet Explorer > is still the dominant browser, your solution isn't really practical. With the IE7 JS hacks it is: http://dean.edwards.name/IE7/ > For what it's worth, I agree that fixed positioning is the way to accomplish > what he's trying to accomplish in CSS 2 compliant browsers. It's > unfortunately, but it's true. 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. No, the lamentable thing is that IE doesn't support it. Ah, well, here's always Dean Edward's IE7 hacks... K. -- Keith Gaughan, Developer Digital Crew Ltd., Pembroke House, Pembroke Street, Cork, Ireland http://digital-crew.com/ -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.6.2 - Release Date: 20/12/2004 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Special thanks to the CF Community Suite Silver Sponsor - RUWebby http://www.ruwebby.com Message: http://www.houseoffusion.com/lists.cfm/link=i:4:188454 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
