div width question

[Chris Stromberger]

I have a div with a width of 40em (is em cool to use for width?). The
situation below applies even if width is auto or 80% or something.
Inside the div I am displaying some code with <pre> tags. If the code
has a very long line (wider than the div), then what's supposed to
happen? IE and Mozilla do two very different things. IE expands the
div to encompass the line (creating horizontal scrollbars in the
browser window if nec). Mozilla lets the line cross the div boundary
w/o expanding the div. Which is correct?

The real question is: how can I get the IE behavior in both browsers?
I would like the div to be say 80% of the page width normally, but
expand to fit any long lines when the content dictates. Is this
possible?

Thanks,
Chris

[Ian Fitchet]

Re: div width question

Chris Stromberger <bit_bucket5@ho tmail.com> writes:
[color=blue]
> I have a div with a width of 40em (is em cool to use for width?). The[/color]

Real world units (mm, cm, in, pt) are generally hopeless as your
browser is on the whole pretty clueless about your screen's dpi. My
laptop's 1400x1050 screen is smaller than my LCD's 1280x1024 but
Windows almost certainly has them both down as 76dpi (or something).
Go figure.

That leaves the media's `natural' units (px, and their derivatives,
em, en and ex). Years ago TeX manuals used to suggest that you use
em (the height of a capital M in the current font) for vertical line
spacing and ex (the width of a lowercase x) for horizontal line
widths. Classically, your line separation would be the order of 1em
(1.2em rings a bell) and the line width wouldn't be more than 76ex.

Of course, these days it's much more common to be dealing with images
so it's a bit harder. I'd guess that most people define overall page
widths/heights in px (because they know how big their images are)
then, if they're feeling keen, they'll set additional em or ex
dimensions for text oriented divs.
[color=blue]
> happen? IE and Mozilla do two very different things. IE expands the
> div to encompass the line (creating horizontal scrollbars in the
> browser window if nec). Mozilla lets the line cross the div boundary
> w/o expanding the div. Which is correct?[/color]

