Need over-ridden width table element: works but breaks height

Hi,

I have a table that is being generated by a database, there are several fields that have longer type content while most fields are very happy living within the natural size of the td elements (with respective padding, font-size…).

Using php I drop classes onto the table cells that need their width over-ridden.

Her is a bit of the table:


<tr>
     <td>2</td>
     <td>2011-07-02</td>
     <td>2011-07-02</td>
     <td>2011-07-02</td>
      <td class="location_cell">Some longish location from the database</td>
</tr>

And the css to deal with the width over-riding:


    td.location_cell
    ,td.program_cell
    ,td.address_cell{
        width: 200px;
        display: block;
    }

When using this css the table cell’s width does set; however it loses the height of the the surrounding cells. With borders surrounding the table’s cells it looks bad.

I have tried numerous things to have the height go to 100% of its’ containing element with no luck. Things I have tried:

  • used display: inline-block instead of display: block;
  • set the height to 100%;
  • wrapped div inside and outside the cell - very bad, ugly, hacky and improper, but it did not help anyway.
  • set has-layout.
  • other things to embarrassing to mention :wink:

I can not specify a fixed height as the other column table cells sometimes have content that wraps 2 or more lines; by setting an explicit size it would not grow with the surrounding cells, leaving the same problem.

Is this possible or am I stuck.

Regards,
Steve

Maybe a little more to go one will help? :slight_smile:

Here is all the css applied to the table including inheritance:

On Table:


