Why Chrome overwrites height & overflow CSS - html

I am having a problem with the following page in plunker. I also have tested it outside of plunker and I get the same result. My problem is that the following CSS get lost somehow. When I look at the computed CSS in chrome the width and height are different even when I can see that it recognized that rule. I am using bootstrap CSS.
table.scroll {
width: 40px;
height: 40px;
overflow: scroll;
}
EDIT:
The intention was to make the table scroll-able. But there no scroll bar appears. The CSS looks correct but apparently it does not work on tables. And the browser just ignores the CSS.

According to the W3C, user agents may reflow tables if the width of their cells is greater than the width that the author specifies. Chrome cannot possibly fit all of that data in a 40x40 table, so it scales it up to fit.
There are some ways to fix the width of the area containing a table, but it will probably require extra markup.

Related

Resizing a table-layout: fixed table in Safari?

Here's a CodePen: https://codepen.io/neezer/pen/eWvLrm
Load that pen in Chrome (I'm running 57.0.2987.133).
Change the width of the <table> to 150px using a style attribute. Don't do this in the code (as it will cause a refresh--that's specific to CodePen and not my issue), but instead change it programmatically through the console or in the web inspector.
Note how Chrome resizes the table and does the proper overflow for the td/th elements:
Load that pen in Safari (I'm running 10.1 (12603.1.30.0.34)).
Change the width of the <table> to 150px using a style attribute. Don't do this in the code (as it will cause a refresh--that's specific to CodePen and not my issue), but instead change it programmatically through the console or in the web inspector.
Note how Safari does not resize the table to the given dimensions, since the td/th do not appear to shrink smaller than their content.
Why is this different? The only explanation I can think of is that Safari does not repaint the table on style changes, taking table-layout into account. I found this in the MDN docs:
Under the "fixed" layout method, the entire table can be rendered once
the first table row has been downloaded and analyzed. This can speed
up rendering time over the "automatic" layout method, but subsequent
cell content may not fit in the column widths provided. Any cell that
has content that overflows uses the overflow property to determine
whether to clip the overflow content, but only if the table has a
known width, otherwise it won't overflow the cells.
The difference to me seems that Chrome re-evaluates the table when it detects a dimension change on the <table>, but Safari does not, and thus does not overflow the cell.
I can make this problem go away if I ensure that <table> has a set width on initial render, but that's a no-go for my app, which allows the user to dynamically resize table dimensions. Needless to say, it works great in Chrome but not Safari.
Is there anyway to have Safari behave like Chrome here? Some way to force Safari to do the re-evaluation, if that is what's actually happening here?
Do Firefox/IE/Edge suffer from the same problem? Could they benefit from the same solution?
UPDATE: This little experiment in Safari's web inspector seems to confirm my theory: http://d.pr/v/bzhIH
You could wrap your <table> in <div>, set table width to this <div> and width: 100%; to the <table>.
If you want stretch your <table> for the columns content width, you need to replace width: 100%; from <table> and set width: auto; to <div>.
Here's example: https://codepen.io/Izumenko/pen/zaGGRM

element with height 100% and overflow

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

Zooming in Firefox Causes Page Layout to Break

I'm having trouble with this page: http://seatgeek.com/atlanta-hawks-tickets/. If you zoom out one level from the "normal" setting in Firefox, the page looks like this: . This happens with both versions 3.6 and 4.0 of FF. It does not happen with Webkit.
Clearly the problem lies in the elements within the "list_details" div. The problem can be fixed by decreasing the width of the "col1" or "col2" spans by 1px or by increasing the "vevent" li element by 1px, but these fixes cause the design to render improperly.
If you add up the width of "col1" and "col2", also taking into account their horizontal padding and border, the total width is 647px. But it only displays properly in Firefox (when zoomed out one level) when the "vevent" element, which contains the two, has a width of 648px. Why is that?
as this appears to have been bumped, but the original code is not available, I can say that the difference would have been caused by rounding (or sub pixels), the OP said the problem didn't happen when the div was 648px wide.. an even number can be halved, or split between 2 columns (OP also mentions 2 columns) quite easily no matter the zoom level
However the odd number647px will have been treated differently by Firefox
I cannot say exactly how as I can no longer see the widths of the two columns, but this blog post by John Resig, may explain better
Sub-Pixel Problems in CSS
one possible solution, or at least a helper, is to make sure the available width of the container is always divisible by the number of columns?
removing the margin-right from the following css fixed the zoom out issue
#left_container .search_details .list_details {
margin-right: 1px;
}
Add the margin-right:-1px to the following css. This can fix the zoom out issue.
.team-show .static-sidebar {
line-height: 22px;
margin-right: -1px;
position: relative;
width: 255px;
}
For future reference those looking for a general answer to why zooming can cause layout breaks
http://dev.jeffersonscher.com/resolution.html
Also use relative units to size things
https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/Values_and_units

