Forum Moderators: not2easy
Looking to the future, there have been a variety of proposed enhancements to CSS that would allow an author to declare that an element should stretch to contain any floated elements within itself. These would obviously be welcome additions to CSS, but as of this writing, support for such abilities is likely to be a long time coming.
[complexspiral.com...]
So, hear me oh doyens of CSS: What's the chance of me kludging a layout together in CSS that I use across 1000s of CSS designed static pages only to watch that design implode due to, say, an upgrade of IE that just crushes the kludge? Say something that changing a few lines in my .css file couldn't fix, so I have to go back into all those pages to switch out something?
Anyone with any experience with a significant amount of design work - based upon hacks - that imploded upon a browser upgrade? Is my anxiety about relying on layout hacks unjustified, unwarranted, un-un?
Other than a database driven site build upon a template any way you can think of to work around ex-post facto concerns? Best CSS design practices for 'just in case' scenarios?
Do you hear me suffering? Needlessly? Just design it and whatever happens happens? There be no monsters here?
Mommy, there's a monster under my bed. I know it. He's going to eat my websites as soon as I get them working.
Here's my theory, it's based on the assumption that the next release of IE will have better css support than the current triplets (5, 5.5 and 6).
If you design your site according to the specs, test in Firefox/Mozilla, even Opera and then kludge, you should be okay. The new IE7 will live up to the specs as best as possible, and we'll all be happy.
That being said, this is based on an assumption and good hack management is a good idea in case of emergency (IE7 breaks your site).
I would imagine that, with the recent warming of the IE team to the world of web developers and designers, they would try and avoid doing something that would really destroy a well kludged layout.
Hmm.. delicately balanced assumptions... I've done nothing to help you, have I?
Oh, but wait, that's why I can understand you (sort of)! I am a damned lawyer myself . . . trying to learn CSS . . . and just like the law "they" - the nameless, faceless, they why are in charge of everything - don't keep it simple, do they?!
The best approach it to keep things browser-neutral as much is as practicable - use the most advanced CSS-aware browser for development (currently the Mozilla family), and keep the hacks to fix specific display problems in legacy browsers (eg. Internet Explorer).
In your specific case, tables for layout are not recommended, but they are not evil, and they may be the best way forward in some circumstances - and certainly better than depending on a precarious heap of hacks because the design is pushing the envelope of current CSS-P browser capability too far. Try it, test widely, and validate, and you'll probably be just fine with a simple table framework.
And, as stated above, browsers are only bound (PLEASE!)to get MORE compliant, not less. Most 'hacks' are designed to be ignored by compliant browsers; that's why they work.
If you do precision designing with advanced css, you'll surely come across ie bugs. Like mipapage notes, *do not* design for ie, design checking in firefox or opera first - and I bet on firefox as my first browser. Chances are best they'll look good in the standards-compliant browsers. Then use ie's nifty feature of conditional comments to help ie clean up it's little booboos - this remains standards compliant, and you can put as much ie yickaroo as you want in this ie stylesheet since it doesn't count as far as standards are concerned.
Like this:
<!--[if IE]><link rel="stylesheet" type="text/css" href="style/ie.css" /><![endif]-->
I make this line somewhere in a central config file in the content management system so it can be modified or yanked site-wide at will. Has been much easier than trying to add the various hacks in a single stylesheet, which gives you very klugey css. And if ie7 turns out to be nice, which is very likely, that <!--[if IE] can be changed to a conditional comment that only applies for IE 6 and below (search msdn for 'ie conditional comments').
Styling for ie and then trying to correct for standards-compliant browsers is likely to be a nightmare since you started off on the wrong foot.
FIXING such a disaster would be a 'simple' case of changing one CSS file, not 1000 html tables.
It's true in the case of smaller sites, but if you're using a site-wide template in a CMS, it is no more complicated adjusting the HTML template than the CSS file.
If you can build a clean, hack-free, compliant, validated, table-free design which works in Mozilla, then apply a few hacks and tweaks to fix for IE and/or Safari, then your design is future-proof as we can only assume that future iterations of browsers are going to be better at standards than the current ones.
But, if the design requires hacks for all current browsers, step back and build something more robust - and that may mean using tables (and you can update your template later on once CSS support improves).
You talk like a damned lawyer!
:-], I think..
No.. because I tried never to use them, but it's a lot easier now than it was, there used to be hacks for different browsers, indeed different versions of different browsers..
Now the general consensus is that those who use Moz, FF, Opera etc. are technically aware and tend to upgrade their browsers regularly so there's no need to "back hack" for the older versions of them. Also I haven't heard NN4 mentioned in a while but it wasn't long ago it was something that had to be dealt with.. now the only grrr on the horizon ie IE5/Mac, but hopefully it's going the way of NN4?
Which leaves us with all those lovely compliant peeps and then IE. IE, we all agree is a pain, but it has to be dealt with.. so hacks become necessary. The good news is that it also provides us with ways to deal with each individual version, via it's own conditional comments [msdn.microsoft.com] so even if "7" is better, worse or indifferent, no hacks/kludges need break it, At the worst it will require different hacks to make it comply, but of course we're hoping it won't need any and will be so compliant it will work with the correct CSS we already have in place (LOL.. well you can dream). If so it won't read the comment that tells it only to apply the kludges to <=v6. If it doesn't then back to the conditional we may either have to expand it to include v7 or write an extra one for it only, Hacks for 5, 5.5 and 6 will need to stay in place for the forseeable future v7 or no v7
As a maximum in hack management it's probably the safest option to keep your IE hacks completely seperate, via these conditionals, if you're worried about future implosions ;)
Suzy
If you don't have picky picky clients, I wouldn't worry too much about the old, old browsers. It can add a lot of time and concern to dev work, and those who still are on those old old browsers need to get the message that they need to upgrade. Seeing pages that render kinda weird is one way they can get that message. I've noticed more and more sites that use the @import rule with no <link rel, meaning NN4 users will get non-styled content - and it really doesn't keep me up at night either.
The browser upgrades of the last year or so haven't been about 'the latest, the coolest' - simply about an internet that works reasonably. For some users, maybe seeing broken pages every once in a while is the only real way they'll come to terms with the fact that a new browser isn't like a new real audio player or a new flash plugin. It's about the most basic technology and not the gizmos. Maybe it's a nuisance to these people, but if you take into consideration the amount of resources put into supporting old buggy browsers, it seems to me equivalent to feeding a bad habit.
ie5mac gets the box-model better than ie6 I have been told (the developer was a well-known css enthusiast), so it's probably good it doesn't use standard ie conditional comments. For me it's an unknown - I don't have any Apple equipment any more, so I hope that the basic scrubbing of my main css in ie5 (I see if I can change the general rules for cross-browser behavior before I add rules) will work ok.
By the time IE gets released with a new rendering engine it may be time to redesign the page anyway :)
