So I'm trying to create a simple header/content layout where the content part extends to the bottom of the window.
Doing it with CSS looks impossible, at without introducing too much complexity considering how simple is this layout.
Please tell me a SINGLE reason why I shouldn't do this
body, html { height: 100%; padding: 0; margin: 0; }
#h{ height: 150px; }
#tbl { height: 100%; }
<table id="tbl" cellpadding="0" cellspacing="0">
<tr>
<td id="h">header</td>
</tr>
<tr>
<td>content</td>
</tr>
</table>
And don't tell me about semantics and how tables weren't made for layout.
It seems most web designers today are masochists who spend hours everyday trying to build simple layouts in very complex ways because they like to torture themselves with things that don't matter.
I can hear you already saying "But... but... john using divs instead of tables is the latest hip thing to do, you don't want us to be mocked by the other web designers do you?"
We do not use table layout anymore because they are not semantic. Bots and screenreaders can not identify what the content is good for. Secondly you will want to separate your content from code for layout (distribution of duties).
Having an external CSS file will make your page much more easy to maintain. If you have 20+ pages which all have a table to keep content in, you will pretty likly have to edit all this documents for a redesign. If you use CSS and have a good document layout width identifiers you will only have to change one .css file to alter all your layout for good.
You have a question. You want to have a content area under your header item. That ok and indeed can be solved with more complex CSS if you want to, but not have to be.
Firstly you will begin width your header. You can use <div> for that or use the headings (h1-h6) items. Like that every bot will know > "Oh! a headline. Thats important!"
Lets structure your document:
<body>
<h1>Header</h1>
<div class="static-content">
<p>Content</p>
</div>
</body>
We have a headline and a div width the classname "static-content" for layout reasons. You can change this name to what ever you want (no whitespace and start width a alphabetic char) you can also add multiple classes, separated by white spaces.
here is some CSS
html, body {
height: 100%;
margin:0;
background-color: gray;
padding: 0;
}
h1
{
display: block;
padding: 20px 10px;
background-color: blue;
margin: 0px 0px 0px 0px;
}
.static-content
{
background-color: red;
padding: 10px;
margin: 0;
}
So. Like you can see in the fiddle here: http://jsfiddle.net/NicoO/rC66e/2/
Your content area can be red (like it is). But you also see the gray background. The element in the background is the body you can work with the body like nearly any div.
So you see, you already have stretched your content area to the bottom of the browser. If you want the red area to be on the bottom also, you have multiple options to realsise that.
See the fiddle here: http://jsfiddle.net/NicoO/rC66e/3/
There are also other ways to realise that.
Update. If you really want that red area to be big, you could try something like this:
http://jsfiddle.net/NicoO/rC66e/5/
This is not a really good solution because I don't know what you want to use it for. You just could style the body element and you are good to go. If you want more complex layout, you will have to addapt your CSS. The soltion in this fiddle is not generic as it should be. But it shows, that you can do a lot of things width CSS. Even if you don't really showed us your use case.
Edit:
You keep saying "why don't i just juse a two row table?". But on the other hand you try to alter this rule for the answer here. Why don't you just a heading and a paragraph? like <h1>Title</h1><p>content</p> You can add a background-color to the body element and be done. There is no reason to do anything else here.
Final Edit:
You have a valid point #John. sometimes CSS can be a pain. But it is far superior to table layout. For most common problems there are Tools like grown grid systems, that get the most of the problems out of the way. W3C is working on making CSS more powerfull and easy to use. For example with thew new display:grid; property.
If you really give css a chance and try to addapt a new pattern of thinking about the box model, it will help you a lot. With HTML and CSS you can just write what you reall need without having to have a clumsy table all the time.
I'am sorry if I offended you. But i'd recommend you to weight the pros and cons of table vs css layout. There is pretty nice stuff around like responsive layouts, that you will not be able to fully use width these old techniques
My personal view:
Using tables for layout is like using coffee to stay awake. Don't do it too often. Maybe once in a while.
And certainly we shouldn't hassle people who use table-based layouts, especially when there's no sound, cross-browser way to do a particular layout in CSS.
That said...
1. Tables make it harder to design for multiple screen sizes at once
Responsive layout is important these days. Having different CSS rules for different viewport sizes, applied to the same HTML code, is a good way to adapt a site to all screens.
For very simple designs, though, a table-based layout may work at any screen size.
2. Tables can interfere with search engine indexes, screen readers, and other automatic web page parsing
In other words, not so good for SEO and accessibility.
However, it's worth pointing out that Google has recently been optimizing its search algorithm to distinguish between layout tables and data tables.
And there are some techniques like <table role="presentation"> to help screen readers handle tables, although those hacks can get complicated.
3. Table-based layouts require changing the HTML markup when you want to change the layout
Again, it's nicer and more conceptually pure -- and often more maintainable -- to use HTML for content/semantics only, so you can leave the markup alone when you make design changes. But practically speaking, in a substantial redesign you'd often need to make changes to the HTML anyway.
In sum, I believe that guidelines and best practices are more useful than hard-and-fast rules regarding tables for layout. It's a balancing act, and there are situations where tables can be, overall, a better choice.
Related
Bootstrap's page about responsive design says this:
Responsive utilities should not be used with tables, and as such are
not supported.
Being new to web development, I am not familiar with what this is talking about. It seems that there is a general aversion to using <table>. Is this true?
Also, the quote as phrased doesn't make sense to me. Shouldn't it read like this?
Tables should not be used in responsive utilities, and as such are
not supported.
Tables are very structured elements. A <td> can only ever be a column. You couldn't change it to suddenly appear like a row or float it somewhere, etc., etc.
HTML, in responsive design, shouldn't define what something should look like (or where it should appear to a degree) that's CSSs job. the HTML should simply group text and other elements. So a HTML <table> and all it's associated tags breaks this paradigm.
CSS display now contains table like elements: How is a CSS “display: table-column” supposed to work? so this removes the need to embed <table> tags and allows you to use the more generic <div> tags and their like, thus now it's a <div> that looks like a <table>, there is nothing to stop you making this appear as something completely different simply by updating the CSS. You could even make it look different for different audiences, etc.
hope this helps a little.
It's not really true in the latest browsers, but traditionally it's been hard to unstyle a table in CSS to not have a table layout.
So while a table might be the correct semantic element for your tabular data, pragmatics meant that if, in some responsive design profiles, you want the data to be displayed in a linear format, it just couldn't be done, except by using JavaScript to rip the table markup out and replace it.
Try table, tbody, tr, td {display:block; } - (JsFiddle http://jsfiddle.net/Z26GF/) in various browser (e.g. compare IE10 with IE9 behaviour) to see what I mean.
(The more I learn about Bootstrap, the less I like it. It seems to encourage a number of bad HTML practices. This is one of them)
[Note: for those who may be confusing this question with "why not use tables for HTML layout", I am not asking that question. The question I'm asking is why is a grid layout fundamentally different from a table layout.]
I'm researching CSS libraries (in particular Bootstrap) for a project. I am a programmer rather than a web designer and I feel I could benefit from a library that encapsulates good design.
We all know that it's bad practice to use HTML tables to accomplish basic site layout because it mixes presentation with content. One of the benefits provided by CSS libraries like Bootstrap is that they offer the ability to create "grid" layouts without using tables. I'm having a little trouble, however, understanding how their grid layouts differ in any meaningful way from the equivalent table layout.
In other words, what is the fundamental difference between these two examples of HTML? Am I wrong in thinking that the grid layout is simply a table with another name?
<div class="row">
<div class="span16"></div>
</div>
<div class="row">
<div class="span4"></div>
<div class="span4"></div>
<div class="span4"></div>
<div class="span4"></div>
</div>
and
<table>
<tr>
<td colspan=4></td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</table>
The difference is that the first example is semantically marked up, assuming the data being marked up is not actually tabular. <table> should only be used for tabular data, not for any data which happens to be displayed in a layout similar to a table.
It is correct though that using CSS packages like Bootstrap, which require you to assign classes to HTML elements which are not semantic but presentational, reduces the separation of content and presentation, making the difference somewhat moot. You should be assigning semantically meaningful classes to your elements and use lesscss mixins (or similar technology) to assign presentational behavior defined in the CSS framework to these classes, instead of assigning the presentational classes to the elements directly.
Say:
<div class="products">
<div class="product"></div>
</div>
.products {
.row;
}
.products > .product {
.span16;
}
Note that I say should. In practice this is not necessarily always the more workable option, but it should be the theoretical goal.
I believe that CBroe comment is the best option, so I chose to clarify it.
Avoid div's. A div should be your last resort, not your first option. Instead, try to use Bootstrap classes on the actual elements. For instance:
<form class="container">
<fieldset class="row">
<label class="span4" for"search">Type your search</label>
<input class="span6" type="text" id="search" />
</fieldset>
</form>
It is a shame to use fieldset to contain a single field, but it is semantically best than using a div for the same thing. The HTML5 standard defines many new container elements, such as article, section, header, footer and many more. In some cases you will have to use div's, but if you minimize it's use then your code will be way more semantic.
The fundamental difference is that you can "reflow" the layout with Bootstrap for different display sizes simply using media queries without needing to change your markup. For example, I can decide that on desktops, I want your 4 divs to be on same row because user has high resolution wide display but on phones I want 2 dives on one row and next divs on next rows. So this way I can adapt my column count in each row using media queries. If you use hard coded HTML tables then it is very difficult to do this.
Having said that, I don't really like bootstrap implementation for the following reasons:
It has breakpoints hard coded in pixels. This means, as phones and tables advance in display resolution, your website may start showing unexpected layouts on those devices. Pixel count is poor proxy for display size.
It limits maximum used display area to 1170px which is again a bummer for users with nice wide displays they can actually use to see more content in your app.
Bootstrap's layout is not source independent, i.e., you can't change column order that is set in HTML. This is however more of a pedantic point.
The default layout is for very small resolution and higher resolution layouts trigger only when media queries fire, which IMO, is a poor choice considering phones will continue to have better resolution and sooner than later your website would have default layout set for outdated mobile devices.
Bootstrap layouts are not truly "worry free" in the sense that you have to read their fine print to see all the bugs and browsers they didn't see worthy of supporting but which you may care about. If you are targeting users in South Korea or China, you would be in for surprise, for example.
So, not everything is gold in bootstrap and their approach is not necessarily always the best possible (as an aside, one other thing I despise in bootstrap is their obsession with so called "jumbotrones" - those real estate wasting inconvenient in-your-face headers - which I hope community doesn't start taking as "new standard"). Personally I use CSS table layout (display:table) these days which has similar benefits as bootstrap without hardcoding <table> in my markup. I can still use media queries to rearrange rows depending on portrait or landscape orientation, for example. However the most important benefit is that my layouts are truly pixel or even percentage independent. For example, in 3 column layout, I let content to decide how much space first and last columns should take. There is no pixel or even percentage width. The center column grabs up all the remaining space (which is good thing for my app, but it may not be for others). In addition, I use ems in media query break points which bootstrap surprisingly doesn't.
I use the Bootstrap grid for page layout, tables for tabular data.
I think of the grid in Bootstrap, not as a grid in the developer sense, like a gridview control, but more in the design page-layout sense - as a grid to contain the page contents. And even though the Bootstrap grid could be also used to create a conventional grid containing tabular data, as deceze pointed out, this kind of grid is better suited for HTML tables - which are still acceptable to use in this scenario.
if you just use tables i think you will miss out on alot of flexibility in re-sizing your document for mobile/tablets without having to make a separate page for each device. once your table structure is defined all you can really do is zoom in and out.
While there's not necessarily much semantic difference between the two sets of markup (since the classes used by Bootstrap's grid system are indeed purely presentational), one very important distinction is that the grid system is much more flexible.
It would be very difficult, for example, to make your table-based layout respond to different screen sizes. There's no way to tell the browser to display one td element below another td in the same row. Whereas with the div example, that's easy to do, and the same markup can be presented in different ways even when the classes are "presentational" in the sense that they define the relative proportions and positioning of the elements on the page.
If I may, I'd like to summarize what I gathered from the other comments and the link explosion I experienced from this page:
The problem with using tables isn't the grid layout, it is the attempt to express it with HTML instead of CSS.
Bootstrap allows grid layouts through (mostly) pure CSS, which is why it is OK. The 'mostly' part comes because your HTML will still be contaminated by your layout data, but more subtly:
<nav class="span4"> ... </nav>
<article class="span8"> ... </article>
This is surely significantly more semantic and maintainable than the old tabular designs, but the 'span4' and 'span8' are still display-data embedded into our HTML. However, since design can never be truly be decoupled from our data (e.g., nested divs), this is a reasonable price to pay.
That being said, even this coupling can be broken, if you use some more modern CSS features provided by a pre-processed language such as LESS. The same example:
<nav id="secondary-nav"> ... </nav>
<article id="main-content"> ... </article>
Coupled with the following LESS:
#secondary-nav{
.span4;
// More styling (padding, etc) if needed
}
#main-content{
.span8;
}
This creates fully decoupled HTML and Stylesheet, which is ideal, because the HTML is cleaner and more readable, and redesigns can be made with less HTML modification. However this only works if you use LESS or some other CSS pre-processor, because CSS currently does not support mixins (AFAIK).
We already use LESS in my workplace, so I know I'll be pushing towards using this type of solution. I'm a very strong believer in semantic HTML and data-design decoupling. :)
Basically DIVs are DIVs & Table elements are simply table elements. The problem with tables is often just keeping track of all of the columns & the rows because it is ultimately a strict data construct. DIVs are far more flexible & forgiving.
For example, if you wanted to to take the four DIVs with the class that equals "span4" and just change them to a 2 column width, all you would need to do is adjust a wee bit of CSS for the outer class "row" and maybe the class "span4". In fact when doing DIVs like this I would avoid calling individual DIVs "span4" or some other number.
My approach would be to create a parent wrapper DIV that is called "rowspan" and the inner DIVs would have some generic ID like maybe "cell".
<div class="rowspan">
<div class="cell"></div>
<div class="cell"></div>
<div class="cell"></div>
<div class="cell"></div>
</div>
Each "cell" class could have a width of 100 pixels for example, and then the parent "rowspan" could be 400 pixels. That would equate to 4 columns in a row. Want to make it 2 columns? No problem! Just change "rowspan" to be 200 pixels wide. At this point it is all in CSS so it's easy to do without rejiggering page structure in the DOM.
But with tables? Not easy. You would have to basically re-render the table with </tr><tr> tags to create new rows.
Version with table, tr, td depends on browser algorithms - wrapping, dynamic width, margins, centering etc.
Version with div can be more easily tuned by css and scripts.
I want to do the following:
------------------------------------------------
width: 100%;
height: 60px
image center
image bottom/right
-------------------------------------------------
I used to do it with table:
<table border="0">
<tr>
<td width="25%"></td>
<td width="50%"><center>image center</center></td>
<td width="25%" valing bottom><div align="right">image bottom/right</div></td>
</tr>
</table>
but they say using tables for formatting is bad (Dunno why)
So is there any idea how to do the following banner? I heard there is absolute position, so mightbe the 2 images could be embedded to 2 divs
First off before I do any explaining I think you could use some visuals of just how powerful CSS can be...
CSS Zen Garden shows how using a different CSS style sheet can completely change the entire way a site looks (use theme links on the right side)...
http://www.csszengarden.com/
My own site supports multiple themes which you can instantly change without even reloading the page...
http://www.jabcreations.com/blog/?prompt=themes-official
1.) Tables are intended for tabular data only, think the nutrition panels on food labels if you're not sure where to start. Tables are great for tabular data because it removes the formatting issues however you should never put non-tabular content in to tables as it disrupts the context of the content to search engines and you should instead use division elements instead since non-tabular data tends to do anything except for be presented in a tabular fashion.
2.) The context of using either CSS background-images or (X)HTML img (image) elements comes down to what you're trying to do.
2.A.) CSS3 allows the use of multiple background-images however browser support isn't yet universal when considering browser market shares...
http://www.caniuse.com/#search=css3%20multiple%20backgrounds
...as time passes however IE8 and other older browsers that do not support this modification to the CSS background-image property will slowly disappear so it will only become an increasingly viable option.
2.B.) You can combine an img element and a CSS background-image together to get two images to display inside of a single element.
2.C.) You can use two division elements with the same styling (or lack thereof) and then give them each a CSS background-image.
Here is the generally relevant CSS code...
background-image: url(kittens.png);
/* Choose one or the other below */
background-position: right bottom;
background-position: center center;
I'll reiterate that tables for on-tabular data is exceptionally bad for styling. Once you begin to grasp how CSS works (cascading means rules on lower lines override earlier lines, so the same rule on line 10 will override the same rule on line 9, if they are the same rule).
By using CSS you're going to have so much more power to quickly implement changes across your entire site and you'll be able to implement changes quicker and move on to more important things.
This question already has answers here:
Closed 11 years ago.
Possible Duplicates:
Why are tables bad rather than css?
Why not use tables for layout in HTML?
What's wrong about creating templates with table?
i was just trying to help someone and i got one upvote followed by few downvotes because i suggested a solution with table: How do you select half the remaining width using css?
what i suggested was:
<html>
<head>
<title></title>
<style type="text/css">
TD.left
{
width: auto;
}
TD.main
{
width:1000px;
}
TD.right
{
width: auto;
}
</style>
</head>
<body>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="left"> </td>
<td class="main"> </td>
<td class="right"> </td>
</tr>
</table>
</body>
Tables aren't that great for layout. They are easy, but often you will spend more time trying to remove the space and get it just right. Learning to use floats and positioning will make future development really easy.
Look into the 960 Grid System. It's a quick and dirty CSS grid layout system that allows you to quickly knockout layout tasks that normally take a lot of time, plus they will reduce your overall CSS file size because you are able to use the same shared classes.
Thats pretty fast answered. Tables were used(for layouting) before CSS was somehow broadly supported by webbrowsers.
Tables consume more space
DIVs are more flexible for future layouts
DIVs are better parseable by search engines
The intended use for tables is row wise representation of strucutral data.
It is best practice to use css for layout. Using tables for layout is considered the old way of doing things. Tables were created for situations where you need to display data in a table format. A while back, developers started using them for page layout but we have since moved on and now use css to achieve much better results.
Usually when someone wants a template using CSS they explicitly do NOT want to use tables. CSS in a large part is supposed to make using tables to lay stuff out unnecessary.
Tables are good to display large amount of data formatted in rows and columns.
For website layouts the use of other elements is preferred, for example divs, because you don't need a table, tbody and tr tags, and you they aren't styled by default by browsers, if not only for margins or paddings. So you can easily move them and style them appropriately, and you will write less code also.
Edit
I don't like to separate tables from CSS like I'm reading here, if you use tables you can still style them using CSS. They can be styled the same way as other elements, you could also do other elements acting like tables for that matter. It's just that they need more elements surrounding them and so are less freely disposable.
Using tables for the layouts is a bad idea:
More HTML code
More CSS code
More time to make it Cross Browser
Not flexible at all
I would use table just for display data, like a grid
I generally use a manual process:
Look at the page, figure out the semantic elements, and build the HTML
Slice up the images I think I'll need
Start writing CSS
Tweak and repeat different steps as necessary
Got a better approach, or a tool?
I have a fairly natural way of coding. The key is to treat the page like a document or an article. If you think of it like this the following becomes logically clear:
The page title is a top level heading
Whether you make the site title or actual page title the h1 is up to you - personally I'd make About Us the h1 rather than Stack Overflow.
The navigation is a table of contents, and thus an ordered list - you may as well use an ol over a ul.
Section headers are h2, sections within those sections are h3s etc. Stack them up.
Use blockquotes and quotes where possible. Don't just surround it with ".
Don't use b and i. Use strong and em. This is because HTML is structural rather than presentational markup. Strong and emphasis tags should be used where you'd put emphasis on the word.
<label> your form elements.
Use <acronym>s and <abbr>s where possible, but only in the first instance.
The easiest: always, always give your images some alternate text.
There's lots of HTML tags you could use that you probably haven't - address for postal addresses, screen code output. Have a look at HTML Dog for some, it's my favourite reference.
That's just a few pointers, I'm sure I could think of more.
Oh, and if you want a challenge write your XHTML first, then write the CSS. When CSS-ing you aren't allowed to touch the HTML. It's actually harder than you think (but I've found it's made me quicker).
Well, when I build a website I tend to try and forget about the design completely while writing the HTML. I do this so I won't end up with any design-specific markup and so I can focus on the semantic meaning of the elements.
Some pointers how to markup things:
menu - use the UL (unordered list) element, since that's exactly what a menu is. an unordered list of choices. example:
<ul id="menu">
<li id="home">Home</li>
<li id="about">About</li>
</ul>
if you'd like an horizontal menu you could do this:
#menu li {
display: block;
float: left;
}
Logo - use a H1 (heading) element for the logo instead of an image.Example:
<div id="header">
<h1>My website</h1>
</div>
And the CSS (same technique can be applied to the menu above if you would like a menu with graphical items):
#header h1 {
display: block;
text-indent: -9999em;
width: 200px;
height: 100px;
background: transparent url(images/logo.png) no-repeat;
}
IDs and classes - use IDs to identify elements that you only have one instance of. Use class for identifying elements that you got several instances of.
Use a textual browser (for instance, lynx). If it makes sense to navigate in this way, you've done good when it comes to accessibility.
I hope this helps :)
I essentially do the same thing Jon does, but here are a few other ideas:
Use Guides in Photoshop (and lock to them). Figure out all of your dimensions for each box/ region ahead of time.
Collect all of your dimensions and color hex values into an info file (I use a txt file) that you can easily reference. This will reduce your alt-tab tax and selecting colors in Photoshop multiple times.
After all my Guides are in place, I slice out the entire website into my images folder, starting with photos and grouped elements, and ending with the various background tiles/images, should they exist. (Tip: Use ctrl-click on the layer preview to select that layer's content).
Notes on using Photoshop:
Use Guides or the Grid.
Use the Notes feature for any pertinent information
Always use Layer Groups for similar elements. We need to be able to turn entire regions off in one click. Put all 'header' content in one Layer Group.
Always name your layers.
You can put each page template in one PSD file and use nested Layer Groups to organize them. This way we don't have to setup all of our guides and notes for each page template on a site.
No shortcuts :) but everybody works slightly differently.
This tutorial that popped up in my feedreader yesterday shows the process from start to finish and might help people who have never done it before but as you are an old hand it's just about streamlining your own methods.
EDIT:
The listapart link certainly is more automated for 'flat' designs where both imageready and fireworks have had pretty good support from day one and it's got better and more semantic with every release but if you have a more complex design it's the twiddly bits that make the design what it is and these have to be done by hand.
I just thought it was worth pointing out that in addition to the excellent advice you've had so far I'd recommend getting a printed version of the design, using a red pen to mark up all the block elements on the design you think you can spot and sitting down with the designer for half an hour and talking through how they envisioned their design working for the use cases that don't fit the static design.
What happens when more text is put in the navigation?
Is this width fixed or fluid?
Is this content pane to the right fixed height or fluid? If it's fluid why did you put a background on it that can't be repeated?
You have a border extending down the page that breaks two otherwise connected elements. Visually it makes sense, but semantically I not can't just use an li to house both those elements. What do you think is more important?
It'll also help you spot potential problems that you might otherwise not have realised were going to be issues until your elbow deep in css.
Not only does it make your job easier after a few times doing it your designer will get a much stronger sense of what is involved in marking up their work - some designers have real trouble comprehending why something they think looks visually very simple will take a few days of css tweaking to make work.
Some of the designers i know, usually uses Illustrator to make the design elements.
This page shows how to do it a little more automated.
Also, get to know the "Layer Comps" feature. I use this for changing button states.
Create layer comps for normal, hover, and active.
In each of these, set up the effects/color overlays and visible layers which belong with that state.
Save for web: go to a different folder for each state, unless it's easier to rename each slice (otherwise your hover button slices will overwrite your regular slices).