By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,665 Members | 1,952 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,665 IT Pros & Developers. It's quick & easy.

Emulate Max-width & Min-Width (hard)

P: n/a
Internet Explorer always presents me with a challenge (partial
repost). The current issue involves emulating max-width in IE using
the technique described by Svend Tofte.

http://www.svendtofte.com/code/max_width_in_ie/

The CSS code uses JavaScript expressions and feeds the browser's width
to the style. The CSS code follows.

* html #Content {
height: 1%;
width:expression(
document.body.clientWidth > (500/12) *
parseInt(document.body.currentStyle.fontSize)?
"30em":
"auto" );
}

This implementation resizes and displays the fluid width in IE. But it
does not emulate the max-width property. Basically, I need help fixing
the max-width implementation on #Content. Since max-width remains a
challenge in IE, the min-width remains a greater mystery. Min-width
would be nice as well. The page is complex with several wrappers for
other IE display issues and JavaScript functionality. Presently, these
workarounds and hacks have my head spinning.

The page has an overall wrapper #Container. #Content div has the
max-width expression. It encases #div.bgWh, so the page could have
true transparent round corners. One issue relates to how div.bgWh
expands beyond #Content when the client's browser width approaches 260
pixels. These containers serve a purpose; but IE does not deal with
their width in a predictable manner. Fortunately, Firefox does not
have these issues. These scenarios leave me scratching my head more
often than not. Overflow hidden property has worked for me in the
past, but did not provide the magic bullet this time around.

Please load the page and shrink you browser to around 260 pixels. Keep
your eye on the round corners around the main content area. The
container, div.bgWh, expands beyond #Content. Please let me know if
you see any relevant patterns and if you have any useful suggestions
on implementing max-width. Somebody may suggest better approaches to
the IE max-width conundrum.

http://neville.f2o.org/nifty_TEMP1.html

Elements in Question
#Content
div.bgWh
#Container

Jul 21 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
R0bert Nev1lle <robert_neville@y@h00.com> wrote:
Since max-width remains a challenge in IE, the min-width remains a
greater mystery. Min-width would be nice as well.


The IE7 script by Dean Edwards handles both.

Bye,
Martin

Jul 21 '05 #2

P: n/a
R0bert Nev1lle wrote:

http://www.svendtofte.com/code/max_width_in_ie/

* html #Content {
height: 1%;
width:expression(
document.body.clientWidth > (500/12) *
parseInt(document.body.currentStyle.fontSize)?
"30em":
"auto" );
}

This implementation resizes and displays the fluid width in IE. But it
does not emulate the max-width property.


The trouble with this particular method of fudging max-width in IE is
that it uses document.body.currentStyle.fontSize. It only works
predictably if you set font sizes in px units. If you set font-size in
ems or %, it seems to use just the numeric portion of the value, so the
calculation is bogus. Something like 100% needs to be converted to a px
value before the expression can work as expected.

One way I found to do this is to have a specific element that can be
used to do accurate calculations in ems, so it actually scales with the
visitor's text size and isn't dependent on px sizes at all. This element
has to be somewhere above the element using the expression, or it won't
work. The first thing in the body is a good place. It is extra markup,
which I'd rather do without, but it doesn't do any real harm. For example:
<body>
<div id="emTester" style="width:1em"></div>

You can absolutely position this off the screen so it doesn't affect
layout. Then, you have to change the expression to use pixelWidth of
this element instead of fontSize. For example:
width: expression(document.body.clientWidth >
(emTester.style.pixelWidth * 30) ? "30em" : "100%" );

I would tend to compare against something smaller than 100% of
clientWidth, to account for margins or whatever. So, plug various
viewport widths into the clientWidth value, and various font sizes (1em
converted to pixels) into the pixelWidth value and see how the
expression works out. It's pretty solid.

I don't know how the Dean Edwards IE7 scripts do this (reliably), but I
bet it takes a whole pile of JavaScript to do it. If there is another
way to set max-width in ems without the extra markup, I'd surely like to
see it.

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.
Jul 21 '05 #3

