I have seen all these 'grid' type css frameworks and I'm still a tad confused as to what they do.
I understand that they help you quickly create a page since the layout is already defined for you, but do these frameworks make certain things MORE difficult?
It depends on how you typically use CSS to set up your pages. They wind up using less semantic classes ("indent-12" vs. "rail-content") if that's important to you, but they also solve a lot of layout issues people tend to run into.
They take care of the need (mostly) for floats, which can break designs faster than... well, something fast.
What they make harder, however, is customization. If you don't take the time to learn just what those classes mean, it can be hard to make things look just the way you want because your CSS rules might clash with something you didn't know about.
They are great as a way to switch from tables to CSS-based design, and they also really help implement the "grid" theory of design, where things line up and are in horizontal and vertical rhythm.
Take 'em or leave 'em (I left them, but sure played with them a bit)
EDIT: I used both 960 and blueprint, about 8 months ago or so. Unclear if significant changes have taken place since then.
Grid 960 is a CSS framework. Mainly, it can help you develop faster the mock-up of your page.
You can learn more about it in this tutorial.
Enjoy!
The idea is to stop thinking in terms of %s or pixels and start thinking in terms of columns. Grid systems automate the implementation of column-based positioning. My favorite is Fluid 960 - a grid system that stretches its columns to entire available width.
I have looked into various CSS frameworks in the past and I think they are aimed at removing a lot of the nitty CSS bugs that come across between browsers, if you ever tried to hand roll your own CSS you will know the issues that come up. If you have your own template that you have developed I would stick with it, that is what I ended up doing. I am familiar with it and it is very lightweight.
A 960 grid is a framework that should be implemented from the initial design stage. It helps both the designer and developer create clean organised UIs. In my experience the 960 grid system (http://www.960.gs) has helped a lot as it will allow me to create a formatted page quickly without re-writing any css files no matter what a client asks for. Typically I implement CSS styles like the following
.marginLeft20 { margin-left: 20px; }
.oneColumn {
float: left;
width: 60px;
}
This means I can make a div with the above classes applied
<div class="oneColumn marginLeft20">This is a oneColumn example</div>
If you need anymore info on grids I would recommend http://www.960.gs
Grid systems/frameworks are sort of like a sandbox with all the shovels, pails, sand and shapers ready made, so that all you have to do is pick up a tool and start making your castle.
Burt makes a great point about rolling your own CSS and all of the browser issues you run into. It can make for a very frustrating experience depending on the project you're working on!
While the framework you're using may have some limitations, it alleviates some headaches also.
Related
After much reading on the subject, I have decided to use a grid when creating my websites. I understand previously grids had a problem with bloating the HTML with unsemantic content.
Now this problem can apparently be avoided by using a grid such as "The Semantic Grid System". However, up until this point in my learning I have used pure CSS, and I understand I would need to adopt LESS were I to start using this particular grid system.
Is this the case with all others as well? Are there any that avoid cluttering up the markup, that also do not require LESS?
Should I even be bothered about finding one, or should I just go ahead and use LESS anyway? Obviously I am still learning so if LESS is something I should definitely be getting into then I will happily learn it and implement it.
You should be able to implement any of these grid systems in a compiled form without touching any LESS files.
But LESS will make your life a lot easier anyways - so yes you should take a look at it.
in absolute terms, you can't go any more semantic than HTML5 standards. Everything else is relative and depends on you and your use, nobody will give you an award or congrat you because of your subjective approach to semantics. This being said, you can obviously use any grid system with just regular CSS, and you can also use LESS or SASS or OOCSS or whatever, I think you're mixing and confusing everything here.
Bottom line is: try to find an adequate way to work, some kind of process or scaffolding with which you're comfortable and that will be it, there's not a real answer to your question
Ultimately, I like to code my own CSS. I hate it when I have to conform to someone else's naming conventions... especially when they have no real meaning. However, I am attracted to the fact that a mobile site is pretty much ready to go with a framework.
Now, I've seen several comparisons between 960.gs and Blueprint, but LESS is never involved in those debates. Why not? Am I missing something? To me, it seems that LESS does pretty much the same basic things.
http://lessframework.com/
Anyone care to discuss?
LESSFramework is a css grid system that supports responsive webdesign principles. Thats the area of webdesign that strives to make one website design to support all browsers from mobile to large screen. The lessframework grid system adapts it's layout to the available screen real estate.
That's where it really differs from classic grid systems like 960.gs or blueprint.
LESS Framework is fairly new too, that's probably why you don't see it that much in reviews or comparisons.
If you want to compare them you'll have to figure out what you really need from a css framework.
960.gs is a pure grid layout system, nothing more ... but the most widely used one.
Blueprint is a grid system that goes a little further, it also offers typography and form styling
LESSFramework is a grid system that's only really usefull if you are aiming to create a responsive layout. If you are not you'll probably be better off with 960.gs
960.gs and Blueprint are grid systems.
LESS is a CSS pre-processor (aka LESScss).
Comparing it to them makes no sense, they do totally different things.
Update:
You seem to be talking about something different from LESScss, a grid system called LESSFramework.
I am leaving this answer here so people reading this question will see the different projects and what they are.
I'm working on a web app that currently has a table-based layout. Ideally I'd like to go to pure css, or failing that, a hybrid tables-and-css layout* .
I've banged my head against the wall trying to understand css layouts and positioning. The main problem I'm encountering is that, depending on the state of the app, I have different things appearing in a 'section' of the layout -- what might be contained in a div or table. For instance, I might have some text and links, and then after user interaction, there might be a form, a table, some images, different text, etc. Anytime I find a css solution, it is for a fixed-element layout, or works in a specific case, etc. They're not robust solutions, in other words.
From this In Search of the One True Layout, the author about "Vertical placement of elements across grids/columns": "Designers face the choice of relying on elements being a particular height, resorting to tables or simply not bothering." Is this true? In my app, I can't rely on elements being a particular height.
Do I fall back on tables when I have elements of various hieghts ( which is quite a bit of the site, actually). I noticed that quite a bit of sites done by well-respected people and organizations use tables for layout in certain places, and not just for tabular data! This site included.
The chances are that there are CSS techniques to achieve what you want, but they may not be obvious if using CSS for complex layouts is new to you.
In your case, to 'get it done', I would recommend a hybrid type layout, and not feel bad about using a table to layout the pieces of the application that require those particular behaviours.
If it is particularly complex and difficult than a table might be the best and simplest approach even for the CSS expert.
Dynamic heights are only a problem if you need to implement a special effect of soem sort or a background image and oftent there are ways around that. It really depends on the Visual Design and what needs to be done to make each "block" flexible to use. Sometimes things arent possible but most of the time they are - they jsut tend to add complexity to the markup. But even that added complexity is easier for me to understand than nested tables :-)
My advice if you want to get things done and spend a ridiculous amount of time on css layout, browser compatibility, CSS reset, fonts:
write simple, valid, semantic HTML
use a simple CSS framework (like blueprint). You will rely on a simple grid system for positioning and layout.
add CSS classes to your HTML
add your custom CSS for colors, backgrounds...
Please reconsider using a table layout 'to get it done'; you will be disappointed, especially if you want to add some JS magic later.
I use CSS layouts for my web apps. But, my apps don't have wildly varying information, so I can set the content area and not have to worry about the layout looking "off" because a column is way out of balance with the rest of the content.
If you're having trouble with CSS layout and positioning, I'd suggest tables first, learn more about CSS/HTML positioning, and then convert your layout LATER. I'm sure that it's made for a frustrating experience learning CSS on a "real" project.
In the meantime, get some really good sources for CSS: books by Andy Budd, Simon Collison, Eric Meyer, et. al. Also, go to their blogs and dig into the archives. A really good book for CSS layout, positioning and general use is Beginning CSS Web Development by Simon Collison from APress. All the ins and outs with great working examples.
Having asked this question How to reach CSS zen?, I now understand that the issues I have are mostly related to positioning. I've found some articles telling that CSS is not always good enough as a layout system.
http://echochamber.me/viewtopic.php?f=11&t=40154
http://www.flownet.com/ron/css-rant.html
http://blog.workaround.org/2009/03/17/dont-abuse-css-for-page-layout/
Do you as CSS designers limit yourselves upfront to designs that CSS can handle? Should I avoid things that seems perfectly easy are in fact difficult to do with CSS?
Of course you limit yourself. As a designer, you should always think about the medium you're working with. If I were designing a magazine ad, I wouldn't be thinking about animations or video. There are certain rules you must adhere to, and it doesn't make sense to ignore that.
But of course, rules were always meant to be broken.
Why?
If you are "designing", why would you limit yourself based on a the limitation of one technology? When you design your site, you should always try to achieve the most usuable interface for the user.
If you do limit yourself, then you are just asking for the site to not be used, and then what's the point of creating it?
I don't limit myself upfront to any designs that CSS can handle (within reason of course), just figure out your design and there will be someway that you can get it looking right using CSS, but it might involve a lot of hair pulling, especially if IE6 is involved!
When implementing a web design (assuming I've got an image/drawing of what the site will look like) I always follow these steps:
I look at the design and determine what components it has. Examples are navigation areas, headers, content areas, and so on.
I implement (X)HTML that can represent the content areas without really taking the design into account (there are certain things such as content order that I use the design to determine.)
I start making the CSS and images needed for the site to look the same way it did in the original design document. Depending on the complexity of the design, I might come up short of elements to use for styling the page, and may end up adding elements that don't really make sense for the content. I try to avoid it as much as possible, though, and I try to create the elements in a way that isn't obtrusive to the content.
As you can see, I never limit the design to the capabilities of CSS. CSS comes last. Now, depending on the complexity of the design, it might not look exactly like it did in the original design document, but the goal is always to make it as identical as possible, while still maintaining clean HTML so that the design can easily be updated in the future.
Most layouts I find can be done with CSS. There are a very few exceptions (normally to do with verically centering text).
For me the main factor which limits my designs is a reluctance to use huge background images. If an effect can't be done by combining/repeating a few tiny bg images I tend to reject or tweak it. Eg a diagonal gradient on a box with curved corners which could be any height might fall into this category using CSS2.1
Almost every painter limits themselves to paint on canvas, almost every sculptor makes 3D shapes from stone or clay or metal...
But there's also the few who dream new dreams and create new things. Some flop, some shine.
Should you limit yourself based on what CSS can do with layouts? Not completely. I say dream big.
Once you've got your dream design, either figure out how to create it, find a technology other than CSS that can do it, or go start inventing!
You can do absolutely almost anything using CSS 2.1 as far as layout. Its a complete pain in the ass that has no reason to ever exist, but you can do rounded corners (using background images), gradient backgrounds (more background images) and all kinds of other bloated crap you don't need all together and still not completely destroy the semantics of your HTML.
Doing all that garbage and still attempting to be standards compliant reduces usability, because its the designers who need round corners and other frivolous crap and not the users. Usability tests have confirmed this. Sites that are bloated to accommodate presentation and usability at the cost of semantics and efficient fail in usability tests compared to their competition. I work for a website that gets several million visitors a day and I have seen the results of our usability tests.
CSS provides a very good way to create an overall design that easily can be changed by small changes in one CSS file, and instantly applies the design changes to all your pages. Of course there are things that are tricky to do with CSS, and in those cases you might want to do it in other ways, but even if your layout is mainly based on CSS, doesn't mean that you can't do some special parts using other technology! You can mix!
So you don't limit yourself when you go for CSS. You just make use of a powerful technology that can be used in perfect harmony along with others!
My one of web designer friend still making sites with table but he use css very nicely and I also use css nicely but with <div> and i face cross browser problem in layout more than my friend.
and i given some reason to my friend about cons of <table>. read my whole discussion with friend?
I - you site will be problematic with screen reader
My friend - OK, but i never got any call from any client regarding this.
I - you will devote more time to make any changes in layout, if changes comes from client
My friend - I don't think so, but if it is then show me how can i save time with <div>?
I - your sites will not work well with search engine.
My friend - it's not true. I've made many site and no problem with any site or client regarding this
I - layout is old way, non w3c and non standard way.
My friend - what is old and what is new, Who is W3C i don't know, What is standard? Whatever i make works in all browsers, it's enough for me and my client will not pay for standard and W3C guidelines rules
I - Your site will not work in mobile browsers
My friend - No problem for me, my client don't care about mobile phone
I - Your sites are not accessible?
My Friend - What do u mean not accessible? Whatever i make works in all browsers. my any client never asked about accessibility
I - You will not get more work in future, with table?
My friend - OK, no problem when clients will not accept site with table then i will learn about div based layouts in future.
My questions?
Is it still true, to make cross
browser layouts for desktop browsers
using table+css is easier then
div+css?
What is the benefit for developer to
use DIV+CSS layout in place of
<table> layouts if client would not
mind if i use ?
Personally I find it much easier to think about the layout in terms of independent chunks rather than a table where the cells are tightly coupled to each other and dependent on each other. Having used both methods extensively, divs are easier when you've learnt about them.
Tables are a nightmare to maintain, too. If you want to add a column you need to make sure other rows aren't affected. Even with CSS, the HTML for tables is still very bloated and difficult to understand "at a glance" (particularly with nested tables).
I'd be surprised if tables really are a huge problem with screen readers (one would hope the software is smart enough to deal with all types of web pages). However, you should take all reasonable steps to make sure the site is accessibility to all, since it's the law.
Mobile phones can display tables fine. The only problem here is if you want to create a separate mobile stylesheet it's virtually impossible to remove the column format.
Finally for SEO, it makes no difference. SEs say time and again that the validity of code makes no difference.
Laying web pages out with tables is probably a bit more intuitive for most people than CSS.
Depends on the layout though. Deeply nested tables can get pretty hairy. CSS layout options (basically float, at the moment) are a different way of thinking about page layout. I find it easier than tables nowadays, as I’m used to thinking about layouts in terms of CSS floats.
IE has a few float-related bugs. I think they’re the main source of cross-browser issues with CSS layouts.
Using a CSS framework makes creating layouts with DIV's a cinch!
I personally use 960 Grid System, but theres plenty of others out there too.
CSS is more flexible and cleaner. Period. I personlly think that 3 nested divs with meaninglful names is much more readable than 3 table tr td s right? There is a reason it's the new accepted standard. I use tables. But only when displaying tabular data. Once you learn the tricks in CSS you can write super clean div structures that are completely cross browser compatible.
I remeber a time I felt like your friend. It was mainly based out of fear. Don't be afraid. And remember it's us developers that determine the future of code and browsers. Agree with all the other answers on here too. No matter how you do it (from scratch) or grid layouts, you'll be much happier with a tableless layout. And to agree with the above, thinking of the site as blocks helps a TON. Good luck!
As nobody mentioned this: HTML aims for semantic markup. That means, the tags you use have a semantic meaning.
So using table for tabular data is fine and the only way to do it.
But using table for layout contradicts the semantic meaning.
And the relevance of semantic should not be underrated as semantic is what the WWW is striving for now (Semantic Web). I know that Semantic Web and HTML are not necessarily connected, but I guess using HTML the right way can only help.
Creating appealing layouts with divs might be more difficult. This comes with the advantage of greater flexibility.
And as already mentioned, maintainability can be a pain with tables.
I personally try to keep my HTML files as semantically correct as possible, i.e. using the right tags for the right purpose. The look (which a layout belongs to) is a matter of CSS.
Btw. if you are searching for CSS vs tables get a lot nice comparisons (most in favor of CSS).
table layouts results in more html, more html results in more code to write and maintain, and less clarity for dom manipulations via js. the amount of css code will remain almost the same (I'm not talking about 2004 inlinestyle markups, that surely will dramatically reduce the amount of css). and there is always the better seo factor that speaks against table layouts. so it can't be easier if you fully understand css. maybe you need to clarify what browsers do you include in your "cross broswer" statement, since its not even self-evident to support ie6 and ie7 nowadays.