Old Opera makes floated DIV too wide

[Thomas Mlynarczyk]

Hi,
Here's what I have:

<div>
<img ...><br>
Caption text
</div>

The div is floated left and has no width set, the content is centered, there
are no margins or padding on the <img> (just a bottom margin and
1px-borders) and the text is about as wide as the image. It looks fine in
IE5+, Mozilla and OP7, but OP5 shows the div about twice as wide and OP6 a
bit wider than it should. I thought a float would automatically shrink as
far as the content permits - so how come the old Operas make it wider?

Any magic spell to cure this?

[Rijk van Geijtenbeek]

On Sun, 12 Dec 2004 00:28:45 +0100, Thomas Mlynarczyk
<bl*************@hotmail.com> wrote:

Hi,
Here's what I have:

<div>
<img ...><br>
Caption text
</div>

The div is floated left and has no width set, the content is centered,
there
are no margins or padding on the <img> (just a bottom margin and
1px-borders) and the text is about as wide as the image. It looks fine in
IE5+, Mozilla and OP7, but OP5 shows the div about twice as wide and OP6
a
bit wider than it should. I thought a float would automatically shrink as
far as the content permits - so how come the old Operas make it wider?

Any magic spell to cure this?

Specify widths for floated or positioned DIVs, don't rely on
shrinkwrapping. Opera 4 and 5 follow the CSS 2.0 spec to the letter,
ignoring the errata that introduced the shrink-wrap behavior... Opera 6
fixes some of the problems, Opera 7 follows the mechanism as described in
CSS 2.1. Though it had some problems for a while with nested floats, which
would shrinkwrap a bit too aggressive (try to float LIs in a floated UL,
Opera 7 used to put each LI on a new line).

--
Rijk van Geijtenbeek

The Web is a procrastination apparatus:
It can absorb as much time as is required to ensure that you
won't get any real work done. - J.Nielsen

[Thomas Mlynarczyk]

Also sprach Rijk van Geijtenbeek:

Specify widths for floated or positioned DIVs, don't rely on
shrinkwrapping.

But I don't know the widths in advance. Even if I calculate them for every
single <img> I put, there's still the caption text which may be displayed in
any size or any font. Specifying a width like 1px would work only in IE
(expanding the width to fit the content), but not in Opera. Would some
additional HTML markup help - like wrapping everything in an additional
container <div> and modifying the styles somehow? Not very elegant either,
but probably the best solution... Or should I simply ignore OP<7?

[Rijk van Geijtenbeek]

On Sun, 12 Dec 2004 13:30:43 +0100, Thomas Mlynarczyk
<bl*************@hotmail.com> wrote:

Also sprach Rijk van Geijtenbeek:

Specify widths for floated or positioned DIVs, don't rely on
shrinkwrapping.

But I don't know the widths in advance. Even if I calculate them for
every
single <img> I put, there's still the caption text which may be
displayed in
any size or any font. Specifying a width like 1px would work only in IE
(expanding the width to fit the content), but not in Opera. Would some
additional HTML markup help - like wrapping everything in an additional
container <div> and modifying the styles somehow? Not very elegant
either,
but probably the best solution... Or should I simply ignore OP<7?

The best solution depends on the type of page you are making. But I
sincerely hope Opera 6 isn't used much anymore on the desktop, so if the
end result is readable that might just be good enough. The same Opera 6
rendering engine is also used in the mobile versions you can install on
Nokia Series 60 phones and some others (like the SonyEricson P800 and
P900), so it might be better to invest some time in a media=handheld
stylesheet instead of optimizing for Opera 6 on the desktop. See
<URL:http://alistapart.com/articles/pocket/> for some tips.

--
Rijk van Geijtenbeek

The Web is a procrastination apparatus:
It can absorb as much time as is required to ensure that you
won't get any real work done. - J.Nielsen

[Spartanicus]

"Thomas Mlynarczyk" <bl*************@hotmail.com> wrote:

Specify widths for floated or positioned DIVs, don't rely on
shrinkwrapping.

