Layers in Front Page

A

Allison

I've been following one of these threads and I've been confused by something
you said, Ron:

"Do NOT place layers directly in table cells, and it is best to not place
text in a layer, since resizing the text may cause odd results."

Why not? Could you explain this? I put my menu leaf layers in a cell
because I wanted the position to be relative to the cell. I didn't fix the
height of the layers because I know that users sometimes change the font
size. I thought it was working fairly well, although when font gets
considerably enlarged the leafs (do they become *leaves* when plural?) don't
line up quite as nice. Nevertheless, I thought it was working well enough.

I've also been considering something else regarding these layers and
behaviors. When the code says "FP_changeProp" is that one of those things
that require FrontPage extensions? Would it be advisable to code it without
the help of FrontPage behaviors?

Thinking,
Allison
 
M

Murray

When you put any absolutely positioned elements (not just 'layers') into a
table cell, *some* browsers get confused about how to figure their location.
I put my menu leaf layers in a cell because I wanted the position to be
relative to the cell.

They will not be. They are relative to the location of the nearest
positioned ancestor container (as long as you leave them absolutely
positioned).

This may help you understand positioning a bit -

There are 4 different types of positioning:
Absolute
Relative
Fixed
Static

Here is a brief explanation of each kind of positioning (with regard to
placement of elements on the page only)....

Position:absolute (or A/P elements)
-----------------------
This does several things -
1. It 'removes' the element from the flow of the code on the­ page so that
it can no longer influence the size or position of any other pa­ge element
(except for those contained within it, of course).

2. The absolutely positioned element takes its position from the position of
its closest PA­RENT *positioned* element - in the absence of any explicitly
positioned parent, this will default to the <body> tag, which is always
positioned
­at 0,0 in the browser viewport.

This means that it doesn't matter where in the HTML code the laye­r's code
appears (between <body> and </body>), its location on the screen will not
change (this assumes that you have not positioned the A/P element within
a table or another A/P element, of course). Furthe­rmore, the space in
which
this element would have appeared were it not positi­oned is not preserved
on the screen. In other words, absolutely positioned elements don't take
up any space on the page. In fact, they FLOAT over the page.

Position:relative (or R/P elements)
----------------------
In contrast to absolute positioning, a relatively positioned page element is
*not* removed from t­he flow of the code on the page, so it will use the
spot
where it would have­ appeared based on its position in the code as its
zero point reference. If­ you then supply top, right, bottom, or left
positions
to the style for this ­element, those values will be used as offsets from
its
zero point.

This means that it DOES matter where in the code the relativ­ely positioned
element appears (, as it will be positioned in that location (­factoring in
the offsets) on the screen (this is true for any placement in the code).
Furthermore, the space where this e­lement would have appeared is
preserved in the display, and can therefore­ affect the placement of
succeeding elements. This means that the taller a relatively
positioned element is, the more space it forces on the page.

Position:static
-------------------
As with relative position, static positions also "go with ­the flow". An
element with a static position cannot have values for offset­s (top, right,
left, bottom) or if it has them, they will be ignored. Unless explicitly
positioned, all div elements default to static positioning.

Position:fixed
------------------
A page element with this style will not scroll as the page c­ontent scrolls.
Support for this in elements other than page backgrounds is ­quirky

There are several other things you need to know:

1. ANY page element can be positioned - paragraphs, tables, images, lists,
etc.
2. The <div> tag is a BLOCK level tag. This means that if it is not
positioned or explicitly styled otherwise, a) it will always begin on a new
line on the screen, and b) it will always force content to a new line below
it, and c) it will always take up the entire width of its container (i.e.,
width:100%).
3. The placement of A/P elements *can* affect the BEHAVIOR of other
elements
on the page. For example, a 'layer' placed over a hyperlink will mask that
hyperlink.

You can see a good example of the essential difference between absolute and
relative positioning here -

http://www.great-web-sights.com/g_layersdemo.asp

You can see a good demonstration of why using layers for a page layout tool
is dangerous here -

http://www.great-web-sights.com/g_layer-overlap.asp
 
A

Allison

Yup, I see it now. Been a while since I coded that page and in reviewing I
didn't look close enough. My layers ARE relative to the body tag. (Does
<div> = "layer"?) And so, if layers are sometimes dangerous, what other way
is there to create a menu leaf? That being said, I'm even more curious
about:

I appreciate your explanation, Murray!

Thanks,
Allison
 
M

Murray

My layers ARE relative to the body tag.

Actually, not. They are relative to the location of the nearest positioned
ancestor, and only when there is not such a beast would it then default to
the body tag.
(Does <div> = "layer"?)

There is no definition of 'layer' in HTML. Different authoring systems use
slightly different definitions, but in general, any absolutely positioned
element is treated as a layer. In Dreamweaver, for example, that could be
And so, if layers are sometimes dangerous, what other way is there to
create a menu leaf?

Sorry - what does this mean?
 
W

Windsun

I hate the word "LAYER", it just confuses people.

The correct term I think is "absolutely positioned <div>, not sure where
that "layer" term came from


-------------------------------------------------------------------------
 
A

Allison

And so, if layers are sometimes dangerous, what other way is there to
Sorry - what does this mean?

Can't help but laugh a bit - I am trying SOOO hard, but I am just beginning
to grasp some of this and I do get a bit mixed up at times! I am going to
work at digesting and studying more and will try to explain my abstract
thoughts better at another time - IF by that point I am still confused!

You've been a wonderful help!

Smiles,
Allison
 
W

Windsun

OK, I Googled the history of "layer", and it was something "introduced" by
Netscape 3.1 for HTML originally. How it got redefined as a CSS term I don't
have a clue.

-------------------------------------------------------------------------
 
A

Allison

Yeah, my thoughts are running in the same direction. Terminology, I guess.

~Allison
 
J

Jon Spivey

Probably the fact that Dreamweaver (originally) and FP (later) call an
absolutely positioned div a layer. Have you never used either program?
 
M

Murray

NN4x introduced the illfated <layer>, and <ilayer> tags which died with this
version.

That's undoubtedly where the term came from.

<layer> was exactly what it sounds like. <ilayer> was a layer that could be
treated as if it were an <iframe>.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top