Layers vs. Tables : what are advantages and disadvantages?

[Guest]

can you please tell me what the basic difference and limitations of
"Layers" VS. "Tables" What are the advantages of Layers, and what are
the advantages of tables, and what is the downside of each ? Couldn't I
just use "Layers" to put Text anywhere I want or even a picture, it seems
that layers are easy to move around anywhere on the page, so can you tell me
if there is any disadvantage in using layers. Thanks

Susu

 

[Murray]

Here's a post I have repeated (and updated) more than once here about layers
and tables -
you may find it helpful -

If you need to use layers, then use them. If you want to begin using
CSS-P
methods, then use them by all means! But learn how to use them first -

http://www.thepattysite.com/layer_laws.cfm

The word "layer" was first coined by Netscape when it introduced its
heinous
and ill-fated <layer> tag with NN4x. It has since been adopted by the
community to generally refer to absolutely positioned <div> tags, and
Dreamweaver has
propagated that usage. In fact, there is really no such HTML thing as a
layer, but for the purposes of this discussion let's use the
Dreamweaver/FP
sense of applying that term to absolutely positioned <div>s.

==============================
In plain talk, a layer is like a magic carpet - it floats above your page
content (any page content, including tables, images, text, etc.). It is
unaffected by page margin settings because it is not really *on* the page.
You can whisk it around on the page to provide motion (using timelines).
You can make it visible or invisible using any of the actions appropriate
to
your browser selection (like onMouseOver, onClick, onLoad, etc.). You can
dynamically clip or scroll the contents of layers to provide a windowed
effect within a page. Layers are wondrous constructs that let you bring
your pages to life! Get to know them - they are your friends....
=================

I would add in clarification and elaboration that layers are positionable
elements and as such allow you to put content at any location you desire,
regardless of the remainder of the content on the page.

The downside to layers is the flip-side of their real benefit. Because
they
are absolutely positioned, they will be static page elements, i.e., they
will not move to reflect changes in your browser viewport size *unless*
you
apply some custom javascript to the page that makes the layers move, or
*unless* you use
specific CSS-P techniques to make them move. There
is no native support in HTML for moving layers - that's why it must be
done
with custom js or advanced CSS.

If you consider that a 'layer' is really just a 'division' or <div> tag on
the page, and that you can use
CSS to position this <div> tag, as well as control the format of its
contents and how it interacts with
other content around it, then you can see how valuable it might be for use
as a page layout tool!
This impression is certainly true. As you become more familiar with CSS,
you will learn how to
replace a large part of your current page layout methodology with pure CSS
positioned page
elements. But it's something you should take your time with. It *is* the
way of the future, so at
some point we will all have to come to grips with using CSS in this
manner.

Some people use layers exclusively for page layout because of the ease
with
which they can be positioned. I do not recommend this approach for anyone
that is new to layers or to CSS in general because it can be confusing and
troublesome. This is partucularly the case if you will have multiple
layers, each
containing nominally uncontrolled/unstyled text. Viewers resizing this
text in their
browsers will see a disappointing overlap of paragraphs that is surely NOT
what you desire.

Tables, on the other hand, are most everything that layers are not! They
are flexible page elements, in that native HTML can center, or right or
left
align a table - in other words, they can float around on your page
depending
on the browser's viewport width. Although originally added to HTML as a
means of displaying tabular data *only*, tables quickly became the
principal
structural element used in page layout. They can be made rigid in order
to
provide a stable base for your page elements, including text, images,
Flash,
etc. They are easy to use and to learn (more or less), and behave in
(mostly) predictable ways across browser and platform combinations - but
there are quirks that must be learned to use them successfully. Luckily,
most of these quirks are discussed here daily. In spite of these quirks,
however, if you intend
to be a credible web developer, you must learn how to build stable tables
with
your hands behind your back!

So - to summarize...