But I don't know the widths in advance. Even if I calculate them for every
single <img> I put, there's still the caption text which may be displayed in
any size or any font. Specifying a width like 1px would work only in IE
(expanding the width to fit the content), but not in Opera. Would some
additional HTML markup help - like wrapping everything in an additional
container <div> and modifying the styles somehow? Not very elegant either,
but probably the best solution... Or should I simply ignore OP<7?

This isn't confined to Opera 5 or 6, *any* browser that follows the CSS
2.0 float rules does not shrink wrap floats.

Adding display:inline-table on the div should produce shrink wrap
behaviour in browsers that use the CSS 2.0 float rules (untested). Note
that IE has always shrink wrapped floats, so it's non support for
inline-table doesn't matter. I'm not sure if Gecko ever followed the 2.0
float rules, if it did then you'd need to add a display:table hack as
the first option to get it to shrink wrap (caveats may apply).

Note that shrink wrap behaviour won't get your behind out of jail when
the caption is wider than the image, if that applies then you need more
tricks to prevent the caption from stretching the containing element
(recently dealt with in this group).

--
Spartanicus

[Thomas Mlynarczyk]

Also sprach Rijk van Geijtenbeek:

The best solution depends on the type of page you are making. But I
sincerely hope Opera 6 isn't used much anymore on the desktop, so if
the end result is readable that might just be good enough. The same
Opera 6 rendering engine is also used in the mobile versions you can
install on Nokia Series 60 phones and some others (like the
SonyEricson P800 and P900), so it might be better to invest some time
in a media=handheld stylesheet instead of optimizing for Opera 6 on
the desktop. See <URL:http://alistapart.com/articles/pocket/> for
some tips.

Thanks for the link. I have now chosen to use fixed widths after all. It's a
less flexible solution, but apparently the only one.

[Thomas Mlynarczyk]

Also sprach Spartanicus:

This isn't confined to Opera 5 or 6, *any* browser that follows the
CSS 2.0 float rules does not shrink wrap floats.
Are you sure? AFAIK, a float automatically becomes a block element. A block
element takes up all the available width by default. Thus, there would be no
more space on the side. Therefore, (and so I have read somewhere) as soon as
an element is floated it automatically shrinks. It wouldn't make sense if it
didn't. Am I wrong?
Adding display:inline-table on the div should produce shrink wrap
behaviour in browsers that use the CSS 2.0 float rules (untested).
Note that IE has always shrink wrapped floats, so it's non support for
inline-table doesn't matter. I'm not sure if Gecko ever followed the
2.0 float rules, if it did then you'd need to add a display:table
hack as the first option to get it to shrink wrap (caveats may apply).
I will have a look into that possibility. I'm not too familiar with the
table display stuff as it doesn't seem to be well supported yet.
Note that shrink wrap behaviour won't get your behind out of jail when
the caption is wider than the image, if that applies then you need
more tricks to prevent the caption from stretching the containing
element (recently dealt with in this group).

Yes. But I think there can be no "perfect" solution for that - one cannot
fix the font-size nor can one know which font will indeed be used by the
user. Only thing to do (short of implementing the capture text into the
image) is to cut off overflows, which will not be very user-friendly either.

[Steve Pugh]

On Mon, 13 Dec 2004 09:37:40 +0100, "Thomas Mlynarczyk"
<bl*************@hotmail.com> wrote:

Also sprach Spartanicus:

This isn't confined to Opera 5 or 6, *any* browser that follows the
CSS 2.0 float rules does not shrink wrap floats.
Are you sure? AFAIK, a float automatically becomes a block element. A block
element takes up all the available width by default. Thus, there would be no
more space on the side.

