Here's the problem:
http://pages.prodigy.net/chris_beal...theproblem.html

The page contains inline text, then some additional pairs of text which
are floated right and left.  (This is a transcript of a historical legal
document with signatures on the right and witnesses on the left).  The
'document' ends with no additional inline text.  The background of the
entire document should be brown inside a white body, (in this test the
body is inside a green HTML structure) but it isn't (the actual
appearance depends greatly on what browser you are using), largely
because the height of the floated boxes is not included in the height of
the 'document' box within which they are contained, per CSS2, Section
10.6.3, which states, regarding the height of a box, "If it has
block-level children, it is the distance from the top border-edge of the
topmost block-level child box, to the bottom border-edge of the
bottommost block-level child box. Only children in the normal flow are
taken into account (i.e., floating boxes and absolutely positioned boxes
are ignored,..."

Thus floating boxes do not extend the height of their containing block.
That's bad when they are part of the same logical structure and you
want them to inherit their parent's color.

I've forced background-color: inherit here, but I'd much rather be able
to use the default background-color: transparent.

Here's the workaround:
http://pages.prodigy.net/chris_beal...workaround.html

I've added:
<p style="clear: both">
&nbsp;
</p>
below the floated blocks.  This extends the height of the containing
block to include them.

And now I can leave the backgrounds transparent:
http://pages.prodigy.net/chris_beal...ransparent.html

The question (you knew there was going to be one, right?).

Is this ugly hack to the HTML the best way to resolve this issue with
CSS styling?

If you'd like to see one of these documents in its native environment
(without any background colors), look at
http://beallsprings.org/WC.Deed%20GG.114-15.T.html.

Thanks,
Chris Beall

Chris Beall wrote:
>
> Is this ugly hack to the HTML the best way to resolve this issue with
> CSS styling?

Not a hack at all to place a Clear in order to get clearance. In order
to understand the box model as it should, and does, behave with W3C
compliant browsers, introduce a border to your Div 1 in both page
versions. You will note that in the 1st version, the Div 1 box extends
down only to the cut-out portion, whereas in the 2nd version, the Div 1
box extends down to where the Clear is applied.

The reason that the Div 1 box (and hence its background color) does not
extend further down in the 1st version is because the floated items are
out of the normal flow and therefore are not presented as content for Div 1.

You can get further understanding by including, in the 1st version, more
text immediately before the Div 1 closing tag. This introdoces more
content to Div 1 and the text will go between the two floats, extending
the Div 1 content along with its background. Adding sufficient text
causes it to wrap around the floats along with the background and
thereby clearing the floats without the need for Clear.

--
Gus

Gus Richter wrote:
> Chris Beall wrote:
> 
>
>
> Not a hack at all to place a Clear in order to get clearance.

Gus,

OK.  Seems a hack to me because you have to add HTML which is not
semantically part of the data in order to have something to style with
the clear: both.

I had already tried adding borders and inline text, so I've seen the
other effects you described.  That's what sent me back to the spec...

Anyway, now when someone in alt.html.critique complains about it, I can
cite this communication as justification for what I've done.    :-)

Thanks,
Chris Beall

Chris Beall wrote:
> Gus Richter wrote:
> 
>
>
> Gus,
>
> OK.  Seems a hack to me because you have to add HTML which is not
> semantically part of the data in order to have something to style with
> the clear: both.

The only time that I would call it an unnecessary hack, IMHO, is if
there were subsequent content and the clear were applied this way and
not applied to the subsequent element.

For example, you have used a "P Clear" whereas some people use a "DIV
Clear" as a norm, instead of applying the Clear directly to the
subsequent element. This, I believe, to be due to lack of understanding,
although I also believe that in some instances, for which I cannot think
of an example at the moment other than yours, it may be the only
solution. Additionally, such use of a Clear may create extra
difficulties with margins collapsing.

--
Gus

Chris Beall wrote:
>
> Is this ugly hack to the HTML the best way to resolve this issue with
> CSS styling?

<URL:http://www.positioniseverything.net/easyclearing.html>

However, I recommend using zoom:1 rather than height:1% for IE, since
who knows whether the next IE will honor height properties like it
should. Read about the "Holly hack" for more info.

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.

kchayka wrote:
> Chris Beall wrote:
> 
>
>
> <URL:http://www.positioniseverything.net/easyclearing.html>
>
> However, I recommend using zoom:1 rather than height:1% for IE, since
> who knows whether the next IE will honor height properties like it
> should. Read about the "Holly hack" for more info.
>
kchayka,

Excellent summary of the problem and possible solutions.

Thanks,
Chris Beall

Lauri Raittila wrote:

> in comp.infosystems.www.authoring.stylesheets, Chris Beall wrote:
> 
>
> 
>
> 
>
>
> Never. <div> is better HTML, but of course you can always apply
> display:table for container, and thus you don't need that ugly HTML.
>
Lauri,

Thanks for more things to experiment with...

Chris Beall

Gus Richter wrote:

> Chris Beall wrote:
> 
>
>
> The only time that I would call it an unnecessary hack, IMHO, is if
> there were subsequent content and the clear were applied this way and
> not applied to the subsequent element.
>
> For example, you have used a "P Clear" whereas some people use a "DIV
> Clear" as a norm, instead of applying the Clear directly to the
> subsequent element. This, I believe, to be due to lack of understanding,
> although I also believe that in some instances, for which I cannot think
> of an example at the moment other than yours, it may be the only
> solution. Additionally, such use of a Clear may create extra
> difficulties with margins collapsing.
>
Gus,

Hmmm. Why didn't I use a <div>?  Seems more natural to me now.  Back to
the sandbox...

Chris Beall

Gus Richter wrote:
> Chris Beall wrote:
> 
>
>
> The only time that I would call it an unnecessary hack, IMHO, is if
> there were subsequent content and the clear were applied this way and
> not applied to the subsequent element.
>
> For example, you have used a "P Clear" whereas some people use a "DIV
> Clear" as a norm, instead of applying the Clear directly to the
> subsequent element. This, I believe, to be due to lack of understanding,
> although I also believe that in some instances, for which I cannot think
> of an example at the moment other than yours, it may be the only
> solution. Additionally, such use of a Clear may create extra
> difficulties with margins collapsing.
>

Gus,

OK, I tried <div>, but it didn't work so I reverted to <p>.  In my case
the containing block ended with two floats, one to the left and one to
the right.  The container was, in turn, followed by more inline text.
With an empty <div> the following inline text slipped up into the space
between the floats (IE) and the background within the original container
was not extended low enough by a hair (IE) or several lines (NN 7.1).

I'll be happy until I hear from some other browser user that it makes a
mess in their environment.

Chris Beall

in comp.infosystems.www.authoring.stylesheets, Chris Beall wrote:
> kchayka wrote: 
 

> Excellent summary of the problem and possible solutions.

But don't use :after, but display:table, as after thingy is not that
stable. You can use display:inline-block for IE6. After only works with
non-visible content in Opera 6+

Of you can float the container also, which is usually simplest way.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>