If you want motion on your page, you must use layers. If you want bedrock
for your page layout, you must use tables at this point. Or not
(particularly when you
consider what you can do with CSS positioned page elements and NO tables
at
all - http://www.csszengarden.com).

Bear in mind that advanced use of these two page elements can
*significantly* blur these two criteria.

And remember, the use of one does not preclude the use of the other on the
same page.
Use them both if the spirit moves you.

There you go....

 

[Guest]

Thanks Murray,
I understand layers and tables much more clearly now, it seems that
layers have a disadvantage in browsers, which might distort my webpage,
so I will use them sparingly, thanks susu

 

[Murray]

Good luck, Susu. It's a truism of this business that the more you know
about HTML (and CSS) the easier all this will become.

 

[Kevin Spencer]

Hi Murray,

I have to take issue with a few statements in that article:

This is not necessarily true. Layers (divs) *can* be positioned at a higher
Z-Level than other elements, or a lower one, or none at all.

Who says that layers (divs) have to be absolutely positioned? This is simply
false, and misleading. In fact, you can actually use nothing but divs and
get the exact same effect as using a table, by creating a div that contains
other divs in rows and columns. Of course, this is much more difficult than
using a table for the same effect, but it illustrates the flexibility of
using divs.

Again, as I pointed out before, divs are not restricted to absolute
positioning. CSS properties such as width and height can be defined as
percentages. Therefore, this statement is also false.

Again, based upon the fallacious preceding premises, this conclusion has no
merit.

I suspect that this article was written some time ago. It looks like it was
written specifically with FrontPage's default behavior in mind. That is,
FrontPage, when you place a "layer" on a page, and position it by dragging,
resizing, etc, will use inline absolute CSS positioning. No doubt this was
done to make the program easier to use for those who know little or nothing
about HTML, but it does not in any way restrict one from using divs to their
fullest capabilities.

That said, I am hardly one to discourage the use of tables. Tables were
originally devised for a specific formatting purpose, and that purpose is
still arguably best achieved with tables. That is, if data is tabular in
nature, a table is just the ticket for formatting it. A table maintains
identical widths of columns, and heights of rows, regardless of what you do
to it. This coordinates the positioning of elements inside a table.

It is also important to note that in recent and upcoming versions of HTML,
attributes are being continually deprecated in favor of CSS, and the use of
external CSS style sheets provides the ability to both remove the layout
style from the content of a page, and to apply that style uniformly across
multiple pages easily. I have often maintained with Microsoft that Themes,
for example, could easily (and better) be replaced with external CSS style
sheets.

In conclusion, the advantage of using tables are (1) they require less
expertise to use than divs with CSS, and (2) they are best used for tabular
layout. The advantages of divs are (1) they are much more extensible than
tables, and (2) One can change the layout of a page without touching the
HTML if they are used effectively.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

 

[Murray]

In plain talk, a layer is like a magic carpet - it floats above your

This is not necessarily true. Layers (divs) *can* be positioned at a
higher Z-Level than other elements, or a lower one, or none at all.

Uhh - isn't that what I said? 8)

Who says that layers (divs) have to be absolutely positioned?

If it's not absoutely positioned, it's not a layer. Of course, this is
complicated by the fact that there is no cosistent definition of "layer" and
there is no HTML mention of them.

In fact, you can actually use nothing but divs and get the exact same
effect as using a table, by creating a div that contains other divs in
rows and columns. Of course, this is much more difficult than using a
table for the same effect, but it illustrates the flexibility of using
divs.

Certainly. Those are not layers, though.

Again, as I pointed out before, divs are not restricted to absolute
positioning.

Divs are simply containers, and can be used to contain anything else on the
page. I have never implied or stated that all divs have to be absolutely
positioned - and if I did, then it's indeed false.

Again, based upon the fallacious preceding premises, this conclusion has
no merit.

It's your interpretation of what you think I was saying that has no merit!
8)

I suspect that this article was written some time ago. It looks like it
was written specifically with FrontPage's default behavior in mind. That
is, FrontPage, when you place a "layer" on a page, and position it by
dragging, resizing, etc, will use inline absolute CSS positioning. No
doubt this was done to make the program easier to use for those who know
little or nothing about HTML, but it does not in any way restrict one from
using divs to their fullest capabilities.

Actually it's as valid now as it was when it was written with Dreamweaver's
default behavior in mind! 8)

It is also important to note that in recent and upcoming versions of HTML

There is no upcoming version of HTML. It's all XHTML now, baby....

In conclusion, the advantage of using tables are (1) they require less
expertise to use than divs with CSS, and (2) they are best used for
tabular layout. The advantages of divs are (1) they are much more
extensible than tables, and (2) One can change the layout of a page
without touching the HTML if they are used effectively.

I have no issue with this. But the original question was specifically about
"Layers" (a specific kind of div) not divs (the generic container).

 

[P@tty Ayers]

This all depends upon what the original poster means by the word "layer",
Kevin, since the term isn't found in HTML. You seem to be defining it as a
synonym for "a positioned div", which isn't accurate.

When the word is defined as Murray defined it (quoted just below here), his
post is factually correct.

