I have HTML such as:
<html>
<body>
<table>
<tr>
<td>
<img style="width: 300px; height: 300px;"></img>
<img style="width: 300px; height: 300px;"></img>
</td>
<td>
hello world
</td>
</tr>
</table>
</body>
</html>
When the page/window is decreased in width, the second image is pushed below the first image.
My question is: Why doesn't the TD cell shrink to to 300 width with the images are stacked? It seems to stay unnessarily large - causing an ugly gap to be between the images and the text of the next cell. Is there any way to force the cell to either 600 or 300 in width depending on how much room there is?
To understand the behavior of the table layout in your example, you need to review
the table width algorithms used by CSS to visually lay out the table:
http://www.w3.org/TR/CSS21/tables.html#auto-table-layout
The table width algorithm looks at the content in the cells making up each column and
determines a mininum and maximum value for the column width. The algorithm then tries
to allocate enough space to each column taking into account any specified column width
values, specified table width and so on.
In this case, the browser tries to allocate 600px (plus a bit for the white space between the two images) and some width for the text in the second column.
If the window is wide enough, all the content fits in a single line in each table cell.
However, as the window width shrinks, the algorithm will shrink each column width (the details here will vary among browsers since the CSS specification does not prescribe a detail algorithm).
The algorithm appears to be shrink each column proportionately. For the first column, this forces the images to wrap with the gap to the right. In this case, the algorithm
does not do a second pass to redistribute the excess space. The algorithm works pretty
well if you are wrapping words. However, when the content is a 300px wide image, the
result is big (ugly) gaps.
So, the table is working as it should, but the results are not ideal.
The table width algorithms try to be efficient by minimizing the number of times it
loops through the content to determine widths and heights. In this case, a more
sophisticated algorithm would be needed to get more pleasant results, but it would also
be a bit subjective.
Note: To fix the layout problem, you would have to build a JavaScript function to do the
math to get the column width to work out. I think this could be quite difficult to make
it foolproof.
You could add style='white-space: nowrap;' to thetd element to prevent the wrapping.
http://jsfiddle.net/mpWn3/
Take the widths away from your image tag. Add them in css for a start...
table img {max-width:100%;}
but yes - you would be better off with making it responsive. This is possible with tables. Read this article: http://css-tricks.com/responsive-data-tables/
My short answer would be to stop using tables and dive into a responsive div layout.
<div class='con'>
<div class='picture_con'>
<img src='img1.jpg'></img>
<img src='img2.jpg'></img>
</div>
<div class='text_con'>
Your text here
</div>
</div>
And then make it work with css
.con {
width:100%;
}
.con .picture_con {
display:inline-block;
}
.con .picture_con img {
width:300px;
display:inline;
}
.con .text_con {
display:inline;
}
This is all very well for big screens but now we need to deal with smaller screens. To do this we use #media css queries
#media(max-width:600px) {
.con .picture_con {
width:300px;
}
.con .picture_con img {
display:block;
}
}
Edit: If tables are really necessary
Here is an example of a responsive table design that does the job aswell
http://jsfiddle.net/4VHd5/
Related
I have been trying to force a table to fit in a printable page, regardless of how many items exist and am having trouble doing so. the only way i have found is to change font size but that isn't exactly automatic.
i have found a lot of answers setting with to a specific width, but the vertical side is difficult. I dont want any overflow to occur and resize the text to show all content in that box.
like here
i have been using a setting of 300px wide and 777px tall
Should be as simple as:
table
{
max-height: 300px;
max-width: 700px;
}
table, table * {white-space: nowrap;}
Use in css table-layout:fixed. For more info: https://www.w3schools.com/cssref/pr_tab_table-layout.asp
I have a grid view and i want it to take the fix width a give it. for the columns that are too long, I want it to break then into rows and merge my fixed width . So far some one suggested putting the grid in div as below.
.container
{
width : 1000px;
height:auto;
float:left;
overflow:hidden;
display:block;
}
<div class="container">
my grid here
</div>
i did this and it successfully fix the width by cutting the remaining three columns that fall beyond the width. Please i need something that will force the grid to merge in everything in to given width by breaking long columns in to rows. Any help would be apprecaited.
May be this will help you...
You can fix the column width like this
<asp:BoundField DataField="" HeaderText="" ItemStyle-Width="5%" ItemStyle-VerticalAlign="Top" />
but if your data is too big to fit in there then you have to make short your data to fit in there.
What I basically need to achieve is to have an element (div, span, table, whatever) to consume 100% of its' parent height and show scrolls if it's content is taller.
The problem is, only chrome and IE in quirks work OK with height:100%; overflow: auto;. Firefox, Opera and IE in standards (any IE 7+, any "standards") just ignore the overflow and stretch the html element below the parent size. If I set fixed height it works, but I can't determine the available height before rendering, there are multiple possible values.
Simplified example (jsFiddle for this):
<body>
<div id="parent">
<table id='container'>
<tr>
<td>
<div id='element-in-question'>
<!--Content long enough to stretch the div-->
</div>
</td>
</tr>
<tr>
<td id='footer-cell'>
<div id='footer'>I'm footer<div>
</td>
</tr>
</table>
</div>
</body>
Css:
#parent { height:500px; width:500px; position:absolute; }
#container { height: 100%; width:100%; }
#element-in-question { height:100%; width:100%; overflow: auto; }
#footer-cell { height:30px;}
#footer { height: 30px; }
In real app all this stuff runs in an iframe, table is used to render header and footer and so on. Please do not suggest stop using tables, it's legacy application with 100+ places that need attention. CSS only solution would be ideal.
One more point: it should work in Chrome, IE10 standards mode. FF, Opera and Safari are not supported, IE9 and below handled differently.
Update: there are about ten footers with different heights, ideally the solution should not depend on fixed footer height.
Here you go:
Updated fiddle.
The problem is that height: 100%; is going to fill the next defined container. For whatever reason, tables aren't seen as a valid container for that purpose. So what we need to do is utilize some of the quirkiness of how tables are laid out.
position: absolute;
top:5px; left:5px;
right: 5px;
bottom: 40px;
overflow: auto;
border: 1px solid green;
background-color: #eee;
No need for relative positioning on the td. Don't ask me why, perhaps someone more knowledgable than I can chime in.
Regardless, with this we can force it to expand to fill a set amount of space, while still allowing:
The footer to be visible.
The padding to be present (even if it's not technically padding.)
This solution to work in a cross-browser environment.
Really hope this helps; if it doesn't, I'd be more than happy to give it another shot.
Update
You said that javascript isn't how you'd like to do it, but here's a short solution using jQuery which would actually solve the problem:
Updated Fiddle
$('td > div').each(function() {
var t = $(this);
var text = t.html();
t.hide();
t.height(t.parent().height());
t.show(text);
});
Why this works:
The div needs its parent to have a defined height before 100% height works, however that's not an option for you as you've already stated that this is all dynamic content. No problem. We just need the jQuery to push the calculated height to the div after the browser has already rendered it. Simple enough, right?
Well, not so fast. Divs aren't meant to be bounded by table cells, at least not ideally. We already have something that serves as a logical, separate container in the td, and the div doesn't much care what the td's height is if it has a boatload of content that's spilling over its borders already. And when we go to query the height of that td, no matter what it actually is, it's going to report that it's larger than the elements which it contains. So, if you look on the fiddle after commenting out the lines where we empty the div, you'll see that the td is erroneously reporting itself to be almost 900 pixels tall.
So what do we do?
Well, we take that content away from the div. Now it's just a husk, and it's going to be smaller than its container in every circumstance. That means that the td isn't going to lie about misreport its size when we query it, since it's confidently containing its children.
And once we get the truth from the TD, we tell the div that the size its parent has reported is the size that it needs to be, and give it back its content.
Voila. You've got a div that actually respects its parent now. If only real children were that easy.
The basic behavior of HTML tables
Here's a demo showing how small and extra-large content affects the width and height of a table. There are gray rulers alongside the tables, showing the intended dimensions of the tables. Standalone version of the demo.
Scrolling extra-large variable-size content in a table cell appears to work to some extent vertically, and not at all horizontally.
For height, there are 3 different outcomes in different browsers:
The overall height of the table is correct. This occurs with Chrome and Safari (Webkit browsers).
The content row occupies the intended height of the overall table, and the footer row adds additional height to the table, causing the table to be a little taller than intended. This occurs with Firefox and Opera, and IE7/8/9/10 in Standards mode (though in IE, the footer cell is even taller than the height of the footer content, which adds significant extra height to the table).
The entire height of the content row is displayed with no scrollbars, causing the table to be much taller than intended. This occurs with IE7/8/9/10 in Quirks mode.
For width, the outcome is comparable to #3 for all browsers (the full content width is always displayed with no scrollbars).
CSS compromise
The closest to a CSS solution that appears to be possible is setting a fixed height for #element-in-question (though letting it remain scrollable), and allowing the footer to vary in height. The overall size of the table would vary by however much the different footers vary in height. If the height difference of the footers is small, or if it's not critical that the overall table always has the same height, then this may be a reasonable compromise.
The CSS posted in the question would look something like the following (giving #element-in-question whatever height is determined to be optimal, when combined with the average or most-common footer height).
#parent { width:500px; position:absolute; }
#container { width:100%; }
#element-in-question { height:450px; width:100%; overflow: auto; }
#footer-cell { }
#footer { }
Here's an updated version of the demo posted in the question, using the changes listed above (tested in: IE7/8/9/10 Standards and Quirks mode, Firefox, Chrome, Safari, Opera). If there are difficulties running JSFiddle in older versions of IE, try this standalone version of the demo.
The website design appears to go beyond the bounds of what HTML tables are capable of. Unless some constraints can be imposed upon the design (such as the one described here), it looks like this will require JavaScript or jQuery.
I've got a workaround for this.tbody tag is added automatically in firefox and that cause the problem. Add height:100% to your td and height:90% to your tbody. The tbody tag never existed so you should add it with css.
table tbody{height:90%}
Live Demo
This isn't really a problem as such, but I would like to know what's going on so I can understand it. I'm currently coding a new website which has required me to use a single table in the footer of the design. (I don't often use them, but this table just makes life a lot easier for this project.)
I am using a CSS class for the tables td with the only element being width:%; but for some reason I just can't understand, increasing the % from 10% to 20% actually makes the td's smaller in width. totally backwards.
I'm really stumped by this one, can anyone explain this?
HTML:
<div class="footertable">
<table border="2">
<tbody>
<tr>
<td valign="top" class="footer">
<div class="footerheading">SHOPPING</div>
</td>
<td valign="top" class="footer">
<div class="footerheading">CUSTOMER SERVICE</div>
</td>
<td valign="top" class="footer">
<div class="footerheading">PAYMENT OPTIONS</div>
</td>
<td valign="top" class="footer">
<div class="footerheading">SOCIAL</div>
</td>
<td valign="top" class="footer">
<div class="footerheading">ORDER</div>
</td>
</tr>
</tbody>
</table>
</div>
CSS:
.footertable { margin:auto; max-width:1080px;}
td.footer {width:10%;}
Notes:
The strange behavior happens for percentages lower than 24: from 15 to 23 the total width decreases, and from 23 to 24 it suddenly expands. For percentages higher than 24, you have normal behavior.
It doen't matter if you specify max-width or just width for the table
The problem is reproduceable in chrome, firefox, opera and IE9
jsFiddle here: http://jsfiddle.net/BPygA/
Table layout has its fans and haters, but one thing is for sure, it's an advanced maneuver. It's like a combination of forces, some weaker, some stronger, that ultimately determine your column widths. And there's a lot of input variables:
table-layout:fixed or not
Table has a specific width (in pixels or percent or not at all)
Do all columns have widths?
Is there a colgroup element in the table?
How much space is available for the table?
Do any cells have non-breakable content?
It's kind of a nightmare for the inexperienced.
In your particular situation you table has no specific width, meaning it'll be the sum of the widths of the columns. But the columns are sized in percentages, which would be percentages of the total table width. You can see this is a chicken-and-egg problem.
Also using percentages that don't add up to 100% is kind of undefined.
I'd take a step back and think about what you're trying to achieve exactly.
I can see the behavior switching between 10 and 20% width on the table cells.
Adding a width to the table itself (not the containing DIV) changes the behavior:
http://jsfiddle.net/BPygA/2/
Without a width on the table itself, the browser is making a best guess on how to display the cells based on their content. I'm not sure why it chooses a smaller width when the percentage is set to a larger number, but it's a non-deterministic calculation so the browser is free to do what it wants (see spec below).
In other words, without a width on the table you are telling the browser that each cell is 10% of a variable value that it is free to determine.
Another consideration may be that the table has 5 cells. Setting each one to 10% results in a total width of only 50%. Once again, the browser has to guess about the total width, but also has to determine what to do with the remaining 50% that is not accounted for.
As #Jacob pointed out the W3 defines recommendations (but only recommendations) to guide user agents in how to render tables.
This algorithm reflects the behavior of several popular HTML user
agents at the writing of this specification. UAs are not required to
implement this algorithm to determine the table layout in the case
that 'table-layout' is 'auto'; they can use any other algorithm even
if it results in different behavior.
The UA should try to use the requested percentage, but it may not always be possible.
A percentage value for a column width is relative to the table width.
If the table has 'width: auto', a percentage represents a constraint
on the column's width, which a UA should try to satisfy. (Obviously,
this is not always possible: if the column's width is '110%', the
constraint cannot be satisfied.)
http://w3.org/TR/CSS2/tables.html#propdef-table-layout
I would be curious as to a better explanation.
Currently the table is too wide and causes the browser to add a horizontal scroll bar.
CSS:
table {
table-layout:fixed;
}
Update with CSS from the comments:
td {
overflow: hidden;
text-overflow: ellipsis;
word-wrap: break-word;
}
For mobile phones I leave the table width but assign an additional CSS class to the table to enable horizontal scrolling (table will not go over the mobile screen anymore):
#media only screen and (max-width: 480px) {
/* horizontal scrollbar for tables if mobile screen */
.tablemobile {
overflow-x: auto;
display: block;
}
}
Sufficient enough.
If the table content is too wide (as in this example), there's nothing you can do other than alter the content to make it possible for the browser to show it in a more narrow format. Contrary to the earlier answers, setting width to 100% will have absolutely no effect if the content is too wide (as that link, and this one, demonstrate). Browsers already try to keep tables within the left and right margins if they can, and only resort to a horizontal scrollbar if they can't.
Some ways you can alter content to make a table more narrow:
Reduce the number of columns (perhaps breaking one megalithic table into multiple independent tables).
If you're using CSS white-space: nowrap on any of the content (or the old nowrap attribute, , a nobr element, etc.), see if you can live without them so the browser has the option of wrapping that content to keep the width down.
If you're using really wide margins, padding, borders, etc., try reducing their size (but I'm sure you thought of that).
If the table is too wide but you don't see a good reason for it (the content isn't that wide, etc.), you'll have to provide more information about how you're styling the table, the surrounding elements, etc. Again, by default the browser will avoid the scrollbar if it can.
table { width: 100%; }
Will not produce the exact result you are expecting, because of all the margins and paddings used in body. So IF scripts are OKAY, then use Jquery.
$("#tableid").width($(window).width());
If not, use this snippet
<style>
body { margin:0;padding:0; }
</style>
<table width="100%" border="1">
<tr>
<td>Just a Test
</td>
</tr>
</table>
You will notice that the width is perfectly covering the page.
The main thing is too nullify the margin and padding as I have shown at the body, then you are set.
Instead of using the % unit – the width/height of another element – you should use vh and vw.
Your code would be:
your table {
width: 100vw;
height: 100vh;
}
But, if the document is smaller than 100vh or 100vw, then you need to set the size to the document's size.
(table).style.width = window.innerWidth;
(table).style.height = window.innerHeight;
Set font-size in viewport-width-related units, e.g.:
table { font-size: 0.9vw; }
This will make font unreadable when page is too narrow, but sometimes this is acceptable.
Put the table in a container element that has
overflow:scroll;
max-width:95vw;
or make the table fit to the screen and overflow:scroll all table cells.
There is already a good solution to the problem you are having. Everyone has been forgetting the CSS property font-size: the last but not least solution. One can decrease the font size by 2 to 3 pixels. It may still be visible to the user and for somewhat you can decrease the width of the table. This worked for me. My table has 5 columns with 4 showing perfectly, but the fifth column went out of the viewport. To fix the problem, I decreased the font size and all five columns were fitted onto the screen.
table th td {
font-size: 14px;
}
For your information, if your table has too many columns and you are not able to decrease, then make the font size small. It will get rid of the horizontal scroll. There are two advantages: your style for mobile web will remain the same (good without horizontal scroll) and when user sees small sizes, most users will zoom into the table to their comfort level.