P: n/a
On Mon, 18 Jul 2005 10:45:26 -0700, R0bert Nev1lle
<robert_neville@y@h00.com> wrote or quoted :
Internet Explorer always presents me with a challenge (partial
repost). The current issue involves emulating max-width in IE using
the technique described by Svend Tofte.


I have been running into these problems with browsers implementing
different subsets of the features.

If you use XHTML does the situation improve, get worse, or stay the
same?

How can these vendors claim CSS 2 compliance when they don't finish
the job?

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes
Jul 21 '05 #4

P: n/a
Roedy Green <lo*****@mindprod.com.invalid> wrote:
I have been running into these problems with browsers implementing
different subsets of the features.

If you use XHTML does the situation improve, get worse, or stay the
same?
That depends. If you pretend your XHTML is really HTML by sending it as
text/html, then the situtation pretty much stays the same. But if you send
XHTML as XHTML, then things get much worse: MSIE won't display it at all.
How can these vendors claim CSS 2 compliance when they don't finish
the job?


How can "they" claim HTML 4 compliance? For that matter, how can "they"
claim HTTP compliance? Embrace, extend, and all that.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"Cheaters never win; they just finish first." - Johhny Hart
Jul 21 '05 #5

P: n/a
[comp.lang.javascript added as a follow-up]

On 19/07/2005 00:53, kchayka wrote:

[snip]
One way I found to do this is to have a specific element that can be
used to do accurate calculations in ems, so it actually scales with
the visitor's text size and isn't dependent on px sizes at all. [...]
It is extra markup, which I'd rather do without, but it doesn't do
any real harm. [...]
This came up in a.html a while ago, but by the time I got around to
playing with ideas for converting units, the thread was long dead. That,
coupled with the fact that I didn't really like the solution meant I
just forgot about it.

The approach I used is somewhat similar to the one that you're
suggesting, but rather than stuffing in extra markup, the script creates
it dynamically and discards it when done. The calculations are only
performed once and, unless the base font size changes, the results are
reused.

I still don't like the solution as it imposes several restrictions, but
I don't see a way around them at the moment.

- All font sizes must be specified as percentages.
- The font-size property of the root element cannot be altered,
otherwise the script will not respond to font size changes.
- All elements between the element in question and the root must
have an accurate font-size property value.

The latter is the clearly the biggest issue, but the reason is readily
apparent. Consider this snippet:

<!-- ... -->
<style type="text/css">
body {
font-size: 100%;
}
</style>
</head>

<body>
<h1>My site</h1>
<!-- ... -->

The default style sheet will apply a greatly enlarged font size (amongst
other things) to the heading, however, the currentStyle object (the
closest thing to computed style information) will suggest that the
font-size property for that heading is 100% as currentStyle simply echos
the nearest explict value for a property.

If a conversion from one length unit to another needs to be performed in
terms of that heading, then its font-size property, that of the BODY
element, and any intervening elements (none in this case) must be set
explicitly.

A quick solution might be to specify:

html * {
font-size: 100%;
}

and then alter the size of other elements later if necessary.

Anyway, the conversion code is:

var toPx = (function() {
var _r = /^(\d+)([a-z]+)$/,
_u = {},
_b, _d, _f, _u;

function c(u) {
var s, t;

if(_f != _d.currentStyle.fontSize) {
delete _u.em;
delete _u.ex;
_f = _d.currentStyle.fontSize;
}
if('number' != typeof _u[u]) {
t = document.createElement('div');
s = t.style;
s.borderStyle = 'none';
s.fontSize = _f;
s.padding = '0';
s.position = 'absolute';
s.width = 1000 + u;
s.visibility = 'hidden';
_b.appendChild(t);
_u[u] = t.offsetWidth / 1000;
_b.removeChild(t);
}
return _u[u];
}

return function(s, e) {
var z = _r.exec(s),
v, u;

if(!_b) {
if(!(_b = document.body) || !(_d = _b.parentNode)
|| !(_d.currentStyle)) {return NaN;}
}
if(!z) {return NaN;}
if(!(v = +z[1]) || ('px' == (u = z[2]))) {return v;}

v *= c(u);

if(('em' == u) || ('ex' == u)) {
while(e && (_d != e)) {
v *= parseInt(e.currentStyle.fontSize, 10) / 100;
e = e.parentNode;
}
}
return Math.round(v);
};
})();