"The word "layer" was first coined by Netscape when it introduced its
heinous and ill-fated <layer> tag with NN4x. It has since been adopted by
the
community to generally refer to absolutely positioned <div> tags, and
Dreamweaver has propagated that usage. In fact, there is really no such
HTML thing as a
layer, but for the purposes of this discussion let's use the Dreamweaver/FP
sense of applying that term to absolutely positioned <div>s."

 

[Murray]

Thanks Patty. I didn't want to confuse the issue by mentioning that
Dreamweaver actually treats absolutely positioned images (and absolutely
positioned tables) as if they were 'layers' too! 8)

 

[P@tty Ayers]

Hm, that thickens the semantic plot even more. It does seem like
defining terms is pretty necessary in order to discuss "layers" at all.

 

[Murray]

Yes, definitely. And given that in FP (and in DW) you cannot insert a layer
using the UI without it being both a <div>, and absolutely positioned, I
guess that pretty much sets the stage, no?

 

[P@tty Ayers]

Yup. I've actually never heard the word "layer" used to refer to anything in
HTML other than an absolutely-positioned div (or the old Netscape tag).

Kevin makes some good points, but he seems to be referring to CSS-positioned
divs in general.

 

[Kevin Spencer]

Okay, it's all a matter of how one defines "layer," is it? Well, the
Frontpage 2003 Help isn't exactly clear about this either:

"A layer is a container in a Web page that holds page elements, such as text
and graphics. Layers can be used to create animations, flyout menus, or page
layouts."

"In FrontPage 2003, a layer is defined as an absolutely positioned
DIVISION."

Dreamweaver isn't exactly clear about it either, and even expands the
definition of "layer" beyond div tags:

"A layer is an HTML page element--specifically, a div tag, or any other
tag--that has an absolute position assigned to it. Layers can contain text,
images, or any other content that you can place in the body of an HTML
document."

Now, what's interesting to me is that Netscape originally coined the term
"layer" to mean a proprietary Netscape "layer" tag. FrontPage and
Dreamweaver have apparently decided that the term is useful to describe an
HTML element that is absolutely postioned using CSS. In other words, a
square isn't a rectangle; it's a *regular* rectangle. But of course, a
square *is* a rectangle, and layer *is* a div (or something else perhaps,
according to DW. Still, DW uses divs when you create a layer, so who knows
what they meant?).

You can call it by any name you like. I prefer to call it a div. And can you
take a "layer" and apply relative positioning or default positioning to it?
Why, of course you can. So, while we're all arguing semantics, I think
you're still overlooking my point. Regardless of what you call it, it's a
div. And it can do many things. Can you set the width of a "layer" to a
percentage? Yes. Is it still a "layer?" Who cares? I just want to know what
I can do with it. And the W3C seems to concur. At least they aren't trying
to complicate matters by giving different names to the same HTML elements
depending upon what styles you apply to them.

As for the following remark:

There is no upcoming version of HTML. It's all XHTML now, baby....

Note that XHTML *is* HTML. To be exact, it's "eXtensible HTML." So, we can
argue semantics some more, or I can get back to work. I think I'll get back
to work!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

 

[Murray]

LOL - yeah, me too....

FWIW, GoLive also uses the same confusing nomenclature..... 8)

 

[Trevor L.]

It's great to read all the experts throwing semantic arguments at each other

I understood what both Murray and Kevin were on about.

In fact, after all this discuusion, something stuck in my mind
Definition: A layer is an absolutely positioned <div>

So now when I read discussion about layers, I will know what is meant (or
what should be meant, as sometines persons say layer=div - that is,
identically equal to)

 

[Murray]

Glad we could help, Trevor. I understood what Kevin was saying as well, and
he was correct (mostly! 8). But then, so was I.... 8)

as sometines persons say layer=div - that is, identically equal to)

Only in a particular case.

 

[Kevin Spencer]

Yes, we were both right. I just have a problem with the Microsoft "Don't
worry your pretty little head about the details" way of dealing with the
user. It has some merit, but is too often taken to extreme, as in this case,
where the "simplification" of FrontPage (and Dreamweaver) actually results
in a more complicated scenario for the user. In this case, they have
actually *added* a new name for a div, meaning that, when speaking
FrontPage-ese or Dreamweaver-ese, a div is a div unless and until it is
absolutely positioned, and then it's a layer. IMHO, this results in more
confusion on the part of the user. In fact, there is no such thing as an
HTML "layer" element.

