C
Chris
Anybody know of a good, online tutorial explaining how to use CSS instead of
tables?
tables?
B
Barry Pearson
Chris said:
CSS and tables are not in conflict or competition! You can use both, and the
vast majority of web pages in the world *do* use both.
Have a look at:
http://www.alistapart.com/topics/css/
http://www.mako4css.com/Tutorial.htm
http://www.w3schools.com/css/default.asp
http://www.projectseven.com/tutorials/css/css_td/
A problem is that designing a page to use CSS layout isn't a methodical task
(yet). It needs knowledge of browser bugs & non-compliances, and the hacks &
workarounds to overcome these. The theory of CSS will get you so far - after
that, your capability will tend to be determined by how many of those
non-compliances & hacks you can put to effective use. I have found this
useful:
http://www.richinstyle.com/
Strictly, you can't replace tables with CSS, because CSS2 doesn't support
"columns". (You could try to emulate columns using CSS's "display" property,
but IE doesn't support what you need). So, typically, what you are doing when
you use tableless-layout, is either implement a different visual design, or
find a way of doing with CSS what it wasn't actually intended to do. Over the
last few years, many such ways have been discovered & published.
You also have the option of using simple tables, under the control, sometimes
extreme, of CSS. Some examples are here:
The CSS Patio Garden
http://www.barry.pearson.name/tableaux/
N
Neal
CSS is a fantastic tool for layout but let go of the idea that it's a
drop-in replacement for tables. Best bet is to learn CSS thoroughly, and
then experiment. I haven't seen a tutorial which gets terribly technical
in creating whole page layouts, unfortunately - a hole needing filling,
IMO.
K
Kris
Barry Pearson said:
Strictly you can, because CSS2 does supports column display.
So you are saying that strictly IE does not support it.
Then we're clear on that.
B
Barry Pearson
[snip]Kris said:
Where?
CSS2 is about boxes. Columns are about separate "things" having the same
height. One of the things that has exercised the minds of experts over the
last few years is how to make CSS-layouts appear to have the characteristics
of columns. There are lots of tricks, trying to make CSS2 do what it wasn't
intended to do - support columns. (I have used a number of those tricks!)
*CSS3* has a working draft of a columns module. But it is not the same as
table-columns. CSS3 would spread a single set of contents over multiple
columns. It is not intended to put separate sets of material into columns with
the same height.
I know of no CSS feature, or proposed feature, that is intended to support
columns in the same way, or even close to the same way, as table-columns.
Separate containers that have the same height, perhaps down to a footer. With
the potential for borders & backgrounds that have this same height. Perhaps
"display: table" techniques?
W
Whitecrest
No it means that 80%-90% of your customers don't support it. Now we are
clear.
D
DU
Chris said:
W3C tutorial
Tableless layout HOWTO
http://www.w3.org/2002/03/csslayout-howto
Why tables for layout is stupid:
problems defined, solutions offered
http://www.hotdesign.com/seybold/
CSS techniques:
Look Ma, No Tables.
http://glish.com/css/
Tables My Ass
http://www.htmldog.com/ptg/archives/000049.php
Tables Vs. CSS - A Fight to the Death
http://www.sitepoint.com/article/tables-vs-css?ct=1
DU
D
DU
Barry said:
If a vast majority of web pages in the world do use invalid code,
improper nesting, etc..., would that be a good reason to do so too?
Using CSS for layout requires knowledge of CSS to begin with. It is the
absence of good tutorials on CSS, how to use CSS, etc.. that is more
detrimental than browser bugs.
Even if browser have bugs - and they do -, there is often a workaround
using code which is entirely valid. Browsers don't have bugs everywhere
and on everything. I'd say amateur web designers are the ones not
putting honest efforts into coding their pages: they rely on
copy-N-paste anyhere/everywhere they can, they rely on Front Page 2002
or older and on old (or not old) versions of DreamWeaver which promises
fast and easy results, etc..
The theory of CSS will get you so far - after
A wide majority of sites relying on table designs also resort
shamelessly and enormously on nested tables: does that makes sense? I'm
talking about as much as 50% of all webpages on the web here.
Can you just give me a good example of usage of nested tables?
A wide majority of sites use <font>, <center>, align and valign
senselessly, everywhere, insane amounts of <spacer> or <img
src="spacer.gif" ...>, etc.. You never address these issues and these
issues are closely related to the easy and mindless usage of tables for
designs to begin with.
DU
T
Toby A Inkster
Barry said:
"display:table" and friends (which is part of CSS 2 and 2.1, is supported
in Gecko since before Moz 1.0 and in Opera since 5.x and will presumably
be part of CSS 3) can exactly emulate tables that don't use (row|col)span.
..table { display: table; }
..tablerow { display: table-row; }
..tablecell { display: table-cell; }
<div class="table">
<div class="tablerow">
<div class="tablecell">1</div>
<div class="tablecell">2</div>
</div>
<div class="tablerow">
<div class="tablecell">3</div>
<div class="tablecell">4</div>
</div>
</div>
or, if you only need one row:
<div class="table">
<div class="tablecell">1</div>
<div class="tablecell">2</div>
</div>
(the row container is implied)
B
Barry Pearson
[snip]Toby said:
You snipped my question "Perhaps "display: table" techniques?"! As you say,
that does emulate tables, and proper column height is achieved in those
browsers.
I wonder why it is still in CSS2.1, given its lack of support in IE? It says
"But most of all CSS 2.1 represents a "snapshot" of CSS usage: it consists of
all CSS features that are implemented interoperably at the date of publication
of the Recommendation". It doesn't say "only those features", but it surely
isn't in any true snapshot of usage, and this leaves me wondering what the
CSS2.1 criteria are.
B
Big Bill
Er, guys....<barbarian>why not use tables?</barbarian> Oh, by the way,
hear that knocking? That's me and the boys at the gates.....
BB
B
Big Bill
B
Barry Pearson
DU said:
I'm talking about tables, the subject of this thread. They can be used in
valid Strict code.
You weaken your argument by bringing in unconnected issues. You simply give
people the opportunity to say "I don't use invalid code or improper nesting,
so that is OK".
[snip]
I agree that good tutorials about general use of CSS are desirable. But the
subject of this thread was using CSS instead of tables, and that is a specific
use of CSS. For that, even if you know the rest of CSS, you need that extra
knowledge I mentioned.
But it goes further than that. Where are the tutorials that say how to get
from a visual design concept to the combination of mark-up & CSS needed to
achieve it without using layout tables? Where is the method or process that,
given some arbitrary (but plausible) visual design, enables an author to
choose the wrapping & nesting & sequencing of the top-level elements that will
give the CSS the structure needed? A method that will steer the author to
appropriate combinations of floats, positioning, and normal flow? Perhaps this
is covered in some of the good books on the topic?
I suspect most of the table-layout pages being uploaded every day are being
developed by professionals, not amateurs. The sites that matter most surely
are?
Those amateurs are likely to have limited audiences. Family & friends, people
pursuing the same hobby, etc. Are they communicating with their audience? If
so, fast & easy is the right approach for them.
[snip]
That isn't an argument against tables. In fact, unless you show problems with
nested tables, it isn't even an argument against nested tables!
If you want to make a point about the risks of bad layout tables, for example
that they blow apart at large text sizes, and/or they don't linearise well and
can become inaccessible, then I agree. But those cases are not a reason to
criticise use of simple layout tables that don't have those particular
problems. It is not either/or, and that is the point I was making earlier. CSS
& tables are not on conflict.
They are different topics. They are often *not* closely related. Those of us
whose target is validated Strict code know how to separate out these very
different arguments.
See what I said above about weakening your argument. You won't convince
someone to stop using layout tables by adding in the subject of <font>, etc.
All you do is the invite the response "I don't use <font>, so that is OK
then"!
W
Whitecrest
Your logic is wrong.
Most developers use a combination of Tables and CSS
Most developers use invalid code or improper nesting
Therefore Using tables and CSS is invalid code.
Sorry that is not good logic, nor is it a true statement.
Not the absence of tutorials, but rather the absence of motivation to
learn from the developers. Many just don't want to learn it because the
old way seems to work anyway. In the long run, these people will end up
losing.
Why bother asking, would you ever look at any code he offers and say;
"damn, he was right, That is a awesome use of nested tables...."
These issues revolve around bad usage of table layout. But you don't
necessarily have to lose the tables to fix it. The use of a little CSS
would solve almost all of the issues.
B
Barry Pearson
Whitecrest said:
Spacer-GIFs are often associated with bad use of tables. (Although I have used
those for sites where I wanted things to work right without CSS). But the
other issues are nothing to do with tables.
In fact, spacer-GIFs are a symptom of the fact that tables are compatible with
"the Dao of the web"! Tables are designed to adapt to the *user's* conditions,
in the best philosophy of the web. If the user increases the text size, or has
different fonts, the table cells will naturally adapt their size. The table
will naturally try to fill the user-chosen viewport width to minimise vertical
scrolling, while also trying to avoid horizontal scrolling. And do so in a way
that minimises or eliminates overlapping elements in the way that can happen
sometimes with CSS-positioning.
Tables defy an author's attempts to control them directly. They are not "dream
mark-up" for "control-freak" authors who want to dictate the final rendering.
In fact, they are a nightmare for those authors. The fact is, authors are
unable to reliably control tables directly. If they really want precise sizes,
they have to control the *content*. Spacer-GIFs are one way of controlling the
content, by adding content that can be controlled. Another way is to wrap the
content of a cell in <div>...</div> then control that <div> with CSS! Authors
who want precise control *have* to use CSS, and use it to control things other
than tables. (They will still fail in some cases, but that is a separate
matter).
Tables have one merit for page-layout. They make it easy & reliable to layout
material in rows & columns. Authors would be wise to limit themselves to that
use. Beyond that, when it comes to controlling widths & heights, forget
tables. CSS is the nearest you will get. Control the content with CSS, and the
table will automatically adapt to it as desired. Or - take a more relaxed
attitude to widths & heights. That is probably the real lesson.
When I see someone like DU lump <font> & spacer-GIFs in with tables, then I
don't see a criticism of tables. I see a criticism of an old-style of web
development, or of inexperienced authors. That is fine, but it says nothing
about any modern use of simple tables, accompanied by a few gentle nudges from
CSS.
W
Whitecrest
True they don't have anything to do with them. But what I was commenting
on, is that the issues he brought up could be fixed with CSS, losing the
table design is not required to fixing the problems.
Totally agree.
R
rf
Whitecrest said:
<chirp>me too</chirp>
I have on occasion used an HTML table to lay out, well, not strictly tabular
things on a page, if only because there was nothing else available to
realize the design. Sure, CSS tables would have but, well, there is IE
In any case what are CSS tables if not, well, tables.
<aside>
There is a really good reason to use CSS to control things like font face
but is there a really good reason for using CSS tables over standard HTML
tables? Both technologies, after all, simply lay out things in colums and
rows. One could argue that one should not use CSS tables for anything other
than tabular data
</aside>
Sometimes the real modern four wheel drive can simply not make it up the
mountain side. Sometimes we have to use a tried and tested horse.
B
Barry Pearson
rf wrote:
[snip]
Chuckle! Aside or not, it is a good point.
Tony provided an example of the use of div-elements & display:table (etc) to
achieve the equivalent of <table> using CSS. But, it didn't really do just
that, did it? It used HTML+CSS, not just CSS. And many times, people, who
might claim to be separating presentation/layout from content/mark-up, have
carefully provided sufficient extra mark-up, in the right order, to enable
that CSS to work. (That is why W3C give that warning that for CSS to work as
expected, you need a valid document parse tree. CSS-positioning doesn't
normally work in isolation).
He wrote 3-levels of nested mark-up, that appeared to have a one-to-one
replacement of the table-oriented elements with divs. Then he made those
behave like the table-oriented mark-up using CSS. Gosh - should we now replace
header & paragraph mark-up with divs, and then use CSS on those to make them
behave like headers & paragraphs? Or do something similar with list-mark-up?
No, of course we shouldn't! But where do we draw the line? Some of my
tableless-pages have several divs that are there to give the CSS something to
work within. And I'm not the only one.
I've been experimenting with the opposite. I start with table-mark-up, then
use CSS to transform it into totally different things. I can stick the cells
to the corners of the viewport, or put the right hand column on the left, or
have a diagonal table. It is a bit of fun, but it has serious purposes. One is
to show that use of table-mark-up is compatible with the separation of
presentation/layout from mark-up/content. See:
http://www.barry.pearson.name/tableaux/
I believe the way to judge these things is in comparison with the aims of the
web site site, which is presumably to communicate with the audience. What are
the consequences today? Next year? With disabled people? At what cost & risk?
Those are good questions.
[snip]
[snip]I have on occasion used an HTML table to lay out, well, not strictly
tabular things on a page, if only because there was nothing else
available to realize the design. Sure, CSS tables would have but,
well, there is IEIn any case what are CSS tables if not, well,
tables.
<aside>
There is a really good reason to use CSS to control things like font
face but is there a really good reason for using CSS tables over
standard HTML tables? Both technologies, after all, simply lay out
things in colums and rows. One could argue that one should not use
CSS tables for anything other than tabular data
</aside>
Chuckle! Aside or not, it is a good point.
Tony provided an example of the use of div-elements & display:table (etc) to
achieve the equivalent of <table> using CSS. But, it didn't really do just
that, did it? It used HTML+CSS, not just CSS. And many times, people, who
might claim to be separating presentation/layout from content/mark-up, have
carefully provided sufficient extra mark-up, in the right order, to enable
that CSS to work. (That is why W3C give that warning that for CSS to work as
expected, you need a valid document parse tree. CSS-positioning doesn't
normally work in isolation).
He wrote 3-levels of nested mark-up, that appeared to have a one-to-one
replacement of the table-oriented elements with divs. Then he made those
behave like the table-oriented mark-up using CSS. Gosh - should we now replace
header & paragraph mark-up with divs, and then use CSS on those to make them
behave like headers & paragraphs? Or do something similar with list-mark-up?
No, of course we shouldn't! But where do we draw the line? Some of my
tableless-pages have several divs that are there to give the CSS something to
work within. And I'm not the only one.
I've been experimenting with the opposite. I start with table-mark-up, then
use CSS to transform it into totally different things. I can stick the cells
to the corners of the viewport, or put the right hand column on the left, or
have a diagonal table. It is a bit of fun, but it has serious purposes. One is
to show that use of table-mark-up is compatible with the separation of
presentation/layout from mark-up/content. See:
http://www.barry.pearson.name/tableaux/
I believe the way to judge these things is in comparison with the aims of the
web site site, which is presumably to communicate with the audience. What are
the consequences today? Next year? With disabled people? At what cost & risk?
Those are good questions.
N
Neal
<aside>
There is a really good reason to use CSS to control things like font face
but is there a really good reason for using CSS tables over standard HTML
tables? Both technologies, after all, simply lay out things in colums and
rows. One could argue that one should not use CSS tables for anything
other
than tabular data
</aside>
A most important reason to use CSS over <font> is to allows changes in
presentation without having to go through all your HTML pages. This is
even more relevant for the <table> markup.
As far as not using CSS tables for non-tabular data, remember, no one
complains that you shouldn't want that presentation. It's the semantics,
the markup, that is objectionable. CSS tables are optional by definition -
while HTML tables are a part of the page structure, and only rendered
differently in a handful of small-screen devices.
In other words, CSS table styles request that the browser renders the
material in a way that looks like a table, even though our markup does not
semantically call this material tabular.
Or we have to hike up, or take a helicopter. Or bag it entirely. Yet I
don't see how this is at all analogous to the CSS/HTML table discussion.
THink of this. HTML tables are like whipping your boy with a belt. CSS
tables are like glaring at him, and reaching as if you're going to take
off your belt, and the kid runs to his room in fear. You get the same
results either way, but you never actually have to abuse the markup, I
mean child.
K
Kris
Where?[/QUOTE]
<http://www.w3.org/TR/CSS21/tables.html#value-def-table>
A little test:
<http://www.xs4all.nl/~apple77/columns.html>