max-width with a percent doesn't seem to work in either IE 8 or Firefox 3. Specific pixel widths work fine. Am I missing something?
I have an input form, and I want to display some explanatory text to the right of it. But I don't want the explanatory text to squash the form.
I haven't used max-width before but it seemed an excellent solution. I wrote this simple CSS style:
div.hint {max-width: 50%; float: right;}
Then I wrote:
<div class=hint>... hint text</div>
<form action=xxx method=post>
... etc ...
The div.hint squashes the form severely to the left.
I tried this with just some text instead of the form. The div.hint takes about 95% of the screen, just gives a small margin on the left, and then the other text is pushed completely below it.
If I change the max-width from a percent to a fixed number of pixels, it appears to work. But I don't want to base it on pixels because I don't know the dimensions of the user's browser.
Does percent not work with max-width despite what I read in documentation, or am I missing something?
In response to Seanmonster's comment: Here, I'll give a trivial but complete web page that illustrates what I thought should work but doesn't:
<html><title>Max width test</title>
<style>
.form {max-width: 75%; float: left;}
.hint {max-width: 50%; float: right;}
</style>
<div class=hint>
<p>Fourscore and seven years ago our forefathers brought forth on this continent a new nation, conceived in liberty and dedicated to the proposition that
all men are created equal. We are now engaged in a great civil war, testing whether that nation, or any nation so conceived and so dedicated,
can long endure. We are met on a great battlefield of that war. We have come to dedicate a portion of that field as a final resting place
for those who here gave their lives that that nation might live. It is altogether fitting and proper that we should do this. Etc.
</div>
<div class=form>
<table>
<tr><th>Label 1 <td>Value 1
<tr><th>Label 2 <td>Value 2
<tr><th>Label 3 <td>Value 3
</table>
</div>
</html>
When I open this page in a browser, I get, not two columns, but the "hint" div taking 100% of the width, and below that the "form" div taking 100% of the width. If I change both the max-width's to "width: 50%", I get two columns as I would expect. Apparently I'm missing something about how max-width is supposed to work, but ... I don't get it.
Max-width works perfectly fine in FF3 and IE8 with percentages. Percentages, however, are based off the parent width. Not children around it.
max-width on IE8 is buggy under multiple scenarios. It is a known issue.
You can find an article on it here. http://edskes.net/ie8overflowandexpandingboxbugs.htm
You need three things to trigger this bug - maxwidth, scrollbars, and float
If you were to float the div.hint and form both to the left and have them both with a max-width of 50%, they shouldn't squish each other.
<div>
<div class="form" style="float:left; max-width:50%">
<form></form>
</div>
<div class="hint" style="float:left; max-width:50%">
</div>
</div>
Related
I made a draft website to learn html, but I noticed that on smaller screens, margin-right: auto doesn't work.
Same with the <center> tag.
I would give the code, but it's pretty big, so I'll just explain what I did:
I put everything in a table and used colspan for more tidyness.
Everything is in a very big div.
The div has width 65%, margin-left:auto and margin-right:auto.
It works perfectly on my pc, but not on smaller screen ones, like laptops. It just appears in the far right, like margin-right is not even there. If I remove margin-left, it goes to the left too much.
I also don't want to measure it in pixels, because it varies from resolution to resolution (right?).
How can I make it work?
You should just remove all these wrappers around table and it'll be good.
You shouldn't also use center tags. center is deprecated in HTML 5 and since you use CSS it's unnecessary. margin: 0 auto is enough.
Using table to build a page isn't good idea too.
You definitely need to read about HTML5 and how to use it to build semantic page layout. Here is good article about that.
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/
I’m making my first full responsive site and I have run into an issue. The site seems to be working as intended in firefox and explorer. The browsers that are giving me issues are chrome and safari.
On the bio/landing page (http://designerdsite.com/new/) toward the bottom of the page are two sections one titled “I Got Skills”, the other titled “and they love me for them”. When I load the page (no matter what size the browser width is) it loads correctly however after the browser width is shrunk and then reopened the layout repositions. In the “skills” section the div on the right side is falling below the div on the left. In the setion “they love me” the text is falling below the pictures. It seems for some reason the width on the container div is not being understood. Perhaps its something else. I am really not sure what is going on here and would very much appreciate any advice anyone has. Thank you!!
I discovered a similiar issue on my site. As far as I could figure this out, it seems that Chrome/ Webkit has a problem with the correct (re-)positioning of floated elements.
So there are 2 (maybe more) options:
1. You may use Javascript to force the Browser to re-render (not reload!!!) these elements (e.g. by changing the display property to none and back to block)
2. Use another positioning variant like 'inline-block' or 'table-cell'
Why don't you use twitter bootstrap that will make your life really easy.
it seems like you used media-query for your site right???...anyway so iguess you know the reason....for example lets assume your last media-query max width was defined as 600px ...then it will work fine upto 600px and below(not far)....when your browser is resized to width:480px (for ex.) then your design like font-size,padding etc are getting very large to fit two divs side by side....so if you want to keep your design intact for microscopic width then lets have one more media query definig that limit max-width:480px;
for example
.fonts{
font-size:18px;
}
#media screen and (max-width:480px){
.fonts{
font-size:10px;
}
}
Seems like an issue with all the percentage widths. I know WebKit can have issues with nested and rounded percentages etc, so when the page is resized both the widths on the images and quotes, as well as padding on the parent element are recalculated.
You'll see if you remove the padding: 0 5% on the max-width class, the problem no longer occurs.
Try wrapping the quotes in a 100% width div:
<div class="quote-wrapper" style="width: 100%;">
<div class="reference clear-both">
<img src="images/monica.jpg" alt="Monica" class="reference-pic">
</div>
<div class="quote">
<p><em>“Paul is the most committed hard working person I've had the pleasure to supervise. If he was unfamiliar with something he did the research to inform himself and others. Paul is one of those rare breed of people who comes to a supervisor with options not just problems.”</em></p>
<p>Monica Luchak, Former Director of Creative Services, BoardSource</p>
</div>
</div>
It has to do with how browsers compute percentages. A quick fix for that is to set a max-width for the left container:
#skills-left {
float: right;
width: 47%;
max-width:411px;
}
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
I have noticed a problem with size of elements in Chrome browser.
I have written a simple code:
<html>
<body>
<table border="1px">
<tbody>
<tr>
<td>
<span style="display: inline-block; width: 5cm">TEXT</span>
<span style="display: inline-block; width: 5cm">TEXT</span>
<span style="display: inline-block; width: 5cm">TEXT</span>
<span style="display: inline-block; width: 5cm">TEXT</span>
</td>
</tr>
</tbody>
</table>
</body>
</html>
I expect to have 4 spans repeated vertically, 5cm each. It works on IE, Firefox, etc.:
IE - Works fine
But Chrome suffers the following problem:
Chrome - Doesn't work
In IE, spans have 189px width each and td has 772px.
In Chrome, spans have 189px width each and td has 771px.
Is this some kind of Chrome issue? Why my td element doesn't fit its content? It's important for me to stay with those span elements (I cannot replace them with i.e. div) and to set width in cm. The issue still exists when I remove table border.
CSS cm units are unreliable if you want a fixed number of pixels. They're also not likely to actually measure 5cm on the screen. The cm unit is intended mainly for printing styles. Yes, it can be used on screen, but don't expect any accuracy from it.
The fact that a 5cm box is rendered as 189 pixels tells us that a cm is not a whole number of pixels. This alone should be enough to tell you that you're unlikely to get accurate pixel-level cross-browser rendering using cm units.
It's just not going to happen. If you want pixel-perfect accuracy, use px units.
You say in the question that you can't change the units. You really should reconsider that if possible, because it's only going to keep giving you these issues.
If you really can't change them, then the one way I can think of to resolve your issue without changing the units is to give the <td> element a white-space:nowrap style. This should force all the spans onto the same line regardless of whether the browser thinks they should be there or not. It should do the trick for you. But it doesn't resolve the underlying problem, and it will likely come back in other ways if you keep using cm units on the screen.
As for what exactly is causing the glitch in the first place, I would guess that Chrome is handling the floating point pixel values slightly differently, and that there is a rounding error when it adds the pixel widths of the spans to work out how wide to make the <td>. If this is the case, then it sounds like a bug in Chrome, and you could report it to them, but given everything I've said above, I can't see them making it a high priority issue.