table {
    background-color: #EFEFEF;    border: 1px solid #103A6C;    border-radius: 3px 3px 0 0;    font-size: 10pt;    height: 250px;    margin: 10px 0;    width: 653px;}style.css (line 711)html,  body, div, span, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote,  pre, a, abbr, address, cite, code, del, dfn, em, img, ins, kbd, q,  samp, small, strong, sub, sup, var, b, i, hr, dl, dt, dd, ol, ul, li,  fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr,  th, td, article, aside, canvas, details, figure, figcaption, hgroup,  menu, footer, header, nav, section, summary, time, mark, audio, video {    border: 0 none;    margin: 0;    padding: 0;}style.css (line 3)
Inherited frombodybody {    font-family: Frutiger,"Frutiger  Linotype",Univers,Calibri,"Gill Sans","Gill Sans MT","Myriad  Pro",Myriad,"DejaVu Sans Condensed","Liberation Sans","Nimbus Sans  L",Tahoma,Geneva,"Helvetica Neue",Helvetica,Arial,sans-serif;
    font-size: 1em;
}

No CSS on the TR elements.

On TD elements:


table td {    border: 1px solid #103A6C;    border-radius: 3px 3px 0 0;    padding: 0 5px;    text-align: center;    width: auto;}

On td that needs extra width:


td.location_cell
, td.program_cell
, td.address_cell {
    border: 1px solid #103A6C;    display: block;    height: 100%;    width: 200px;}style.css (line 735)

Here is a picture of what is happening:

Normally I like to publish a link to the actual page as it is much easier to diagnose, but in this case my client does not want this published in the public domain. (:

Regards,
Steve

Hi,

Remove the display:block because that means its not a table-cell anymore. A cell is display:table-cell and not display:block and as its already a cell you don’t need to tell it what it is :slight_smile:


td.location_cell, td.program_cell, td.address_cell {
	border: 1px solid #103A6C;
	width: 200px;
}



<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Untitled Document</title>
<style type="text/css">
table {
	background-color: #EFEFEF;
	border: 1px solid #103A6C;
	border-radius: 3px 3px 0 0;
	font-size: 10pt;
	height: 250px;
	margin: 10px 0;
	width: 653px;
}
html, body, div, span, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, address, cite, code, del, dfn, em, img, ins, kbd, q, samp, small, strong, sub, sup, var, b, i, hr, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td, article, aside, canvas, details, figure, figcaption, hgroup, menu, footer, header, nav, section, summary, time, mark, audio, video {
	border: 0 none;
	margin: 0;
	padding: 0;
}
body {
	font-family: Frutiger, "Frutiger  Linotype", Univers, Calibri, "Gill Sans", "Gill Sans MT", "Myriad  Pro", Myriad, "DejaVu Sans Condensed", "Liberation Sans", "Nimbus Sans  L", Tahoma, Geneva, "Helvetica Neue", Helvetica, Arial, sans-serif;
	font-size: 1em;
}
table td {
	border: 1px solid #103A6C;
	border-radius: 3px 3px 0 0;
	padding: 0 5px;
	text-align: center;
	width: auto
}
td.location_cell, td.program_cell, td.address_cell {
	border: 1px solid #103A6C;
	width: 200px;
}
</style>
</head>

<body>
<table>
		<tr>
				<td>2</td>
				<td>2011-07-02</td>
				<td>2011-07-02</td>
				<td>2011-07-02</td>
				<td class="location_cell">Some longish location from the database</td>
		</tr>
</table>
</body>
</html>


Hi,

Originally I did not have any display settings; however the width will not show unless I have display: block or display:inline-block.

I understand what you are saying regarding ‘not having to tell that it is a cell’ but this:

 td.location_cell
    , td.program_cell
    , td.address_cell{
        width: 200px;
        border: 1px solid #103a6c;
    }

I get this: You can see the width is not honoured on the Program 1 cell.

Earlier I posted all firebug output for the CSS inherited and direct; there doesn’t seem to be any inherited settings that would be causing this to not resize the width? Any further thoughts on this?

Regards,
Steve

If you have set table-layout:fixed on the table then the width probably won’t be honoured.

The same applies if there’s not really enough room for it all to fit and the cells are re-adjusted.

In my small example above it shows it is working.

Hi,

I checked the width of the table and it was set to 650px and on the #search_results div. I changed that to width: 100% and width: auto with no luck. I also removed any of the widths on the upper nodes so that none that I could see should restrict the width of the table. I don’t know if the widths play a role as the overflow is set to scroll? In any case none of this has worked yet.

The div where the table is located has this:

.overview_leads div#search_results {
    overflow-x: scroll;
    overflow-y: hidden;
}


It needs to scroll as there is far to much content to show in the size of the site.

I asked the client If I could post the link again and explained how forum help is often limited by what you can show; they gave the ok for me to publish the link until I get this fixed. Here it is: scrolling table. Can you see anything getting in the way of the sizing?

Thank You!!!
Steve

Hi,

The cell is being compressed once it reaches the browsers edge (because that’s what tables do).

You could try something like this to offset the effect.


[B]#search_results table{float:left;margin-right:-3000px;}[/B]

.overview_leads table td.location_cell, .overview_leads table td.program_cell, .overview_leads table td.address_cell {
    border: 1px solid #103A6C;
   [B] display: table-cell;[/B]
    width: 200px;
}


You don’t need the display:table-cell just remove the inline-block you had.

The negative margin on the floated table needs to be big enough for all your data so you may need to tweak it a bit larger than you should ever need.

The only other solution I think is the old fashioned spacer gif (which is why the were invented).

Or you could set white-space: nowrap on the cell but that assumes one line of content only that you don’t want to wrap.

Hi,

This does work, so thank you!

#search_results table{float:left;margin-right:-3000px;}

However I don’t quite get why this works? float: left removes the table from the document flow then sets it to the left of the nearest position: relative container. Then, margin-right: -3000px should bring the right margin to the left; whereas I thought that 3000px would create a margin 3000 the right; so to provide room before the collapsing border of the table (don’t know if I got the collapsing border idea right here)?

When your time is so valuable, thanks for going the extra mile on this one,!

Regards,
Steve

Glad it helped:)

I had to expand my original demo above until it went pass the browser window to see the effect that you were getting.

However I don’t quite get why this works? float: left removes the table from the document flow then sets it to the left of the nearest position: relative container. Then, margin-right: -3000px should bring the right margin to the left; whereas I thought that 3000px would create a margin 3000 the right; so to provide room before the collapsing border of the table (don’t know if I got the collapsing border idea right here)?

When your time is so valuable, thanks for going the extra mile on this one,!

Regards,
Steve

This is just one of the useful behaviours of floats and a negative margin on the opposite side of a float (i.e. margin-right on a left float or vice versa) creates negative space (unlike a static element) and allows any content to the right of the float to overlap the float as if the float wasn’t there. This is in effect allows the float to pass out the side of the browser window without ill effect. It’s a technique that can be used for horizontal scrolling of items without using a width.

Hi,

This is just one of the useful behaviours of floats and a negative margin on the opposite side of a float (i.e. margin-right on a left float or vice versa) creates negative space (unlike a static element) and allows any content to the right of the float to overlap the float as if the float wasn’t there. This is in effect allows the float to pass out the side of the browser window without ill effect. It’s a technique that can be used for horizontal scrolling of items without using a width.
This is an awesome explanation!

Where was I hiding? Under a rock maybe… 2007 the

This is just one of the useful behaviours of floats
was discussed :eek:! Great Article!

Thanks so much Paul!
Steve