Mixing floats, positioning and offsets

[Bill Norton]

I've been experimenting with floats, positioning and offsets (top, left, etc.) to see what happens when you mix the properties together.
All this may be old news to most of you, but it was extremely helpful to me. The results are summarized in this chart. In all these tests I was using a single child element inside a containing block. (I hope the formatting doesn't fall apart too badly when it's uploaded to a newsgroup.)
| Do Floats | Do Offsets |
Position | Matter? | Matter? |
---------|-----------|------------|
Static | Yes | No |
---------|-----------|------------|
Relative | Yes | Yes |
---------|-----------|------------|
Absolute | No* | Yes |
---------|-----------|------------|

OK. That all makes sense. For example, if your positioning is static there's no point in specifying offsets, because then you'd be defining relatively positioning. In the case of relative positioning with both a float and offsets, it appears that the element is floated first and then offset. Yeah, I know, you probably knew that.

Wrapping my head around an absolutely positioned, floated element was a bit trickier, and apparently IE had a little trouble with it also*. Check out what happens in IE vs. FireFox when you have an element that has position: absolute; float: right and no offsets defined:

http://www.thehammondhouse.com/test_...ight%20Off.htm

All of this brings up a this question. Is it fair to say that it would be unusual to find an element that is both floated and offset? Actually a better way to ask the question might be is it unusual to have a good *reason* to have an element that is both floated and offset?

[Gus Richter]

Bill Norton wrote:

I've been experimenting with floats, positioning and offsets (top, left,
etc.) to see what happens when you mix the properties together.

All of this brings up a this question. Is it fair to say that it would
be unusual to find an element that is both floated and offset? Actually
a better way to ask the question might be is it unusual to have a good
*reason* to have an element that is both floated and offset?

You're trying to take a shortcut in experimenting with behaviors rather
than reading, understanding and following the specifications. This is
what got the Web in trouble in the first place. Here are a few pointers:

A floated item slams the item to the extreme left or right, as the case
may be, within its container. It sets the item flush left or flush
right. If you wish to offset it, you have to affect the item some other
way, since the specs state:

"This property [float] specifies whether a box should float to the left,
right, or not at all. It may be set for any element, but only applies to
elements that generate boxes that are not absolutely positioned."

So, no sense in any further discussion on this - you cannot float an abs
element, period.

Regarding your, 'Do Offsets Matter for Static?' you should also be aware
that Static does not take any offsetting properties whether block or inline.

--
Gus

[Bill Norton]

"Gus Richter" wrote

You're trying to take a shortcut in experimenting with behaviors rather
than reading, understanding and following the specifications.

Please. I've done plenty of reading on this. The few hours I've spent
experimenting with these properties has given me a far better understanding
than yet more reading would ever do. Trust me. I know my learning style.

So, no sense in any further discussion on this - you cannot float an abs
element, period.

Well, tell it to MS, then. What's happening with their absolute,
right-floated, non-offset element isn't exactly floating, but it's not
exactly according to specs either.

Gus, you obviously place a lot more weight on specs than I do. Ultimately I
have to write to the browsers, not to the specs, and the main browser I have
to write to is IE. That's the unfortunate reality for me.

Regarding your, 'Do Offsets Matter for Static?' you should also be aware
that Static does not take any offsetting properties whether block or
inline.

Well, there's nothing that keeps you from specifying offsets for a static,
it's just that they will be ignored. This isn't like passing parameters to a
function where an invalid or meaningless parameter could make it crash.

But it's true that statics don't "take" offsets because then, well, they'd
be relatives, wouldn't they?

[Gus Richter]

Bill Norton wrote:

>

>So, no sense in any further discussion on this - you cannot float an abs
element, period.

Well, tell it to MS, then. What's happening with their absolute,
right-floated, non-offset element isn't exactly floating, but it's not
exactly according to specs either.

If the specs tell you that you cannot do a certain thing, then you
should not do that thing, IMHO. If you do that thing, the result may be
unpredictable, especially in a faulty browser such as IE. If you do that
thing anyway, then the browser should ignore it. Fx does so in this case
and IE does not, but proceeds to do something unpredictable (unspecified
in the specs). You give some value to IE's action here?

Gus, you obviously place a lot more weight on specs than I do. Ultimately I
have to write to the browsers, not to the specs, and the main browser I have
to write to is IE. That's the unfortunate reality for me.

Due to the fact that some browsers had some difficulty in following some
of the specs, the web had some problems when author's wrote to the
quirks (behaviors) of some browsers. This is not the way it should be
done today. Authoring should be according to the specs with compensation
to accomodate any defective browser such as IE6. Generally it can be
done within the spec guidelines. This also means that one should check
with Fx/Opera _first_ and IE _last_. If IE is the odd-man out, IE will
be wrong 99% of the time.

>Regarding your, 'Do Offsets Matter for Static?' you should also be aware
that Static does not take any offsetting properties whether block or
inline.

Well, there's nothing that keeps you from specifying offsets for a static,
it's just that they will be ignored. This isn't like passing parameters to a
function where an invalid or meaningless parameter could make it crash.

