YUI Grids CSS framework considered harmful.
Note: Please realize that this post was written in 2006, and a lot has changed since then–including YUI Grids. I am not too familiar with how the framework works now, but I am told it’s much better than it was when I wrote this article. Also note that I am not against all CSS frameworks and am even known to use them occasionally myself.
So yesterday I published a post defending frameworks, saying that if they helped you out: use them. Well that was before Dustin mentioned that Yahoo’s created a CSS Framework. I checked it out…and after having done so, I now take back some of what I said yesterday.
The problem
The biggest problem with Grids CSS is that it basically forces you to use unsemantic markup. Here’s an example straight from their site:
<div class="yui-main">
<div class="yui-g">
<div class="yui-g first">
<div class="yui-u first">
<!-- your content here -->
</div>
<div class="yui-u">
<!-- your content here -->
</div>
</div>
<div class="yui-g">
<div class="yui-u first">
<!-- your content here -->
</div>
<div class="yui-u">
<!-- your content here -->
</div>
</div>
</div>
</div>
You’d use code like this to produce the 4 units in this layout.
That’s a heckuva lot of divs. That’s like…divitis on steroids. In fact, lets take a look at the following code:
<table>
<tr>
<td>column one</td>
<td>column two</td>
<td>column three</td>
<td>column four</td>
</tr>
</table>
Compare that to the YUI code. Add a little CSS, and they will produce the same effect. Sadly, the table actually requires less code–and I’d say is just about as semantical as what Grid CSS is forcing you to do.
Why?
Because correct me if I’m wrong, but it looks like Grids CSS is merging content with presentation. In other words, this framework is undermining what CSS is for. In order to achieve a certain layout, one has to stack div after div, applying un-semantical class after un-semantical class. We’re really setting our styles in our HTML. Certainly, if we change the stylesheet we’re not stuck with a certain layout–but to create the layout we did have to compromise our HTML.
A four column layout with CSS really isn’t that complicated, and hardly requires that kind of code.
So in saying so…
If somebody makes a CSS framework that cuts out the work for some hacks and browser quirks, that’d be great. But no framework should have to require unsemantic code and force a developer to use HTML in order to achieve styles. Granted, somethings such as curved corners can require a few extra elements. But this is just ridiculous.
I’m sorry to say it, but I’m not impressed. 












