For small Websites and quick "PSD to XHTML/CSS," I wouldn't consider using this. And isn't it best for a newspaper-like website? I guess the question is, does a CSS Grid help everyone ? I haven't had a project where I felt like I had to use it yet. And very seldom are the designs I get meant for a grid.
Most CSS frameworks are utter rubbish once you know what you are doing - and frankly if all you ever use is frameworks you'll never know what you are doing. They are fat, bloated, declare a bunch of stuff that isn't necessarily going to be used, and are often written by people who don't know what they are doing in the first place or WORSE, haven't updated their skillsets since 1998. span-8, span-15, span-6, span-7 - First off they are being assigned to div's, not spans - secondly they don't say WHAT the content is, just how they appear. That's just as bad as having classes called "border", "left", "right", "bold", etc. At that point you might as well have just used presentational markup as it entirely misses the POINT of CSS in the first place. That and 13k of CSS in three files for a page that shouldn't even break the 3k mark - instantly made of /FAIL/. Take a look at their sample page - given their INCORRECT use of heading tags that should be enough on it's own to warn you away from using it... Because of course you should have a h2 immediately after the h1 (when it actually should likely be PART of the h1 or a paragraph/div beneath it), immediately jumping to a H6, (WTF happened to 3, 4 & 5? - H3 should be next!), You have an H3 followed by a H5 (is that h5 a subsection of the h3? No it is not, so that should be a h3, even if it WAS it should then be a h4), and then a h2 at the bottom that isn't even the start of a new section. When they can't even use heading tags properly, it doesn't exactly inspire confidence in the rest... That the CSS is distributed in the stupid malfing damn near illegible one line per class/id/tag technique, declaring inherit on properties that DEFAULT to inherit (WTF is that supposed to accomplish) top to bottom it's a miserable ***ing /FAIL/ - just like YUI, Mootools and every other damned 'framework' that seems so popular these days.
How about YAML? Yet another /FAIL/? It has helped to give me ideas, but I've never considered using so much CSS. Frankly, I don't want to give up control of my CSS. The only reason I would consider a CSS Framework is if it saved me time, so I could make more money. However, this assumes that the client doesn't mind the usage. I spent some time looking at YAML, and I'm not that impressed. I think it's more impressive for someone who doesn't know CSS very well and wants to be sure their design works well in all browsers. Yet with the downside of bloat and stagnation of development skill.
EXACTLY. I think the popularity of 'libraries' stem from two types of developers. First, as you noted, the people who don't know CSS and are new to it, it seems like an easy way to get started, despite the endless problems associated with them. The second group are programmers coming from a compiled language background. Under compiled languages unused parts of libraries are usually not compiled into your program, or in the case or runtime libraries not linked in or are already in OS memory. For all intents and purposes web technologies, even HTML and CSS, are interpreted languages from a functionality standpoint - the net result is that unused parts of a library or really any code written are still sent over your connection, have to be parsed by the rendering engine, etc, etc... In a number of ways it's like badly written BASIC programs in the 80's where you could make them run four times faster by deleting the REM statements. Or what Apple just figured out regarding Leoptard, as their linker was including uncalled routines. Snow Leopard is faster NOT because of the 64 bit code (64 being faster than 32 on CODE has always been malarkey - memory moves, sure... Raw code? #DDD ) but because they fixed the linker resulting in uncalled code being pruned from the 'gold builds' - net result? Many applications built for OS X 10.6 have half the memory footprint and a quarter the binary size. (and they get even smaller now that they are including binary compression) In an interpreted environment, frameworks suck. When the point of classes and ID's is to say what things are and NOT how they appear, the common habit of frameworks having classes like " Of course, you mentioned YAML - which is one of those situations of learning YET ANOTHER way of doing things that is one more level removed from how it really works... in the name of simplifying things. That's like running WinUAE inside the PPC version of Virtual PC inside Rosetta on OS X on an intel chipset laptop. If it were the Excelsior, Mr. Scott would have a field day. YAML, it's simpler. Aye, and if my mother had wheels, she'd be a wagon.
The same goes to me. I would only consider using this CSS framework if it really makes sense using them such that it will greatly help for efficient production time and less hack(troubleshooting) while maintaining semantically correct codes. For the mean time, i would still prefer hand-coding everything.
Hand-coding everything is best, but frameworks certainly have their benefits. Sometimes they are good to get set-up rapidly, and then to clean up afterwards. Admittedly, some times you never get around to cleaning up. The best use of them is when working with a team. It establishes a quick set of conventions and makes it so people don't step on each other. It's especially useful if you have people of different skillsets working simultaneously (which is likely). Blueprint has a few tools to convert over all your class/id names to more semantic naming conventions. You also aren't obligated to use the other stylesheets like typography, etc. Also, I disagree that these were created by folks who don't know what they are doing. YUI, YAML, and 960 Grid System were all created by people I respect. Bottom line, it's just a tool. It will never replace know-how.
They are made for a million different situations, so naturally, they contain a lot more than is actually required when used on just 1 site.
I can't say that about YUI, as I'd not expect it's creators to code their way out of a piss soaked paper bag with a hole in the bottom... YAML strikes me as being developed by people who know JUST enough programming to be a danger to themselves and others, while 960 grid system pretty much defeats the entire POINT of using CSS in the first place (though many 'frameworks' are guilty of that)
I'll admit, I'm still fuzzy on what a framework IS, and likely the only reason I don't use one is because I never learned to use one (same reason I don't use a WYSIWYG-- never owned one). Me being the lazy person I am, I may have gone to such things had they been presented to me. Fortunately, now I can look at code for things like templates and it burns my eyes. Which is a good thing.
I think this is the basic "framework" I want for all the CSS & XHTML my business provides clients, whether it's coded by myself or another: * Reset CSS (http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/) * Use conditionals instead instead of CSS hacks * Same re-usable IDs for containers, columns, and blocks within * Standardized class names for re-usable elements, such as decorated lists, buttons and images * Valid XHTML with simple markup and separated presentation -- it should read logically with CSS turned off
You really want it the other way around. I know M$ keeps saying CC's are better, but how, if they need to be placed in every single HTML file, when you can usually use a little less code and have it in your SINGLE CSS sheet? It's much better to say * html #menu { margin-left: -3px; } to fix a 3-pixel-jog bug on every page you have, than to have <!--[if lte IE 6]><style type="text/css"> #menu { margin-left: -3px; } </style> <![endif]--> on every single page in the <head>. Sure, you can take the work out of it by using HTML templates (where you only have a single copy of the <head> for instance) but those who visit the page are loading that HTML every time they get a new page from the site... while the CSS page is only loaded once. PLus, while hacks in general are not good, the * html hack, used sparingly, is not one that would even come back to bite us. No other browser but IE6 and below looks at that. Everyone else ignores it, and as a well-known hack, no browser vendor is going to let a new browser do something with it anyway. A "stable" hack. As for the reset, you get to choose: A huge bloated list-200000-elements so as to preclude form controls (and I've found it's not margins that cause issue anyway but padding on inputs and options), or just * { margin: 0; padding: 0; } img { border: 0; } ul, li { list-style: none; } or whatever, right first thing on your single CSS file. Even if you do have one of those big sooper resets, there's no reason to have it as a seperate file since again your visitors have to ask for each and every file, and why make them ask for 2 files when they could just get one? Even though you may want that same reset for every page you've got, it's still better in my opinion to just have some code being the same between CSS sheets.