Correct. Therefore a floated element has an implicit width: 100%; (the
default for all block level elements and consistent with your 'all the
available width' and 'no more space on the side') if no other width is
specified.
Therefore, (and so I have read somewhere) as soon as
an element is floated it automatically shrinks.

How do you reach that conclusion? It doesn't follow from what you said
above.

Steve

[Spartanicus]

Steve Pugh <st***@pugh.net> wrote:

Therefore a floated element has an implicit width: 100%; (the
default for all block level elements

The default width for block level elements is "auto", not "100%".

Try this:
<p style="width:100%;padding:0 20em;border:1px solid #000">100%</p>
<p style="width:auto;padding:0 20em;border:1px solid #000">auto</p>

--
Spartanicus

[Steve Pugh]

On Mon, 13 Dec 2004 10:59:50 +0000, Spartanicus <[e-mail]>
wrote:

Steve Pugh <st***@pugh.net> wrote:

Therefore a floated element has an implicit width: 100%; (the
default for all block level elements

The default width for block level elements is "auto", not "100%".

Correct.

Steve

[Spartanicus]

"Thomas Mlynarczyk" <bl*************@hotmail.com> wrote:

This isn't confined to Opera 5 or 6, *any* browser that follows the
CSS 2.0 float rules does not shrink wrap floats.

Are you sure? AFAIK, a float automatically becomes a block element. A block
element takes up all the available width by default. Thus, there would be no
more space on the side.

Correct, but floats are not part of the flow, example:

<p style="border:1px solid red">
<img src="dummy.png" width="100" height="100" alt="" style="float:left">
</p>

Note that shrink wrap behaviour won't get your behind out of jail when
the caption is wider than the image, if that applies then you need
more tricks to prevent the caption from stretching the containing
element (recently dealt with in this group).

Yes. But I think there can be no "perfect" solution for that - one cannot
fix the font-size nor can one know which font will indeed be used by the
user. Only thing to do (short of implementing the capture text into the
image) is to cut off overflows, which will not be very user-friendly either.

I repeat: recently dealt with in this group, look it up (there is a
method to do this).

--
Spartanicus

[Thomas Mlynarczyk]

Also sprach Spartanicus:

Yes. But I think there can be no "perfect" solution for that - one
cannot fix the font-size nor can one know which font will indeed be
used by the user. Only thing to do (short of implementing the
capture text into the image) is to cut off overflows, which will not
be very user-friendly either.

I repeat: recently dealt with in this group, look it up (there is a
method to do this).

I tried to find that thread, but wasn't quite successful. Could you give me
a link please?

[Spartanicus]

"Thomas Mlynarczyk" <bl*************@hotmail.com> wrote:

Yes. But I think there can be no "perfect" solution for that - one
cannot fix the font-size nor can one know which font will indeed be
used by the user. Only thing to do (short of implementing the
capture text into the image) is to cut off overflows, which will not
be very user-friendly either.

I repeat: recently dealt with in this group, look it up (there is a
method to do this).

I tried to find that thread, but wasn't quite successful. Could you give me
a link please?

From: Chris Leipold <cl******@dietzk.de>
Newsgroups: comp.infosystems.www.authoring.stylesheets
Subject: Image Captions
Date: Fri, 10 Dec 2004 10:39:48 +0100

--
Spartanicus

[Thomas Mlynarczyk]

Also sprach Steve Pugh:

Are you sure? AFAIK, a float automatically becomes a block element.
A block element takes up all the available width by default. Thus,
there would be no more space on the side.

Correct. Therefore a floated element has an implicit width: 100%; (the
default for all block level elements and consistent with your 'all the
available width' and 'no more space on the side') if no other width is
specified.

Therefore, (and so I have read somewhere) as soon as
an element is floated it automatically shrinks.

How do you reach that conclusion? It doesn't follow from what you said
above.

What I meant was this: If a floated element is supposed to take up all the
available width, then how could its rendering differ from that of a
non-floated block element? If it takes up all the width, then nothing could
be shown to its left or right (depeding on where it was floated). For a
visual "side-by-side", the floated element must leave some room for other
content to actually float around it, and how could that be if the floated
element stretches all the way to the "other side"? That's why it doesn't
make sense to me *not* to shrink-wrap a floated element. Besides, that would
imply that none of the modern browsers I know (OP7, Moz, Firefox, NN6+,
IE5+) would follow this specification as they all seem to shrink-wrap
floated elements.

Confused,
Thomas

[Steve Pugh]

On Mon, 13 Dec 2004 13:37:55 +0100, "Thomas Mlynarczyk"
<bl*************@hotmail.com> wrote:

Also sprach Steve Pugh:

Are you sure? AFAIK, a float automatically becomes a block element.
A block element takes up all the available width by default. Thus,
there would be no more space on the side.
Correct. Therefore a floated element has an implicit width: 100%; (the
default for all block level elements and consistent with your 'all the
available width' and 'no more space on the side') if no other width is
specified.

Therefore, (and so I have read somewhere) as soon as
an element is floated it automatically shrinks.

How do you reach that conclusion? It doesn't follow from what you said
above.

What I meant was this: If a floated element is supposed to take up all the
available width, then how could its rendering differ from that of a
non-floated block element?

By setting the width.
If it takes up all the width, then nothing could
be shown to its left or right (depeding on where it was floated). For a
visual "side-by-side", the floated element must leave some room for other
content to actually float around it, and how could that be if the floated
element stretches all the way to the "other side"?
You set the width of the floated element.
That's why it doesn't
make sense to me *not* to shrink-wrap a floated element. Besides, that would
imply that none of the modern browsers I know (OP7, Moz, Firefox, NN6+,
IE5+) would follow this specification as they all seem to shrink-wrap
floated elements.

They either thought like you do and decided to ignore the
specification. Or they interpreted width: auto = width: 0 = ??? as an
invitation to do whatever the liked.

Actually, some of the browsers you list (OP7, receny Gecko) explicitly
say that they're supporting CSS 2.1 and so it's a non-issue. It's Win
IE and early Gecko that shrink-to-fit in possible defiance of the CSS
2 spec, whilst Mac IE and early Opera did not.

Anyway, that's all in the past. CSS 2.1 specifies that shrink-to-fit
is correct for width: auto on floated elements.

Steve

[Lauri Raittila]

in comp.infosystems.www.authoring.stylesheets, Thomas Mlynarczyk wrote:

Also sprach Rijk van Geijtenbeek:

Specify widths for floated or positioned DIVs, don't rely on
shrinkwrapping.
But I don't know the widths in advance. Even if I calculate them for every
single <img> I put, there's still the caption text which may be displayed in
any size or any font. Specifying a width like 1px would work only in IE
(expanding the width to fit the content), but not in Opera.

Use disaplay:table, works Opera 5+ IIRC
Would some
additional HTML markup help - like wrapping everything in an additional
container <div> and modifying the styles somehow? Not very elegant either,
but probably the best solution... Or should I simply ignore OP<7?

I have gotten it to work on Opera 5, 6 and 7. Don't remember exactly how
though. URL?
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>

[Thomas Mlynarczyk]

Also sprach Steve Pugh:

What I meant was this: If a floated element is supposed to take up
all the available width, then how could its rendering differ from
that of a non-floated block element?

By setting the width.
Thus, in real life, a float can never be without a specified width?
Anyway, that's all in the past. CSS 2.1 specifies that shrink-to-fit
is correct for width: auto on floated elements.

"is correct" != "is a must"?

[Thomas Mlynarczyk]

Also sprach Spartanicus:

I tried to find that thread, but wasn't quite successful. Could you
give me a link please?

From: Chris Leipold <cl******@dietzk.de>
Newsgroups: comp.infosystems.www.authoring.stylesheets
Subject: Image Captions
Date: Fri, 10 Dec 2004 10:39:48 +0100

Thanks, I've found it now. Somehow, though, the third example doesn't quite
seem to work on my IE5 as expected - the middle caption doesn't use the full
width of the image above. And if I change the caption to something long and
unwrappable like "xxxxxxxxxxxxx..." the result is - well, not exactly
satisfactory. Well, I must take a closer look at it. It certainly gives
useful hints.

[Thomas Mlynarczyk]

Also sprach Lauri Raittila:

Use disaplay:table, works Opera 5+ IIRC
Thanks, I will look into this.
I have gotten it to work on Opera 5, 6 and 7. Don't remember exactly how though.

So there is hope for me :-)
URL?

localhost for the moment. But with the help I got from all your replies
here, I should now be able to get it working somehow :-) Thanks again!

[Spartanicus]

"Thomas Mlynarczyk" <bl*************@hotmail.com> wrote:

I tried to find that thread, but wasn't quite successful. Could you
give me a link please?
From: Chris Leipold <cl******@dietzk.de>
Newsgroups: comp.infosystems.www.authoring.stylesheets
Subject: Image Captions
Date: Fri, 10 Dec 2004 10:39:48 +0100

Thanks, I've found it now. Somehow, though, the third example doesn't quite
seem to work on my IE5 as expected - the middle caption doesn't use the full
width of the image above.

Works fine in IE5.5, 5.0 is so horribly deficient that I don't care what
it does in that, it's market share is so low that I serve it plain html.
And if I change the caption to something long and
unwrappable like "xxxxxxxxxxxxx..." the result is - well, not exactly
satisfactory.

So if you set out to break it, it actually breaks? Imagine that.

--
Spartanicus

[Steve Pugh]

On Mon, 13 Dec 2004 20:35:21 +0100, "Thomas Mlynarczyk"
<bl*************@hotmail.com> wrote:

Also sprach Steve Pugh:

What I meant was this: If a floated element is supposed to take up
all the available width, then how could its rendering differ from
that of a non-floated block element?

By setting the width.

Thus, in real life, a float can never be without a specified width?

Under CSS 2, yes.
In the real world if support by Mac IE5 and some other minor browsers
is required, yes.
Otherwise, no.
Anyway, that's all in the past. CSS 2.1 specifies that shrink-to-fit
is correct for width: auto on floated elements.

"is correct" != "is a must"?

Read http://www.w3.org/TR/CSS21/visudet.html#q8 and judge for
yourself.

Steve

[kchayka]

on 2004-12-13 Steve Pugh wrote:

On Mon, 13 Dec 2004 20:35:21 +0100, "Thomas Mlynarczyk"
<bl*************@hotmail.com> wrote:

Thus, in real life, a float can never be without a specified width?
Under CSS 2, yes.
In the real world if support by Mac IE5 and some other minor browsers
is required, yes.

You can get MacIE5 to shrink wrap floats, too. In a nutshell, just give it
display:inline-block, a CSS 2.1 property value. I suggest using syntax

* html>body .floater { display: inline-block }

The *html trick hides the rule from non-IE browsers, and the descendent
selector hides it from WinIE, so MacIE should be the only browser to see
it. Other browsers should ignore inline-block on a floated element anyway.

I learned about this somewhere at http://www.positioniseverything.net/


Otherwise, no.

Anyway, that's all in the past. CSS 2.1 specifies that shrink-to-fit
is correct for width: auto on floated elements.

"is correct" != "is a must"?

Read http://www.w3.org/TR/CSS21/visudet.html#q8 and judge for
yourself.

Steve

[Thomas Mlynarczyk]

Also sprach kchayka:

You can get MacIE5 to shrink wrap floats, too. In a nutshell, just
give it display:inline-block, a CSS 2.1 property value. I suggest
using syntax

* html>body .floater { display: inline-block }

The *html trick hides the rule from non-IE browsers, and the
descendent selector hides it from WinIE, so MacIE should be the only
browser to see it. Other browsers should ignore inline-block on a
floated element anyway.

I learned about this somewhere at http://www.positioniseverything.net/

I think I read that one, too. But as the display-property is to be ignored
for floats (except for display:none), why bother hiding it from other
browsers anyway? Or would it collide with a display: inline required to fix
the IE double margin bug?

[Thomas Mlynarczyk]

Also sprach Spartanicus:

Works fine in IE5.5, 5.0 is so horribly deficient that I don't care
what it does in that, it's market share is so low that I serve it
plain html.
Already? I still consider IE5.0 a must-support. And once you get something
working under IE5.5+, IE5.0 shouldn't be that hard.

And if I change the caption to something long and
unwrappable like "xxxxxxxxxxxxx..." the result is - well, not exactly
satisfactory.

So if you set out to break it, it actually breaks? Imagine that.

Well, I was hoping for something like an "overflow:hidden". Which, of
course, would have had disadvantages of its own.

[kchayka]

Thomas Mlynarczyk wrote:

Also sprach kchayka:

* html>body .floater { display: inline-block }

But as the display-property is to be ignored
for floats (except for display:none), why bother hiding it from other
browsers anyway? Or would it collide with a display: inline required to fix
the IE double margin bug?

I just prefer setting clean, valid properties as the default, then only
use targeted overrides for dirty browsers that don't play nice. That's
almost always some flavor of IE, of course. :)

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