You have a solid point Elliot. The way you need to look at it though is that this framework is defining certain microformats that are neither semantic or unsemantic. They’re just static classes that can define a grid. It’s helpful in the sense that if you need to create a “grided” website that needs to support a chaos amount of layouts, this grids.css file is going to save you a ton of time. Otherwise you’re left in the dust creating style sheets upon style sheets.
On your basis of just using this for developing a normal website, then I’d say hey, I know how to make a website, what do I need a grid kit for? That’s not what it was designed for. In 99% of cases for just developing some blog website, you won’t be needing a kit for that. That’s understandable.
Interesting, Nice article Elly.
@Dustin: True, the framework itself simply defines the classes. But in order to really make good use of it one’s going to end up coding HTML in order to achieve a presentation. I’d venture to say that really, if you’re using grid.css in the way that the documentation explains, you’re basically writing tables only using divs plus a few extra containers.
There may be a better way to use it, but that seems to be the gist I’m getting from the examples and explanations in the documentation.
Nested DIVs are only necessary because of IE’s wacked box model. If you don’t use nested DIVs then you have to write a ton of extra CSS to make sure it renders properly in IE 5-6. Yahoo just chose to create their framework to be old-IE-browser friendly for obvious reasons.
Why not use tables then? Because they’re not as accessible (supposedly) and because they render slower than nested DIVs. Eventually this will be cleared up…and then we’ll have some other IE issue to deal with.
This grid layout framework is surely quite unsemantic. But I think it’s easy to use and not so problematic if you aren’t constantly redesigning. At least we all use unsemantic id- or class-names, think of “header”. Yes, it is a header inside, but isn’t it called header because it’s on the top of the screen (and markup, too)? The semantic web as you descripe it is not possible at the moment, and yahoo is using a group of “proprietary” microformats. The benefits, however, are that these microformats are only a subset of offical standards and not violating them.
Your example shows impressive whats possible, and you’re right that the markup is oversized for a simple five colum layout. but if it gets more complex and there are different column widths and column structures on a site, this modal grid framework could show its strengths.
Hey Elliot, nice site. Sorry to be off-topic here but I thought I’d visit and say hi. I’ll be adding you to my Netvibes page here shortly.
Nice article. I’m just wondering why is Yahoo! doing this? I mean, giving codes and everything. I mean, how can someone learn if everything is spoon fed?
@All: Some good thoughts.
It’s obviously treacherous ground, so thanks for sharing.
@Brad: Hey.
Thanks for popping by.
@fatfingur: They’ve been doing a JavaScript framework for a couple months, and I guess they wanted to be the first to try a CSS one.
Hello,
Thanks for taking a look at the YUI Grids CSS system I authored. I respect your skepticism, but heartily disagree with your assessment.
Using DIVs for structure is appropriate (in fact, explicitly recommended by the W3C), semantic, and not an example of divitis. I’ve discussed this in more detail on my blog in an entry called: On Appropriate Use of DIVs, or When Divitis Doesn’t Apply
Thanks,
Nate
YUI team,
YUI Grids author,
Yahoo!
I accept your argument that YUI Grids are not as semantic as they could be. However, at the risk of being heavy-handed, I would like to point out that tables are to web accessibility what staircases are to a building’s accessibility.
Your argument is akin to saying “It takes fewer steps for me to get up the stairs than to walk the ramp. Since stairs are more simple structures, they are easier and faster to build, you should use stairs instead of ramps.”
Semantic markup is largely an academic debate, and affects how machines read markup more than humans. Tables, on the other hand, have noticeably negative effects (slower page loads, more confusing to hear in a text-reading browser, more difficult to maintain with complicated layouts etc…).
I’m surprised that anyone would advocate for table-based layouts over YUI Grids on the basis of semantics given the context.
I always see the “tables require less markup than grids” argument applied to either a) trivial examples – like two column layouts – or insanely complicated examples that would take a ton of markup regardless – like 4 column examples.
Rarely do I see a comparison of grids to tables or grids to custom CSS for a real world design. From experience I can says in real world examples that
– tables require more markup
– custom css requires less markup, but is very difficult to then change major aspects of the page without going back and changing the document structure
– Yahoo Grids makes working on teams with people of various skills much easier. CSS-P is not a system; it’s a collection of tricks to get pages looking right. It’s very easy to teach team members a system. It’s very hard to teach them a collection of tricks and techniques.
And, most importantly, Grids can be made more semantic by adding to it! Many people wrongly assume that their content must go inside the divs required by Grids. They usually write code like this:
...
when they could be writing
..
In fact, you’ll find that in only two instances does Grids add extra layers of markup complexity over most custom solutions:
You have to wrap your main block in and you have to nest two 2 column grids to get 4 column layouts.
The former gives us source order independence in all browsers, the latter a complex layout.
p.s. You let us use basic XHTML, but it looks like you stip out code blocks…
div class’=”yui-b”
div id=”secondary_navigation”
…
/div
/div
vs
div class=”yui-b” id=”secondary_navigation”
..
/div
[...] CSS frameworks in general, and grids.css in particular, have taken some heat, but I think that the basic concept has been accepted. The “non-semantic class names” argument is specious, in my opinion, since the meanings are defined by the grids microformat. The “more code” argument is also a bit off, since the verbosity is actually easier to parse and manage once you get used to it (speaking as a 90’s-era table-master.) Also, downloading code is usually faster than parsing/displaying it—and divs typically render faster than tables. [...]
[...] You should be aware that these frameworks are often criticized for bloating the code with non-semantic markup and generating too many unnecessary classes, IDs and div-containers in CSS. Yahoo! UI Library also provides a detailed documentation with numerous examples, tutorials, cheat sheets, templates and tools. [...]
[...] You should be aware that these frameworks are often criticized for bloating the code with non-semantic markup and generating too many unnecessary classes, IDs and div-containers in CSS. Yahoo! UI Library also provides a detailed documentation with numerous examples, tutorials, cheat sheets, templates and tools. [...]
[...] You should be aware that these frameworks are often criticized for bloating the code with non-semantic markup and generating too many unnecessary classes, IDs and div-containers in CSS. Yahoo! UI Library also provides a detailed documentation with numerous examples, tutorials, cheat sheets, templates and tools. [...]
I’ve been thinking for years now to make my own Framework one that I could reuse from time to time, but never had the time until now.
I’m still working on it, I would much suggest on making your own framework, rather than have google and yahoo dictate things for you.
My Framework is still a work in progress, but I’m going to try and simplify things.
I think I also use non-semantic mark up at times but I’ve learned it the hard way.
When using divitis I always make it to a point to use these only when I need a top border image a bottom image border and a middle one specially when making faux columns or plain old boxes.
Write a comment here. CSS
Write a comment here. Styleshieet
Since this is a somewhat old post, I could assume that when you wrote it Yahoo User Interface wasn’t really so mature as it is today. Sure, the Grids CSS forces you to use some un-semantic code, but (at least to me) the really interesting part of YUI it’s Reset, Base and Fonts, which are purely CSS and really save a lot of work.
[...] YUI Grids CSS framework considered harmful. | Elliot Swan YUI Grids CSS framework considered harmful. May 10, 2006 . You should be aware that these frameworks are often criticized for bloating the code with [...]
I’ve only just discovered the YUI CSS framework, but as I understand it they’re not forcing anyone to use unsemantic markup, they’ve just provided a useful, flexible and cross-browser-compliant microformat for quickly setting up page layout using grids (yui-g) and units (yui-u), etc.
I think it’s pretty neat.
If I were to use the YUI CSS framework then I’d simply add IDs to the appropriate DIVs to give it semantic meaning, since IDs are unique to each element.
[...] Ho scritto tableless… brrr! Non mi son sbagliato infatti la pi grossa critica che viene mossa contro questo sistema la dubbia semanticit del codice che si deve produrre per ottenere i risultati voluti. [...]
[...] I’m somewhat known for speaking out against CSS frameworks. However, I have to come clean: I’ve become quite a fan of BluePrint [...]
[...] should be aware that these frameworks are often criticized for bloating the code with non-semantic markup and generating too many unnecessary classes, IDs and [...]
@ Fat Fingurs, I think it’s more a case of saving time for designers rather than an out-and-out beginners teaching aid.
I don’t think I would go over to using a CSS framework, just as I prefer to code HTML and JavaScript manually, because although a framework can save time initially, when errors occur it can be a bind trying to figure out a fix from a layout that was auto-processed rather than created by ‘you’ the designer from the ground up.
I can see a place for CSS frameworks in shaving off some time when in a hurry to get a project complete though.
hi buddy…I get what you are saying but YUI grids to me is an simple, easy to use, lightning fast solid foundation for website projects, i can whip up a framework almost instantly and know that it will render perfectly in every browser, saving a lot of work…
Totally agree, yui grid is just a “styleshit” and works only in very basic layouts, for example you CANT have sublevels of grids and finaly you write more code than using table. So I wonder if its just business operation or if there is a plus value??
We just started using YUI grids as part of a portal that we are building. We have a database person, graphics person and a backend person trying to put this together. Previously, we had put together a couple of sites with hundreds of pages using tables and Dreamweaver templates. Those sites are a pain to change, and to make matters worse, we have been asked to make them more accessible. Let’s just say that we are not using tables for anything but tabular data from now on. It makes no sense to do otherwise. CSS makes a lot of sense, especially for dynamic sites that change all of the time, but it is a pain learning all the browser quirks when I have several other things to keep up with. YUI has saved us boatloads of time. When we want to move a sidebar to the other side of the page, it’s a simple change. YUI also lets us put the main content area up at the top above all of the other columns where it belongs. The greatest advantage is when the new guys come in, we simply point them to the YAHOO site for documentation and leave it at that.
David, but that means developer must learn Yahoo! grid lib in more than basic HTML, so its really a waste of time I found. I mean, what is the plus value of that? What I can do with it I cant do with basic HTML? Nothing.
Thomas — Grids does let you nest grids. Also, “basic HTML” shouldn’t be controlling the presentation. The CSS required to drive this level of flexibility is far from trivial. I’ll admit that I was initially skeptical (I’ve been doing this stuff by hand for over six years) of YUI and CSS frameworks in general, but I’ve been especially impressed by YUI. It offers a lot of niceties that can be tricky to get right initially (like getting footers to place themselves correctly without the use of clearer divs) and is also fairly stable. I can change my layout from a fixed with design to a fluid one by changing a classname and it still works across browsers. Even if I change the font-size. And resize the window. No matter how much content I have in either module. And I can place the units in any order I want for SEO and accessibility purposes.
These things are certainly possible to code by hand and having a deep knowledge of how it all works together is still essential (especially if you want to stray away from some of their template presets), but in general I’ve found that it reduces a lot of the headaches I would have otherwise while maintaining the same standards I would have for my own, hand-built websites.
Yes but I have the feeling you have never used YUIGrid, because, okay you can change css class to change all your HTML (color,and position). BUT the CSS classes of YUIGrid are totally fixed, I mean, once you have done all your HTML layout with it, you will never change it, so its totally the same than static HTML. BUT you have to learn more to get the same result AND you have to download an extra file and you make your HTML heavier because of CSS rules instead of use basic tables …
And I am not sure that change the order of your HTML change a lot about SEO.
Thomas,
You can easily add to the YUI Grid classes with your own custom css definitions. I don’t think anyone is claiming YUI Grids is a panacea or something that everyone should be using, but it can be used by web site shops that don’t want to repeat building their own frameworks (which is what I found myself doing). YUI Grids already has the browser testing done (for the base framework anyway) and the documentation readily available.
I can understand that people designing a singular blog template may not want to use it or it may seem “hard” for some people to learn, but I think to claim that people aren’t using it is absurd since you have already demonstrated your lack of knowledge of YUI Grids in thinking that you couldn’t nest them.
Best wishes,
Matt
I’m finding YUI Grids CSS to be quite easy for non designers to grasp, and that is one of the major reasons for us to use it. Now if we could just ditch the traditional box model, that would be something
True. What’s funny is that there is some thoughtful commentary on this original post which wasn’t very thoughtful (paradoxically, the author later comes out in favor of the Blueprint CSS framework–which I like too–a framework which also doesn’t let you create a pure tableless layout without “extra divs”).
Nice article, though I think you’re missing an important point. CSS3 (or 4) may eventually make frameworks obsolete, but not today.
YUI grids are a foundation for web applications, not simply a document style sheet. For instance, the four column grid you showed can be manipulated with javascript to display in any order by adding or removing the “first” classnames as needed.
Secondly, the grids provide a way to automate the layout, a strong requirement of web applications. This is especially true when pages are required to evolve in real time. If markup does not have structural divs and a predictable css rules, a developer might have to modify many interrelated styles just to add a single element asynchronously.
Using table code for layout is the very definition of mixing presentation with content and is not semantic, whereas using spans and divs for layout within markup is exactly what those tags are for! I might point out that your table code requires more markup to make it equivalent with the YUI grid including classes and don’t forget the cellpadding=0 etc… the grid is far better semantically.
In the end, I think that YUI grids make markup more readable from a developer’s prospective, more easily manipulated with javascript, easier to maintain, and at the same time, more cross-browser friendly and more accessible than using sparse html and stylitis… yes, too much style, not enough markup is often more cumbersome and difficult to maintain than a judicial use of divs.
I’ll concede that tructural markup should be kept to layout only (divs for rounded corners is javascript territory), but YUI does a good job of that. Check out the YUI sample application to see what you can do with an extra div tag or two.
*structural even
I think there’s a common confusion of terms going on just about every time I see someone attack grid based layouts. Maybe this will help:
1) For the most part (ignoring semantic-ish tags like code and blockquote for the moment) HTML is for adding “structure” to the content it contains. That’s it. Structure is comprised of three things: a) Hierarchy, b) Linear Flow, and c) Grouping [with divs].
2) CSS is for enhancing this underlying structure with: 1) Positioning, aka “layout”–which is NOT the same thing as structure!, and 2) Styling / Presentation. You could add limited UI if you consider some of the a:hover techniques, but for the sake of brevity I’ll ignore those.
The point is, CSS is *for* adding layout & presentational elements, NOT for adding semantics (which is the domain of microformats and certain XML schemes). Though I agree, it’s nice when you can add in some semantic meaning as a bonus to whatever else you’re trying to accomplish with CSS.
Personally, I like to intermingle both approaches by adding supplementary ids and classes which describe the semantics of the content I’m working with.
Thanks everybody for all of the great discussion that’s gone on here for the past three years. CSS frameworks have advanced quite a bit since I first wrote this post, and I feel it’s important to note that this was written about the very first grid framework attempt ever, so much of what I said may not apply to the current frameworks. I added the following to the beginning of the post for any first-time readers, and I thought I would re-post it here as well:
Note: Please realize that this post was written in 2006, and a lot has changed since then–including YUI Grids. I am not too familiar with how the framework works now, but I am told it’s much better than it was when I wrote this article. Also note that I am not against all CSS frameworks and am even known to use them occasionally myself.
Again, thanks for reading and taking the time to participate here, and I hope you’ll continue to do so. You can always subscribe to the blog if this kind of stuff interests you and you’d like to continue in awesome discussion.
Hello Elliot,
I don’t think that your new disclaimer is sufficient (and no, I do NOT work for or have any affiliation with Yahoo). It’s not that Yahoo YUI Grids or CSS Frameworks have evolved and that they are better than when you first wrote this article. It’s that you made some mistaken claims about YUI Grids, misunderstood it’s full benefit and didn’t properly use some of your terms (as many of the comments here demonstrate – including one from the author of YUI Gridsd).
I think a better disclaimer would be that one should read the comments after (or instead of) reading my article because they shed a great deal of light on the purpose, benefit and advantage of using a CSS Framework in general and YUI Grids in particular. In short, fess up – YUI Grids is an extremely clever Framework that benefits many web developers.
A few things:
- CSS Frameworks have evolved. I know this, because I’ve used them. Yahoo also knows this, because they’ve updated their framework since this post and have notified me of it.
- The code I posted for how YUI Grids works is how it was. I copy and pasted it from their own website, and I am not going to take back what I said about it. However, I hear that it’s better now, and I am guessing the YUI Grids that you know and seem to love is this newer one, not the one this article is about.
- The comments do hold an awesome discussion on YUI Grids and frameworks in general, but many of them are from people discussing the current YUI Grids, not what the article is about. YUI Grids might be fine now, I do not know for sure. Funny you mention how you’re not from Yahoo!, because I have been in contact with them about this post in the past and they nicely asked (not required) that I put up a note similar to the one I have up now. No one from Yahoo! has ever asked that I disclaim my entire article, and I see no reason to do so, either.
you dont understand a thing bout css man, it was a waste of time reading this…using tables to build a layout is totally anti-w3c conventions….lets give u a moment for studying…
Hmm… Pretty sure that was the point of the article. Glad to know you read them before commenting!
[...] should be aware that these frameworks are often criticized for bloating the code with non-semantic markup and generating too many unnecessary classes, IDs and [...]