The function, toPx, takes two arguments. The first is a string that
represents the length value and includes the units (all, except
percentages, are supported). The second is the element used for context,
and only required when converting from em or ex. The return value is an
integer or NaN (not-a-number).

[snip]
width: expression(document.body.clientWidth >
(emTester.style.pixelWidth * 30) ? "30em" : "100%" );

I would tend to compare against something smaller than 100% of
clientWidth, to account for margins or whatever.
As far as Microsoft are concerned, the clientWidth property only
includes the padding of an element, irrespective of which rendering mode
is in use. However, in Quirks mode (or pre-IE6) it will also include
spacing outside the content area of the BODY element as that acts as the
canvas, rather than the HTML element.
So, plug various viewport widths into the clientWidth value, and
various font sizes (1em converted to pixels) into the pixelWidth
value and see how the expression works out. It's pretty solid.


A simpler alternative is to use the auto keyword:

width: expression(toPx('40em', this) < document.body.clientWidth
? '40em' : 'auto');

When resizing through the margin area of the BODY element in Quirks
mode, scrollbars will appear but only for those twenty or so pixels.

That could be countered by subtracting this extra space if rendering in
Quirks mode:

var getCanvasWidth = (function() {
var _b, _s;

return !document.compatMode
|| (-1 == document.compatMode.indexOf('CSS'))
? function() {
if(!_b) {
if(!(_b = document.body)) {return NaN;}
_s = _b.currentStyle;
}
return _b.clientWidth - toPx(_s.paddingLeft, _b)
- toPx(_s.paddingRight, _b)
- toPx(_s.marginLeft, _b)
- toPx(_s.marginRight, _b);
}
: function() {
if(!_b) {
if(!(_b = document.body)) {return NaN;}
}
return _b.clientWidth;
};
})();
width: expression(toPx('40em', this) < getCanvasWidth()
? '40em' : 'auto');

[snip]

The proposal above will work for IE5+. IE4 doesn't supply a currentStyle
object, and has other problems besides.

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Jul 21 '05 #6

P: n/a
Michael Winter wrote:

[a bunch of JavaScript]

Too much JS for my tastes.

:)

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.
Jul 21 '05 #7

P: n/a
This post finally generated a discussion. Kchayka, your point opens a
valid deliberation about the mentioned approach. I need a few days to
digest your full description.

Michael, your JavaScript is a novel approach, yet it is not simple.
Unfortunately, my web development skills fade when I step away from
active development. I am not a full time coder (it is more of a
hobby). If the logic becomes too complex, then it would take me more
time to re-acquaint myself with my code for any edits.

Some people mentioned other approaches found here.

http://www.hedgerwow.com/360/dhtml/c...min-width.html

http://www.ozoneasylum.com/25116

Let me know if you are familiar with them. Honestly, my time is
strained from trying all these approaches. Implementation takes me
time with squashing all the bugs. My HTML and JavaScript is
considerably complex.

I implemented the first approach and it seems ok. But the round
corners remain a Bear; the div.bgWh container continues expanding
beyond the #Content div. This occurrence continues to frustrate me.
Does it relate to the max-width implementation or the CSS? Argh! I can
not pin point the problem. Ultimately, I probably use a fix width
since these workaround provide me more scenarios for me to debug. Let
me know if you have any additional comments.

http://neville.f2o.org/nifty_TEMP1.html
Jul 24 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.