Hi there
I'd like to know what the general rules are when working with divs to create a pure css layout (if there are any). I've been reading a bunch of tutorials and yet I'm having a huge headache trying to get my layouts to work the way I want it to.
Tables seem so much easier to work with but I'd like to expand my skills a little with front end coding.
Please help this frustrated coder
Only one rule from me.. Don't set out to "work with divs to create a pure CSS layout", unless you're entering some wannabe-elitist competition. Use whatever's appropriate and whatever works best: tables, frames, etc.
Nothing but a table does what a table does, and nothing but a frame does what a frame does. Those elements would have been W3C-deprecated in the last recommendation if they were redundant, and they are certainly not redundant. There is no suggestion by anyone worth listening to that the table or the frame tag are, or will soon be, deprecated*, and there is no reason to punish yourself by ignoring these valid, useful, elements. Just don't use tables for anything you can do easily in CSS ( note 'easily' ), and avoid frames like the plague unless you're making a certain kind of site: frames are great for offline API documentation minisites, and sites that are supposed to be read like books, but they are, of course, quite awful for most sites.
The font tag was deprecated, because it's redundant and difficult; don't use the font tag.
In a way, it makes me laugh that certain people took this WAI guideline so far: http://www.w3.org/TR/WAI-WEBCONTENT/#gl-table-markup, yet will blissfully ignore the rest of the WAIs recommendation, to the detriment of many. One can create a usability atrocity without using a single table, frame or font tag; and equally, one can create a blissful user experience with a frame and some layout tables. It really depends who's making it, and even more so what it is they're making, not so much what they're making it with.
Ask yourself this. Why don't you want to use tables? If you can come up with a good answer and you actually believe it yourself, then I guess you should look around for the latest "Semantic Web 2.0 Best Practice Eyecandy Coding Styles Ultimate Pro in Four and a Half Days" kinda book.
I'm sorry I can't be more overtly helpful. But, to me, your request is like asking how to drive from A to B using only left turns; when B is to the next right. Now, of course, a driving instructor might want you to do that and there's nothing wrong with left turns: but there's more to driving than taking left turns, and a driving instructor who only teaches left turns doesn't teach how to drive. Learn the latest revision of CSS in its entirety, and learn (X)HTML in its entirety; that's my best advice to you. Practice with all the elements, all the techniques, and all the browsers.
If you are unforunate enough to have a client who wants you to only use divs: I'd be mighty suprised, since few design clients even know what a 'div' is. If you have a boss or manager who wants you to only use divs, try and find out why, and try and appeal to sense; unless the web changed yesterday, there's no written recommendation from the W3C or anyone else worthy that says that the only morally taintless XHTML element is the 'div', or that it's good practice to use only the div. If you absolutely have to use divs for some reason, everywhere and for every layout; then cry, I guess, because it's very hard ( if not impossible ) to make certain layouts without tables; and if it's hard or impossible to do with divs and easy to do with tables, its nearly always unecessary to do it with divs**.
-----
* Anyone who claims to you that "frames were deprecated because they aren't in W3C (X)HTML strict" clearly doesn't have a clue how frames work, and thus why it doesn't matter that frames aren't in W3C (X)HTML strict.
** It's also the case that certain div tricks used to make the page look right actually worsen the linearized form of a page, making the site LESS readable to screenreaders. If you don't believe me, download a few screenreaders, and try them out on all of your code.
Thank you MattEvans. Your response has been, by far, the most entertaining response I've had since joining Daniweb ;)
And no, I don't have any intention of becoming some elitest web developer ;)
I've just seen a lot of, and herd of, talk about pure CSS layouts and couldn't understand how anyone achieves it. I'm still yet to find a resource that explains it completely
>> I've just seen a lot of, and herd of, talk about pure CSS layouts
I have also heard a lot of this talk. I can't imagine a CSS-only layout, since these layouts do use a few (X)HTML elements ( div, p, span, ul, strong, em, etc.. )*. So, I will use 'no tables' for what might be called 'CSS-only', and I don't need a special word for normal coding practice, because it's normal coding practice.
* don't get me wrong, these are all great elements.
For certain layouts, it is perfectly feasible, even elegant, to use minimilistic markup and it is most certainly the case that not every layout needs a table.
Many of the 'no tables' pages are fixed-width -- as is Daniweb -- the entire content is set at some defined width ( suitable for the majority of users, but smaller than the available visible width on an average display ), this makes it easier to use positioning and strictly-defined sizes for elements. 'No tables' design also favours sites without complex non-flowing layout ( text and pictures, newspaper/magazine-esque pages ); sites where alot of the layout is made of vertically stacked blocks ( like Daniweb again, although, there used to be tables here in places [ yep, there still are ] ); and sites that are sent to small devices, since reduced layout works well there. Some of these sites are indeed really pretty, and examining source code is a good way to see how a specific design was achieved.
As soon as you want things such as same-sized blocks dependant on inner-content height, horizontal sequences of blocks that don't jump onto new lines when the window resizes or the target browser has a slightly amplified font size, small column layout sections that don't break when the content gets too wide in one column, widths partially or totally dependant on the browser window, and mixtures of fluid and non-fluid areas; it gets more difficult to completely avoid tables. It is of course, sometimes possible to create 'fixes' for many problems that arise, but it really does depend on the case in question: a rule for non-jumping relatively sized horizontally arranged blocks might be different depending on how many blocks you have, other elements on the page, the currently available browser versions, the shade of the moon... etc. As such, there aren't many useful guidelines or one-size-fits-all rules for 'no-tables' design.
There are, as I'm sure you've found, a myriad of little tricks to eliminate some tables in source code. In my opinion, if the markup required for a non-table trick is more than 2x larger and more complex ( 'complex' is difficult to measure, but if it looks mad and breaks easily, it's probably too complex ) than than the markup for a table that performs the same trick, use the table, otherwise, use the non-table. There have for some time been plans for a new CSS version. When this comes out, things may change or improve with regard to layout as specified in CSS.. but judging by the time it took all of the modern browsers to agree on the interpretation of the last CSS version.. ah.. it could be a long time before it's feasible in production code.
Perhaps in some cases, tables can be avoided by adjusting the layout plans themselves, but, sometimes they're not so easy to change ( I think most clients would prefer you use a table or two than reject the stunning design they just had produced at cost ). Sometimes -- this was especially true with Firefox1-2 vs. IE6* -- certain 'no tables' layouts "just break" on one certain browser and work fine on others, due to inconsistencies in rendering engines. Occasionally the workarounds to such issues that don't involve tables were/are more ugly than throwing away CSS and using only <font>. This issue has got a little better though, as the present standards have been adopted, and I'm sure it is set to improve.
** Apparently Firefox was right, but that didn't really matter since neither were the same.
Perhaps in some cases, tables can be avoided by adjusting the layout plans themselves, but, sometimes they're not so easy to change ( I think most clients would prefer you use a table or two than reject the stunning design they just had produced at cost ). Sometimes -- this was especially true with Firefox1-2 vs. IE6* -- certain 'no tables' layouts "just break" on one certain browser and work fine on others, due to inconsistencies in rendering engines. Occasionally the workarounds to such issues that didn't involve tables were/are more ugly than throwing away CSS and using only <font>. This issue has got a little better though, as the present standards have been adopted, and I'm sure it is set to improve.
Your signature says it all ;)
What the W3C wanted us to stop doing is using tables to make margins and borders.. At one time, this was the only way to do margins and borders that worked on all browsers.
My rule is:
If I need a rigid structure, I use a table.
If the structure can be allowed to float, I use divs.
Since frames are not in XHTML 1.0 Strict (which employers want to see), I don't use them.
I believe that page layouts should be designed with divs and tabular data should be designed with tables. Our page design is CSS-based. Our forum listings, because they include columns of tabular data, are table based.
I don't think it's any harder to create a fluid CSS design than a tabular CSS design. DaniWeb is fixed width and tableless. DaniWeb's cousin, ProgrammingForums, does include tables, but its outermost border, which is fluid, uses the same technique as on DaniWeb, where it's fixed.
The reason I chose to go fixed width on DaniWeb is not related to it being a CSS-limitation or any harder to do with CSS. It was actually originally based on the fact of using images ... the navigation menu would look too stretched out and weird at fluid width, as would a bunch of columns, especially ones containing advertisements. Also, the quick reply message area needs to be a fixed width, so there's little point in making the page width fluid and everyone just seeing a big gap between it and the ad. So yeah ... it was really purely aesthetic.
>> I don't think it's any harder to create a fluid CSS design than a tabular CSS design.
It's hard, but not impossible, to create a tabular design without tables, and it's hard, but not impossible, to create a fluid design without... fluid. O_o ( meaning, of course, it's hard to create a fluid design with only tables ).
If you have a design, then you have a design; there's a tool for every design, within the bounds of reason. My only gripe is that there's no reason to for someone to inflict a limit on design potential ( or ease-of-implementation ) based only on hype and misplaced elitism.
You can't say Daniweb is table-less =p I see your tables. You can only say something like; it's ' low in tables', or even '98% table-free'. I myself don't value 'table-free' as a claim; for obvious and oft-stated reasons, so, good on you x100 for using tables to present tabular data.
> You can't say Daniweb is table-less =p I see your tables.
DaniWeb isn't tableless. DaniWeb does have a tableless layout though. By that I mean the container that everything is in, and all of the columns, are created tablelessly.
I never use tables for the outside container. I use tables when I want the structure to stay in row and column order and scroll (instead of wrapping elements to lower locations) when the window width is less than the smallest possible width of the row contents.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.