I think this is the `overflow' property.
http://www.w3schools.com/css/css_positioning.asp is one of many
references.

Cheers,

Ian

[Chris Morris]

Re: div width question

Chris Stromberger <bit_bucket5@ho tmail.com> writes:[color=blue]
> I have a div with a width of 40em (is em cool to use for width?). The[/color]

em and % are the best things to use for sizing, depending on context.
px can be used in situations where something needs to match something
else with a definite pixel size, like an image.
[color=blue]
> situation below applies even if width is auto or 80% or something.
> Inside the div I am displaying some code with <pre> tags. If the code
> has a very long line (wider than the div), then what's supposed to
> happen? IE and Mozilla do two very different things. IE expands the
> div to encompass the line (creating horizontal scrollbars in the
> browser window if nec). Mozilla lets the line cross the div boundary
> w/o expanding the div. Which is correct?[/color]

From my reading of http://www.w3.org/TR/CSS2/visufx.html I think
Mozilla is correct.
[color=blue]
> The real question is: how can I get the IE behavior in both browsers?
> I would like the div to be say 80% of the page width normally, but
> expand to fit any long lines when the content dictates. Is this
> possible?[/color]

div.foo {
min-width: 80%; /* IE ignores min-width. */
width: 80%;
/* But seems to treat this _as_ min-width in the event of overflow */
}

div.foo, [notinie] { /* IE now can't see this rule */
width: auto; /* Let decent browsers take up more than 80% if needed */
}

This may not do exactly what you want, since browsers may expand the
div past 80% if there's enough content, even if linewrapping the
content would keep it under 80%. If you're only keeping a <pre> in
the div, you should be fine.

That said, if you're only keeping a pre in the div, why not put the
above properties direct onto the pre?

--
Chris

[Alan J. Flavell]

Re: div width question

On Sat, Aug 30, Chris Morris inscribed on the eternal scroll:
[color=blue]
> em and % are the best things to use for sizing, depending on context.
> px can be used in situations where something needs to match something
> else with a definite pixel size, like an image.[/color]

I'll grant you that some kinds of image material resize badly:
typically that would be line-art, images of text (but we shouldn't
normally do that, should we?). That would be the kind of material for
which gif or indexed PNG format is apt, and those images are best
shown at their natural pixel size.

But JPEG, on the other hand, suitable for photo-realistic-type images,
can re-size fairly well, and - depending on the circumstances - it
could be quite a reasonable idea to size such an image in em units to
match the accompanying text. A bit of testing with a few browsers in
different browsing situations would be advisable, obviously, to
develop a "feel" for what works and what's best avoided. I've done
this to some extent in the past, but I haven't done a recent browser
survey, so I won't try to give any detailed advice just now.

all the best

[Nikolaos Giannopoulos]

Re: div width question

Alan J. Flavell wrote:[color=blue]
> On Sat, Aug 30, Chris Morris inscribed on the eternal scroll:
>
> I'll grant you that some kinds of image material resize badly:
> typically that would be line-art, images of text (but we shouldn't
> normally do that, should we?).[/color]

Unfortunately for things like headers - e.g. a banner that says
"Products and Services" in a large font, does not look as good when
rendered in a browser as it does if it was created in Photoshop and used
as an image. I'll agree that we should only even consider such notions
in "special" circumstances as there are many downsides and this should
only be done if a text alternative is available.

Furthermore, I recently came accross an interesting series of articles at:

http://www.web-graphics.com/mtarchive/000815.php

Yes, there are downsides but one has to way the pro's and con's and make
a judgement call (BTW it is interesting to note that in the last article
the JAWS downside may be a non-issue with certain (newer?) versions of
JAWS).

[color=blue]
> But JPEG, on the other hand, suitable for photo-realistic-type images,
> can re-size fairly well, and - depending on the circumstances - it
> could be quite a reasonable idea to size such an image in em units to
> match the accompanying text.[/color]

I'm not sure that I can agree that JPEG resizes really well. Most
images will resize adequately if they are made smaller than the original
BUT even this is not always the case. Enlarging images means that the
browser has to interpolate the pixels that essentially don't exist and
unfortunately browsers do a really poor job in this area (this is
understandably so as they need to be fast and therein lies the trade off).

The best thing to do for images IMO is provide them at their exact size
unless the picture is condusive to being resized - e.g. a square black
box. But even in these cases one has to consider whether the bandwidth
savings, coupled with addtional work put on the browser (albeit
seeminlgy negligible) are truly worth it. I'd say in general not but
again it depends on the circumstances (e.g. if a single black pixel is
used to draw numerous lines on a page of different sizes then it would
be worth it to have the single black pixel and resize it as opposed to
numerous http requests for those additional line images even if each
file itself is tiny).

[color=blue]
> A bit of testing with a few browsers in
> different browsing situations would be advisable, obviously, to
> develop a "feel" for what works and what's best avoided. I've done
> this to some extent in the past, but I haven't done a recent browser
> survey, so I won't try to give any detailed advice just now.[/color]

As a rule of thumb I'd say avoid resizing any image unless you are
looking for a specialized effect or file size is an issue (but even in
the latter case choosing higher compression levels and/or applying
gaussian blurs for jpegs or choosing less colors for gifs is typically a
better option IMO especially when in many cases the perceived
degradation - on the web page - is negligible).

--Nikolaos

[Chris Stromberger]

Re: div width question

Thanks. Overflow looks like what I need.

On Sat, 30 Aug 2003 10:20:32 +0100, Ian Fitchet
<idf@lunanbay.L ESS-SPAM.com> wrote:
[color=blue]
>Chris Stromberger <bit_bucket5@ho tmail.com> writes:
>[color=green]
>> I have a div with a width of 40em (is em cool to use for width?). The[/color]
>
> Real world units (mm, cm, in, pt) are generally hopeless as your
> browser is on the whole pretty clueless about your screen's dpi. My
> laptop's 1400x1050 screen is smaller than my LCD's 1280x1024 but
> Windows almost certainly has them both down as 76dpi (or something).
> Go figure.
>
> That leaves the media's `natural' units (px, and their derivatives,
> em, en and ex). Years ago TeX manuals used to suggest that you use
> em (the height of a capital M in the current font) for vertical line
> spacing and ex (the width of a lowercase x) for horizontal line
> widths. Classically, your line separation would be the order of 1em
> (1.2em rings a bell) and the line width wouldn't be more than 76ex.
>
> Of course, these days it's much more common to be dealing with images
> so it's a bit harder. I'd guess that most people define overall page
> widths/heights in px (because they know how big their images are)
> then, if they're feeling keen, they'll set additional em or ex
> dimensions for text oriented divs.
>[color=green]
>> happen? IE and Mozilla do two very different things. IE expands the
>> div to encompass the line (creating horizontal scrollbars in the
>> browser window if nec). Mozilla lets the line cross the div boundary
>> w/o expanding the div. Which is correct?[/color]
>
> I think this is the `overflow' property.
> http://www.w3schools.com/css/css_positioning.asp is one of many
> references.
>
>Cheers,
>
> Ian[/color]