images with width: 100% in table cells don't scale right in IE

I have a 3-column table which contains images. All td's have width="33%", and the images contained have CSS width:100%. In FF and Opera, the images scale like I want them to, i.e. fill the entire width of the cell, maintaining their aspect ratio. However, in IE7, they behave quite differently: I think the pic with the largest width stretches the entire column, and the smaller ones are stretched up to the new available width.
The page in question is: http://mybgagent.com/print.php?offers_id=4515
(I know the site is a mess, I didn't code it)
Any advice on what to do? Setting css position:absolute makes images scale correctly in IE, but breaks scaling in Opera and FF, as well as positioning in all browsers.
I ran into this issue a lot with IE7 "compatibility" mode. the easy fix was to not only put
width: 100%;
in my css, but also
width: 100%;
float: left;
cleared that nasty hiccup right up.
Sounds like you have a solution for each browser but no way to target it, well here comes the CSS Browser Selector to help you with that! Just plug in this jQuery to your site (in the <head> section), then write separate rules for IE and the real browsers and append .ie before your IE selectors :)
Works great, I use it all the time!
Example:
myTd
{
background: #f00; /*whatever your rules are*/
}
.ie .myTdv
{
position: absolute;
}
And that's it!
Try setting the style of the parent cell to position:relative.

How do I specify in HTML or CSS the absolute minimum width of a table cell

Summary
What's the best way to ensure a table cell cannot be less than a certain minimum width.
Example
I want to ensure that all cells in a table are at least 100px wide regards of the width of the tables container. If there is more available space the table cells should fill that space.
Browser compatibility
I possible I would like to find a solution that works in
IE 6-8
FF 2-3
Safari
In order of preference.
This CSS should suffice:
td { min-width: 100px; }
However, it's not always obeyed correctly (the min-width attribute) by all browsers (for example, IE6 dislikes it a great deal).
Edit: As for an IE6 (and before) solution, there isn't one that works reliably under all circumstances, as far as I know. Using the nowrap HTML attribute doesn't really achieve the desired result, as that just prevents line-breaks in the cell, rather than specifying a minimum width.
However, if nowrap is used in conjunction with a regular cell width property (such as using width: 100px), the 100px will act like a minimum width and the cell will still expand with the text (due to the nowrap). This is a less-than-ideal solution, which cannot be fully applied using CSS and, as such, would be tedious to implement if you have many tables you wish to apply this to. (Of course, this entire alternative solution falls down if you want to have dynamic line-breaks in your cells, anyway).
Another hack is the old 1x1 transparent pixel trick. Insert an 1x1 transparent gif image and set its width in the image tag to the width you want. This will force the cell to be at least as wide as the image.
I know this is an old question but i thought I'd share something that wasn't mentioned (Although pretty simple in concept..) you can just put a <div> inside the table (in one of the <td>'s or something) and set the <div> to min-width. the table will stop at the <div>'s width. Just thought I'd throw that out there in case somebody comes across this on google. Also, I'm not so sure about how min-width is handled in I.E6. but that has already been covered in another answer.
I had some success with:
min-width: 193px;
width:auto !important;
_width: 193px; /* IE6 hack */
Based on a combination of Vatos' response and a min-height article here: http://www.dustindiaz.com/min-height-fast-hack/
what about this css property
min-width: 100px
but it doesn't really work in IE6 if not mistaken
if you don't want to do it in the css way, I suppose you can add this attribute
nowrap="nowrap"
in your table data tag
This is a cross-browser way for setting minimum width and/or mimimum height:
{
width (or height): auto !important;
width (or height): 200px;
min-width (or min-height): 200px;
}
IE 6 doesn't understand !important
IE 6 sees width/height:200px (overwriting auto)
Other browsers understand the min- and the !important
I am not 100% familiar with the behaviour of widths in TD elements, but this all works nicely on eg DIV tags
BTW:
Based on a combination of Vatos' response and a min-height article here: http://www.dustindiaz.com/min-height-fast-hack/
This is not working because of the order of the first 2 lines, they need to be in the right order (think about the above) ;)
IE6 handles width as min-width:
td {
min-width: 100px;
_width: 100px;/* IE6 hack */
}
If you want IE6 to handle width like normal browsers, give it an overflow:visible; (not the case here)