Very much related to my first paragraph:
If the specs tell you that you cannot do a certain thing, then you
should not do that thing, IMHO. If you do that thing anyway, the result
may be unpredictable, especially in a faulty browser such as IE. In this
case it seems that Fx and IE both ignore (don't take) the offsets for
Static. So why would you then include it?

But it's true that statics don't "take" offsets because then, well, they'd
be relatives, wouldn't they?

Right. Which should tell you to not include offsets for Static.

--
Gus

[Bill Norton]

"Gus Richter" wrote

Authoring should be according to the specs with compensation to accomodate
any defective browser such as IE6.

Good point.

But back to the question:

Is it fair to say that it would be unusual to find an element that is both
floated and offset?

[Gus Richter]

Bill Norton wrote:

>
Is it fair to say that it would be unusual to find an element that is both
floated and offset?

It's all in:
<http://www.w3.org/TR/CSS21/visuren.html>
with specific references to:

<http://www.w3.org/TR/CSS21/visuren.html#positioning-scheme>
explains the three positioning schemes.

<http://www.w3.org/TR/CSS21/visuren.html#choose-position>
explains that there are two positioning properties - position and float.

<http://www.w3.org/TR/CSS21/visuren.html#position-props>
explains that the offsets may be applied only to an element that has a
position property other than static - floats are excluded.

<http://www.w3.org/TR/CSS21/visuren.html#float-position>
explains the float algorithm - neither a position property, nor the
offsets are applicable to a float.

Bottom line: Not only would I say that it would be unusual to find an
element that is both floated and offset, but that it is an error, not
conforming to the specs, a result of bad coding due to a lack of
understanding and just plain garbage.

--
Gus

[Spartanicus]

Gus Richter <gu********@netscape.netwrote:

>Is it fair to say that it would be unusual to find an element that is both
floated and offset?

It's all in:
<http://www.w3.org/TR/CSS21/visuren.html>
with specific references to:

<http://www.w3.org/TR/CSS21/visuren.html#positioning-scheme>
explains the three positioning schemes.

<http://www.w3.org/TR/CSS21/visuren.html#choose-position>
explains that there are two positioning properties - position and float.

<http://www.w3.org/TR/CSS21/visuren.html#position-props>
explains that the offsets may be applied only to an element that has a
position property other than static - floats are excluded.

<http://www.w3.org/TR/CSS21/visuren.html#float-position>
explains the float algorithm - neither a position property, nor the
offsets are applicable to a float.

Bottom line: Not only would I say that it would be unusual to find an
element that is both floated and offset, but that it is an error, not
conforming to the specs, a result of bad coding due to a lack of
understanding and just plain garbage.

An element can be both floated and have position:relative, in which case
the box offsets apply.

--
Spartanicus

[Gus Richter]

Spartanicus wrote:

>
An element can be both floated and have position:relative, in which case
the box offsets apply.

I tried this and it does indeed work.
That being said, my belief is that this behavior is undefined and
according to my understanding of the specs, should not work. Can you
give a reference supporting this behavior?

How about this:
A rel element is offset from its position in the normal flow.
A float is out of the normal flow.
My test shows that the offset is not from where the rel element had been
in the normal flow, but offset from its float position.
This goes against the grain.

My previous links proved by omission that this should not work.
Where in the specifications does it even hint that this is correct behavior?

BTW, this is the test I used:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Float and Relative Offset test</title>
<style type="text/css">
#box1 {
background-color: #ff0000;
height: 100px;
width: 200px;
float: left;
}
#box2 {
background-color: #00ff00;
height: 200px;
width: 200px;
clear: left;
float: left;
}
#box3 {
background-color: #0000ff;
float: left;position:relative;top:100px;left:100px;
height: 50px;
width: 300px;
}
</style>
</head>
<body>
<div id="box1">Box 1</div>
<div id="box2">Box 2</div>
<div id="box3">Box 3</div>
<p style="clear:left;">Firefox and Opera support this float and relative
offset. IE also (with another problem evident).</p>
</body>
</html>

--
Gus

[Spartanicus]

Gus Richter <gu********@netscape.netwrote:

>An element can be both floated and have position:relative, in which case
the box offsets apply.

I tried this and it does indeed work.
That being said, my belief is that this behavior is undefined and
according to my understanding of the specs, should not work. Can you
give a reference supporting this behavior?

http://www.w3.org/TR/CSS21/visuren.h...ve-positioning

--
Spartanicus

[Gus Richter]

Spartanicus wrote:

Gus Richter <gu********@netscape.netwrote:

>>An element can be both floated and have position:relative, in which case
the box offsets apply.

I tried this and it does indeed work.
That being said, my belief is that this behavior is undefined and
according to my understanding of the specs, should not work. Can you
give a reference supporting this behavior?

http://www.w3.org/TR/CSS21/visuren.h...ve-positioning

Right, thank you. I kept on missing the 'or floated'.

"Once a box has been laid out according to the normal flow _or floated_,
it may be shifted relative to this position."

So, Bill and anyone else following this: My appologies - A floated
element may indeed be offset relatively.

--
Gus