I have justr created www.maltabookshop.com. How come the site is ok in firefox while in IE a blank page is showing?? Thanks
You didn't close your script tag: <script type="text/javascript" src="scripts.js"> should be <script type="text/javascript" src="scripts.js"></script> That's your most likely culprit... Which is something validation would catch. Which you might want to try validatiing, you are using a XHTML 1.0 doctype but have a bunch of tags that aren't closed properly.
It shows as a blank page in Safari too. You are showing 16 errors on the HTML validator. I would start by cleaning those errors up to make sure one of them isn't the culprit. http://validator.w3.org/ Also, what is the reason behind the 1% heights? I am guessing some kind of IE fix. I would make those inside of Conditional Comments if that is the case. And for crying out loud, you have a table-less layout man! Get that font tag out of there! =/
A 1% height is what's called a holly hack for IE's peek a boo bug. The oddest bug I've seen. When the page loads, things disappear, but then reappear if you minimize the window and then restore it. Very odd.
Yup. Height:1% forces haslayout... and can be safely passed to all browsers so there's no need to waste the code on a conditional for it... same for zoom:1; - though I would throw a comment next to that. It's one of the browser hacks I don't consider a 'true' hack. To me true hacks cannot be safely passed to browsers other than the one you are hacking for... if you can safely pass it to all browsers that's not hacking, that's variable initialization. One of the core rules of programming, never assume the value of a variable, or in this case the default behavior. It's no different to me than doing the universal selector margin/padding null.
It's a hack because the standards say you shouldn't have to do this, but, as we know, IE is not a standards compliant browser. Anything that you have to add that is not part of the standards, is a hack in my book. Book authors also refer to this as a hack, hence it's well known name, the holly hack, named after the woman who came up with this solution.
See Peekaboo Bug Fixes. Not exactly true. Setting a height does trigger hasLayout in IE, and the reason setting that height to 1% (or 1px, for that matter) works for IE is that IE expands the container as needed to contain its content. Modern browsers will take that height at face value. The full Holly Hack includes the * html hack to hide the height property from modern browsers. * html #elementofinterest { height: 1%; } Code (markup): cheers, gary
It's a shame, but there is still nothing more reliable than tables. Hate to say it because I prefer CSS by far.
A lot of people will argue against that - you'll find I'm one of the few that does NOT. There are a handful of situations that floats just don't cut it... When you need a fixed height and dynamic vertical placement other that top. When you need styling on columns to run all the way to the footer on all three columns and faux columns just isn't going to cut it... especially in 100% height models. When you actually have tabular data and.... and... uhm, yeah. I think that's it. Though you do hear people calling tables for layout a hack, which it isn't and the arguements FOR it being called a hack do NOT hold water. "Because ____ said so" - RIGHT. "Because it's not tabular data" - does it have rows and columns? SOUNDS like a table to me. "Because it takes longer to render" - in a lot of cases (not all the time) it ends up being LESS total code to use a table given some of the hoops I've seen people jump through. As such if you can make the whole page arrive at the user faster, render time really doesn't play a part. A 386/40 running windows 3.1 can render a table in an acceptable amount of time.... I don't buy this one. "It doesn't work as well cross browser" - this one is just utter nonsense once you discover border-collapse:collapse; much less that it is supported going back FURTHER than most SEO float layouts. "You can't do SEO" - yes, yes you can, though it involves one or two empty TD's and rowspan. But like anything else, people want to take one technique to radical extremes rejecting all others - which is just wrong. (I caught myself on that with being anti %/em - You CAN use it after all, just not everywhere like the zealots say to) It's very important IMHO to know how to do ALL the ways of coding an effect visually, and not sticking with just one and hack hack hack to make it work in all circumstances. Do not reject a tool just because some expert says it's "Bad" - at the same time do not overuse a tool... Which is the table's biggest problem - overuse. People end up using it for single columns (which there is NO good reason to ever do apart from vertical-align), or for column layouts that don't need it. Of course when these people move to non-table layouts they end up nesting DIV's and loading up on classes, making just as unneccessarily bloated pages as when they were working with tables.
Not in all cases... Which is why you TEST the effect. If it screws up, put it in the conditional or a star hack, if it does not mess up, don't waste the code. In this case it does NOT effect the other browsers since MOST of the time % heights are treated not as height, but min-height so long as you don't mess with overflow. and in those cases you might be better off using zoom:1;
<div style="height:1%; border:1px solid #000;"> <p>Test Content</p> <p>Test Content</p> <p>Test Content</p> <p>Test Content</p> <p>Test Content</p> <p>Test Content</p> </div> You can add/remove those paragraphs until blue in the face, and Opera, Safari, FF and IE all ignore the height:1%; - even as overflow:hidden; height:1% is ignored by all browsers apart from tripping haslayout in IE. (actually good you asked for a testcase, I thought overflow:hidden would screw it up, it didn't) Technically, I believe ignoring it IS the correct behavior, because heights cannot be stated in percentages unless the container has a fixed height... from the W3C spec: Meaning that MOST of the time, height:1%; is the same as height:auto; It's not perfect for every situation, but it's 'good enough'... Besides, if percentage heights only work inside fixed-height containers, there's no reason to use a percentage since you can do the math by hand - not that I ever would use a percentage height apart from 100% given the differences in rounding off between Trident, Gecko, Presto and KHTML/Webkit.
Thanks a lot. Cheers. Anyway, there are clearly hacks necessary for CSS. That's not reliability in my book. If I do tables, I am always guaranteed across all browsers. Like I said, I like CSS better for a multitude of reasons, but it still needs hacks, and complete cross browser reliability is not one of the reasons. Yes, I know that's IE's fault, but it doesn't change the reality. If I had to code a site and I had to be sure that it looked the same across all browsers and browser versions, without being able to test this and then adjust and fix it, I would do it in tables. No doubt. Much better chance of working right out of the box, even though I hate coding in it. But CSS is so superior in so many other ways. Most importantly, to me, is the fact that you get the markup off the page. Search engines love this. To me, that's the number one, most practical or financial or marketing oriented reason to use CSS. And don't forget. Websites don't exist so that you can have a coding job. Many purists lose site of this.
Why yes, there are some hacks and work-arounds required. However, it is centered around one outmoded browser, whose shortcomings are well documented, as are the fixes. With rare exception they come down to positional reference, hasLayout or position+hasLayout. Once you know what you're doing, you apply the needed hacks or work-arounds automagically, without conscious effort. Have you forgot all the hacks and work-arounds that any non-trivial table layout requires? Browsers have much more leeway in how they render a table, and they take advantage of that slack in the specs. Even the simplest of tables vary greatly in rendering from one UA to the next. Experienced table coders apply their hacks as easily and with as little thought as I do with css. Job security? It requires considerably less time and effort to maintain a css based layout than it does to keep up a table based page. But hey, it's always easier, and engenders greater confidence, to do what you know best. There comes a time to embrace the better technology. CSS is that technology. gary