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

Table cell width ignored in IE6

P: n/a
I have a site that runs in strict mode in IE6, and IE is making <td>s
for simple two-digit numbers really wide. So I want to restrict it (and
right-align it) by using <td class="number"> and .number { width: 10px;
}. In Mozilla this works, but IE ignores this. Next to adding an
invisible "0" precding one-digit numbers, what can I do to solve this?
Jul 20 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
"Philipp Lenssen" <in**@outer-court.com> wrote:
I have a site that runs in strict mode in IE6, and IE is making <td>s
for simple two-digit numbers really wide.
As usual, a URL would be essential, since this surely depends on various
ingredients on the page or associated with the page.
So I want to restrict it (and
right-align it) by using <td class="number"> and .number { width: 10px;
}. In Mozilla this works, but IE ignores this.


Why do you set the width in pixels? If it "worked", it could cause serious
trouble.

There's no way to say "two characters wide" in CSS. There's even no
guarantee that all digits have the same width, but this happens to be the
case in all - or at least almost all - fonts. But none of the CSS units
corresponds to the width of a character. The ex unit can be used as a coarse
guess, but for safety, I would use something like width: 2.5ex for a field
that contains two digits.

On the other hand, browsers may ignore anything you say about widths. You
can make most graphic browsers honor your widths for table cells if you set
table-layout: fixed for the table, telling that the browser should apply a
fixed algorithm for allocating the widths, using the _first_ line of the
table as the basis. But then you open a can of worms, especially if you have
used the px unit - content that doesn't fit will (by default) be omitted,
procrustinated.

So I think you should first analyze what causes the problem. Normally a
browser allocates just the needed width for a column. But if you set e.g.
width: 100% for the entire table, then the browser has a problem, and will
probably make it your problem too.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Jul 20 '05 #2

P: n/a
Jukka K. Korpela wrote:
"Philipp Lenssen" <in**@outer-court.com> wrote:
I have a site that runs in strict mode in IE6, and IE is making
<td>s for simple two-digit numbers really wide.
As usual, a URL would be essential, since this surely depends on
various ingredients on the page or associated with the page.


The page is not yet intended for publication. I'm working on a client
and cannot show the URL (it's password-protected anyway at the moment).

There's no way to say "two characters wide" in CSS. There's even no
guarantee that all digits have the same width, but this happens to be
the case in all - or at least almost all - fonts. But none of the CSS
units corresponds to the width of a character. The ex unit can be
used as a coarse guess, but for safety, I would use something like
width: 2.5ex for a field that contains two digits.

Sounds good.
You can make most graphic browsers honor your widths for table cells
if you set table-layout: fixed for the table, telling that the
browser should apply a fixed algorithm for allocating the widths,
using the first line of the table as the basis. But then you open a
can of worms, especially if you have used the px unit - content that
doesn't fit will (by default) be omitted, procrustinated.
Exactly, I don't want to open that can. I played around with fixed
table-layout and I find it really annoying.

So I think you should first analyze what causes the problem. Normally
a browser allocates just the needed width for a column. But if you
set e.g. width: 100% for the entire table, then the browser has a
problem, and will probably make it your problem too.


Yes, currently the width is set a defined pixel value, like 615px. This
causes IExplorer to do some strange things. Maybe I can just get rid of
the width in this case. In others, I can't, because several pages
contain the table of a similar structure, but single cells carry the
same meaning and should look alike. But in this case I might just do
that, let the width be automatically adjusted to the content. Will see
if the art director or client likes it though!
Jul 20 '05 #3

P: n/a
Philipp Lenssen wrote:
The page is not yet intended for publication. I'm working on a client
and cannot show the URL (it's password-protected anyway at the moment).


You could give us the source code or a link to the source code. We don't
need images to check if it is correct ;-)

--
Anne van Kesteren
<http://www.annevankesteren.nl/>
Jul 20 '05 #4

P: n/a
Philipp Lenssen wrote:
Jukka K. Korpela wrote:


So I think you should first analyze what causes the problem.
Normally a browser allocates just the needed width for a column.
But if you set e.g. width: 100% for the entire table, then the
browser has a problem, and will probably make it your problem too.


Yes, currently the width is set a defined pixel value, like 615px.
This causes IExplorer to do some strange things. Maybe I can just get
rid of the width in this case. In others, I can't, because several
pages contain the table of a similar structure, but single cells
carry the same meaning and should look alike. But in this case I
might just do that, let the width be automatically adjusted to the
content. Will see if the art director or client likes it though!


OK, I'm afraid the auto-width isn't acceptable from a layout POV. Will
have to figure out something else... actually, like I said, Mozilla is
doing just fine -- I have some cells which have an auto-width, and some
which have a fixed width, so why shouldn't the browser be able to
figure out to have the auto-width cells occupy what's left over of the
width?
Jul 20 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.