I can certainly see the chain of thought which lead to this decision being
made. Cross-browser-compatible HTML layout is one of the most difficult
tasks for any web developer to perform, as evidenced in the massive numbers
of questions we see here on this newsgroup. Tables are one solution, but
hardly a perfect one. Divs are a better solution, but require more mastery
to use effectively. So, both Dreamweaver and FrontPage came up with the idea
of using absolutely-positioned divs, which requires less knowledge on the
part of the developer, can be dragged and resized easily, and while lacking
many of the abilities of divs in general as a layout tool, provides a
relatively simple and effective alternative to table layout. With the rise
of CSS in the WWW community as a layout solution, this was a logical
solution. So, what were Macromedia and Microsoft going to call
"absolutely-positioned divs" in such a way as not to intimidate the average
AOL user? They used an existing Netscape term, "layer."

However, IMHO, this added to confusion in several ways. First, the "layer"
tag already existed, and is not a div. DW and FP "layers" *are* divs. To
anyone familiar with Netscape "layers," this makes the concept confusing at
best. Second, both DW and FP help don't seem to want to explain much at all
about them, other than to say that they are absolutely-positioned divs,
which is not likely to inform the average AOL users of much of anything at
all, since he/she doesn't know what a div is. Third, it seems to hide the
existence of divs, which, combined with CSS, can serve a huge variety of
uses.

As I mentioned yesterday, a div can have percentages as width and height,
rather than absolute pixel sizes. This means that divs *can* grow and shrink
with the page. In fact, a div with no CSS or attributes, by definition, is
the width of the browser window, or the HTML element containing it. Using
CSS relative positioning, it can be tied to another HTML element, and grow,
shrink, and/or move with it. In fact, when used with CSS, divs are possibly
the single most powerful HTML element that one can use in a web page.

As to what they *should* have named it, I don't know. I have often thought
that a progressive help system would be a great solution. Give the
first-tier stuff at first, and allow the user to drill down into the nitty
gritty in steps. There is some of this already built into Windows, but I
think it's still got a long way to go.

Possibly the greatest problem is simply the proliferation of the idea that
people can design web sites without any knowledge at all using FrontPage or
Dreamweaver. While it is literally true, in practice it is far from true.
Different browsers, versions of HTML, screen resolutions, etc., make certain
(many) things very difficult to do without knowledge. It seems to me that
FrontPage should be marketed as a developer tool, and address its
terminology and help to more of a developer level. I doubt that anyone who
works with it for long remains ignorant. But by marketing it as a user-level
tool, Microsoft has created for itself a big support problem.

At the very least, FrontPage should include some materials for learning the
technical details of HTML, CSS, and JavaScript.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

 

[Murray]

IMHO, this results in more confusion on the part of the user. In fact,

there is no such thing as an HTML "layer" element.

Yes. I agree 100%.

They used an existing Netscape term, "layer."

Water flows downhill - this was an easy concept to mirror in HTML. Further,
if you think about it, a DW/FP/GL 'layer' acts much like a layer in

Second, both DW and FP help don't seem to want to explain much at all
about them

Heh - there is a method there, I think!

Possibly the greatest problem is simply the proliferation of the idea that
people can design web sites without any knowledge at all using FrontPage
or Dreamweaver.

In my opinion, FP (and perhaps even GL) is much more guilty of this than DW
is, by providing such an assortment of wizards and bots to effectively
shield the end user from the stark reality of web development. In
particular, to imply that one can build web pages without a knowledge (even
a casual knowledge) of some HTML is just wrong....

At the very least, FrontPage should include some materials for learning
the technical details of HTML, CSS, and JavaScript.

That's a good idea. Dreamweaver comes with O'Reilly Reference for HTML, for
CSS, for Javascript, and for other scripting languages built in. While this
only helps if you know how and when to use it, it's still there, and
available....

 

[carouse_woman]

Yes. I agree 100%.


Water flows downhill - this was an easy concept to mirror in HTML. Further,
if you think about it, a DW/FP/GL 'layer' acts much like a layer in


Heh - there is a method there, I think!


In my opinion, FP (and perhaps even GL) is much more guilty of this than DW
is, by providing such an assortment of wizards and bots to effectively
shield the end user from the stark reality of web development. In
particular, to imply that one can build web pages without a knowledge (even
a casual knowledge) of some HTML is just wrong....


That's a good idea. Dreamweaver comes with O'Reilly Reference for HTML, for
CSS, for Javascript, and for other scripting languages built in. While this
only helps if you know how and when to use it, it's still there, and
available....

went i put all them i was thinking that google would know what i'm
talking about okay

 

[Murray]

oh l have been looking to find out how to find my csv for my ad that i

went i put all them i was thinking that google would know what i'm
talking about okay

Say what?

 

[Trevor L.]

Thanks again, Murray and Kevin

Great background knowledge