There has been a little buzz about some CSS frameworks recently, such as Blueprint, although YUI’s grids & other parts have been around for a while. I’ve kept an eye on these, but they have never seemed suited to CSS for one main reason.
CSS frameworks maintain the style sheet as a constant, and make you change the HTML.
This is in opposition to the aim of CSS, where you leave the HTML in it’s most meaningful form, and use CSS to change the appearance:
Complementary to structured documents. Style sheets complement structured documents (e.g., HTML and XML applications), providing stylistic information for the marked-up text. It should be easy to change the style sheet with little or no impact on the markup.
I’m not holding that up as a holy reference that must be adhered to, and there are certainly situations where CSS frameworks are useful, but it just doesn’t seem right to change the HTML to use them (for production sites).
Jeremy Keith mentioned their usefulness in prototyping, but equates it to creating cookie-cutter sites
. Jon Christopher touched very close to this point talking about how a CSS framework passively removes a great majority of semantic value from the markup of a document
.
JavaScript is a programming language that in some way suits being built up into a library, and the recent spate of good libraries can be layered on top of an existing site. However, the same concept just doesn’t fit a mark up language like HTML, or style sheets.
PPK is undecided (just completing the link loop).
Just like PPK, I can’t help myself. You really made some interessting points. I completely agree that you should not change your HTML because of your CSS. That’s not the way it meant to work.
But I think, there can be CSS-Frameworks be written, that doesn’t cry for changes in your HTML.
That reset.css for example is such a part. Some typographical descriptions also should be in no harm to the mind of CSS. I should make some investigations. (And built a new Blog to spread this information. *G*)
I think, CSS-Frameworks by itself are not completely out of the way, even if they can be easily miss theie goal.
I feel that CSS in itself is like a framework and because it is already human-readable there is little point in creating an abstraction layer.
I can see why something like a reset.css file would be useful but would hardly call it a framework.
I have been building cross-browser compatible sites with CSS and xHTML for over 3 years and find that it takes very little time to turn a bespoke design into a CSS/xHTML template.
Do we really need a framework for something that looks like this?:
width: 200px;
background-color: red;
etc….
I have shunned the use of YUI because of their overriding need to include massive amounts of JavaScript into the model and instead have attempted to build a cross-browser, standards compliant template. At first I thought it was going to end up being a CSS framework, but instead, it became more Ruby-like in implementation. Right now, it’s still pretty simple in execution, but I can call a Perl script to create the files needed for a page and have it automatically determine how many columns are on the page as well as choose between horizontal or vertical navigation.
Here’s the kicker, I have a single JavaScript file for recreation of the hover method in IE6 and below, two scripts written in Perl to generate pages, and a single shell script for killing my included content. Everything else is pure Server Side Includes containing xhtml strict and CSS.
I think after building this, that I agree that there shouldn’t be “CSS Frameworks” and instead, there should be “Template Systems” that will generate basic pre-generated code to handle the global framework of a web site. The rest should be up to the web author.
It’s worth watching the lecture by Nate Koechley at the YUI Grids developer site.
You don’t have to add any JavaScript to use YUI CSS so I don’t know what Christopher is talking about.
The layouts can be incredibly flexible if you need different widths, however it’s not well documented (though the video explains how).
The DIV element is generic for adding structure to documents, so it’s perfectly appropriate to use divs to group navigation elements and secondary content. YUI CSS does impose one semantically extraneous DIV. However, all the other DIVs do not inherently violate any semantic minimalist principles.
The advantages of YUI CSS is that all of the hacks we use to make layouts consistent between IE and the more standards compliant browsers are encapsulated in one file. It’s not usually necessary to hack your own CSS to make it work in IE (though widths are still a problem since 1em = .9759em in IE).
Hi Ben,
Thanks for the link. I think YUI is probably the best of the frameworks I’ve come across, including the CSS aspect.
However, it still doesn’t seem natural to have to alter your HTML to match the CSS. Rather than “related navigation”, you have an obscure character set.
I appreciate the reasons, it just feels backwards.
Ben,
Perhaps I was mistaken, I got the JavaScript impression from something one of my workmates had printed out, and perhaps there was more than just the YUI:CSS in there. I took a look at the link you included and was surprised by what I found. Looks like what I’m doing exceeds this by far.
One of the advantages that I have is I don’t have preset templates, instead, I’m having the user input variables and the template is made on the fly. I offer up to three instead of only two initial columns with dynamically generated widths instead of fixed. All of this is systematically processed and displays in a liquid layout for further formatting.
The only thing that I seem to be missing in my implementation is the preset ability to nest grids. I’ve thought about doing this, but, quite honestly, if you need to do this, then you’re working on a site that’s going to become cluttered and wild really quickly. I prefer the simple approach, which has been proven to be more aesthetically pleasing to the majority of users. In short, people don’t like to read, so don’t present them with a whole lot of information all at once, or they’ll experience an overload and wander away confused.
The other thing that I offer with my template is the ability to own it and modify it to your liking. Looks like if you use YUI, then you’re at their mercy if they want to change the file that your site references. Sounds like a disaster waiting to happen to me to rely on someone else to provide your CSS for you. Sure, it’s quick and you don’t have to think, but that’s half the fun of making a website anyway. I love to experiment with CSS to see how it would function in different ways, and thus, have become a much better programmer than if I just got lazy and used someone else’s files without even looking at them.
The last advantage that I will say is that my templates are 100% IE compliant, including widths. That buggy em thing is the problem, so I’m using percentages and px. IE 6 and below is a static site so I don’t run into problems with IE 7 and the rest of the world doing liquid layouts. I haven’t fully packaged the product yet, but look for it on http://www.phaldor.org That’s where it will appear very shortly (i.e. within this month anyway).
Chris
P.S. AlistairC, I feel the same way, YUI does attempt a good framework, but it IS backward! 🙂
AlistairC: It’s true, you do have to alter your HTML to use Yahoo’s IDs and classes. However, if you don’t use Yahoo’s CSS framework, you’re going to have to invent your own names to achieve the same results.
Christopher: I don’t know if you’re meaning to call me lazy, but I got really tired of hitting my head against the wall of IE inconsistencies and only YUI has saved me from it time after time. All I need now is a calculator and I get precisely the same layout on IE 6, Safari and Firefox pixel for pixel. I don’t need to re-invent the wheel.
YUI’s full set of code is downloadable from Sourceforge under a BSD license, so you don’t have to rely on Yahoo to host it. Furthermore, if you do rely on Yahoo’s hosts, the src URLs for the CSS files specify the version number, which means Yahoo won’t be changing older versions without increasing the version number.
Hmmm….ok, I’ll bite here. No, I didn’t mean to intentionally call you lazy, after all, YUI does some pretty good canned stuff, if that’s what you’re looking for. So I downloaded it and took a really good long look at what they’re doing here.
First, let’s break it down into sections. The YUI library is mainly a JavaScript library that incorporates some preset CSS templates as a wireframe model. Essentially we’re mainly concerned only with the CSS that it provides, not the bloat of nearly 7MB of other stuff contained in the download (incidentally, my entire code base is only 464KB in comparison, graphics, scripts, and all). Then, to break it down further, the CSS section only has four things listed, three of which can be combined in a single file called reset-fonts-grids.css. So, essentially, YUI::CSS consists of two files. That’s it.
In looking at these two files, the base.css reconstructs block elements to have style after the reset-fonts-grids.css is processed so that all browsers render the block level elements the same way, but it uses em’s. What’s more, is it doesn’t compensate for the IE flaw in the em calculation. This is where I find your statement that it renders across all browsers “pixel for pixel” simply bs. Put bluntly, you’re lying through your teeth, although I admit that you probably don’t know it.
So let’s look at the other file. The basic reset on HTML elements is straightforward and only contains a little bloat due to being a little bit TOO inclusive IMHO. There are elements included here that are either so infrequently used to be non-existent or depreciated in the DTD that I use. Then it defines a whole lot of yui classes, this time compensating for IE’s flaws with the em width. Now, I’ll admit, I didn’t go into depth here by pulling up a document in Firebug and actually looking at everything that each class does, but a peripheral look at it looks like a bunch of positioning, but that’s about it.
Because CSS defines HTML, then I would assume that a corresponding html file is located somewhere else in the YUI system that incorporates these classes. I would further surmise that, although you could use these classes separately, it wouldn’t be practical for you to do so, simply because it looks like these get pretty specific (at first, I wasn’t sure there were any commas, after I saw them, I still counted at least four levels on some of them, e.g. an element with a class within a class within a class). To me, this represents someone else’s concept of what my page should look like and means a cookie cutter site. Worse, because of it’s popularity, it means a very COMMON cookie cutter site.
I know what your next argument is going to be….that of the 10000 or so possible combinations. Sure, it is possible to do that many because of the nested grid arrangement, but are you really thinking that when you employ this system that you’re not really copying someone else’s look? Fact is that over a million NEW websites are put on the Internet every day. Chances are very good that you’re new site looks like about 10000 of them. Ok, sure, my system doesn’t change this picture very much either, but in the end, isn’t what YUI is doing with CSS pretty much the exact same wire-modeling that you could do on your own?
And the answer is yes, that’s really all it’s doing with the CSS. The vast JavaScript libraries that it includes is really the bulk of the system. Not sure how you missed that, but it’s the truth of the matter here. Bottom line is that even your calculator punching can be eliminated if you sat down and actually coded the css yourself so that you’d actually understand what YUI is doing. You just learned a system that didn’t change your methodology very much, it just gave you a bunch of bright new, shiny toys to play with in the JavaScript libraries.
As for re-inventing the wheel, I haven’t run into a situation where I even needed a calculator, and my template works cross-browser reliably. Period. Seems to me that I “invented” a better wheel here….
Now, to get this post back on topic…AlistairC, you are talking specifically about CSS frameworks and their usefulness. After my analysis, I am even more in tune with what you are saying here. I’d have to sit down with the YUI guidebook for about a day before I could even understand how it works. In doing so, I would be forever altered in my design because I’d be using a system that would make me work inside a box. I enjoy thinking outside that box, which is why I’m most certainly NOT going to be employing YUI on any of my sites.
Thank you for putting up with me.
I think you’re being rather unfair here. You can get all the benefit of the YUI CSS in a 5.2k file, that’s a great thing!
YUI leads the way on efficient front-end code, and it’s very modular, so you only need to include what you’re using.
Not really true, the look of a site is far more than the layout. When you get down to it, all sites have a few basic layouts (even with all the different methods they use). However, grids.css is meant for you to get the layout sorted, and start doing the actual look ‘n feel yourself.
That main reasons I’d be less than happy using it are that you’re using classes like
.yui-gbrather thancontent. The complexity of changing the CSS to match you’re HTML is too great (and would mean you don’t benefit from updates).Also, it’s not valid CSS. The impact of this is largely mitigated by their comprehensive testing for now, but it’s not a road I want to go down.
This must include the templates along with the css files, perhaps a smattering of JavaScript to correct some of the more blatant IE flaws. No, I have no arguement here, you’re correct, I am being overly unfair, but I was trying to break it down into it’s extremely basic components and this is all I found.
Again true and again I’m being overly dramatic by claiming a cookie cutter look. This has far more to do with the knowledge of the web designer than the layout template itself. Even the basic layouts don’t look all that similar to one another. I think my point here is that if you accept YUI’s methods and do not change them (column widths are static), you are going to be constrained.
As for the rest of what you said, we are in total agreement. Changing the YUI grid to match my code would be arduous, painstaking, and full of tripwires. I’d rather write the code myself, it would take less time. I also like using more descriptive css tags while keeping them semantically neutral, something that Molly taught me, plus it helps when someone else is reading your code.
The main point about my post above was to point out some misconceptions about the YUI model itself and to concur with your assessment of not building a CSS framework model for any site. I’m actually using a less comprehensive reset-fonts-grids in my own template to achieve a similar result, but I’m also using methods that are more friendly to potential users than the YUI model. (i.e. header, footer, column1, navigation, etc.) All that’s left is for me to write the documentation and I’ll get it up there.
Christopher, did you ever complete the documentation and post it? By the way, the ~40 min video on YUI CSS was useful to me, but then I’m a newbie. The speaker did address the IE 0.9759 pixel discrepancy.
Semantically neutral, you say? I thought it was a plus to use semantically informative class tags? The alphabet soup of YUI class names bothers me. Also, while Yahoo uses YUI on many pages, why not their home page? I notice too that Yahoo pages aren’t doing a sterling job of using and , e.g., to benefit themselves with the bots.