I have a <textarea> that needs to fit into a space whose size is not pre-determined (is a percentage of the screen size). I can get good results if FireFox by setting the regular CSS properties:
#container { width: 70%; height:70% }
#text_area { width: 100%; height: 100%; margin: 0; padding:0; }
However in IE 6 and 7 I get different, odd results. In IE6 the textbox appears to have padding to both the left and the right, pushing the size of my container to grow. In IE7 the textbox has padding to the left, but does not make the size of the container grow - instead its right edge pushes outside of the container.
The height setting seems to have no effect in either IE6 or IE7; the <textarea> is 2 rows long in both cases, ignoring the height:100% directive.
Is there a consistent way to size a <textarea> across browsers?
Is there a way to get rid of the padding to the left of the <textarea>?
Update
Using position:absolute removes the padding, but the width:100% is still screwed up. IE7 seems to calculate the 100% width to be too large, resulting in a <textarea>that spills out of the <div> that contains it.
I'll create a stand-alone example if I get a chance...
I've seen this problem with ASP.Net textbox controls also in IE7. I couldn't remember where I found a solution (but props to the person that found it), but I was having the same problem where the textbox with width="100%" would actually break the DOM and my entire content section would "spill" onto a neighboring section (such as a table based navigation).
The solution I eventually adopted was to wrap the asp:Textbox inside its own table and set the "table-layout:fixed; width: 100%" property and on the textbox/textarea "position:relative; width: 100%;" so the block would look like this:
<table style="width: 100%; table-layout: fixed;">
<tbody>
<tr>
<td>
<asp:Textbox id="txtMyTextbox" runat="server" Width="100%" style="position: relative;"/>
</td>
</tr>
</tbody>
</table>
This is not the prettiest solution, but I have verified that it does work cross all browsers. I have a write-up on this issue HERE.
Hope this helped.
There may be a sneaky CSS way to achieve this that I don't know about, but in my experience this is one of the things where using a bit of Javascript is justified.
You could get the height you need (of the current window I presume) using JQuery or Prototype, or in pure Javascript: Get the height of the current document and then
document.getElementById("text_area").style.height = calculated_height+"px";
The left hand padding I find odd, though. Can you post an example?
In order to solve this kind of problems, one has to think about how percentage is handled in the browser. First of all.... percentages don't exist, they are converted to pixels at some point. The steps are 1) browser renders all tags, 2) browser measures outer, parent, percent-sized boxes to get its size in pixels, and sets the size of the child boxes according to their percentage size.
I think the first thing to verify is the size of textarea's parent box, and it's parent box, and so on. This can be done by checking the "Layout" information in Firebug and IE Developer Toolbar, and find out what's measured differently in both browsers. Once you find that element (or elemets) css can be adjusted to consider them.
Have in mind that percentage sizing considers the width and height of parent box content to size the child element and not padding. So, if a parent box width is 500px and has 100px padding, a child element with 100% width will be 500px and the 100px padding will be around it, and both elements will take 700px of your screen.
Try
adding a min-height:100% on the text area css. On the div containing the absolute positioned , set the position to relative on your css.
also use transistional Doctypes instead of strict, while your at it. Make sure there are no unclosed tags. I would be better if you can make the page XHTML or HTML standard compliant so that you will have less problems with cross browser compatibility.
Try adding display:blockand border:0 to your #text_area.
The former should take care of the height-issue and the latter prevents the width:100% to spill over.
Related
What is major differences in using these css rules
div{width:100px; overflow:hidden;}
And
div{max-width:100px; overflow:hidden!important;}
Is there going to be any cross-compatibility Issues.
max-width is great for stating "don't go any bigger than this, but it's OK if it's smaller".
This might be great if you were doing say a speech bubble that could be dynamic in size (depending on content) and you wanted the div surrounding speech bubble to vary.
width on the other hand says "the must be 100px", which means even if the content within the div is smaller, the surrounding div will still be 100px.
Example:
http://cdn.gottabemobile.com/wp-content/uploads/2013/10/photo1.png
max-width: 100px is not different from width: 100px if you do not have width specified. And the !important flag only prevents from overriding the property, so it depends on the context if that makes a difference.
I'm trying to understand the effect that margin has on two elements. I have the following HTML, see the dabblet:
<p>some text</p>
<pre>some code</pre>
I have the following CSS:
body { color: white; }
p { background: red; margin-bottom: 50px; padding: 20px; }
pre { background: purple; margin-top: 40px; padding: 20px; }
So I've given the paragraph tag a bottom margin of 50px, and I've given the pre tag a top margin 40px. I was expecting therefore to find 90px vertical distance between them, but only have 50px.
I understand that the margins are collapsing, and that if I want to fix this then I need to add display: inline-block to the pre tag. But that causes the width of the pre tag to collapse.
Again, I know that I can fix the width problem by adding width: 100% to my pre tag, but I've got padding on the pre tag (20px), so this causes my elements to be too wide. I know that I can use box-sizing to deal with that, but what an almightly pain in the crotch it is to have to mess about with width, display and box-sizing just to have the desired amount of vertical space between two elements. So I simply refuse to do any of that.
Instead, I've decided that I'm just going to add margin-top: 90px to my pre tag, which will guarantee that I've got the 90px space that I want.
My question is: Are there any browsers out there that don't collapse margins in the way the others do? Will I inadvertently end up with 140px space (90px from the top-margin of the pre tag + 50px from the bottom margin of the paragraph tag)? In other words, are margins collapsed reliably and consistently across all browsers, or is there a browser out there that does it's own thing?
It's hard to give a definitive answer to this question because it's very broad. "All browsers" is a lot of browsers. There could always be some fringe browsers you never heard of that handle this differently. It all depends on how the browser's CSS rendering engine was written.
That said, any browser that wants to be taken seriously will try to adhere the W3C specs, which have the following to say about margin collapsing:
In CSS, the adjoining margins of two or more boxes (which might or might not be siblings) can combine to form a single margin. Margins that combine this way are said to collapse, and the resulting combined margin is called a collapsed margin.
Adjoining vertical margins collapse, except:
Margins of the root element's box do not collapse.
If the top and bottom margins of an element with clearance are adjoining, its margins collapse with the adjoining margins of following siblings but that resulting margin does not collapse with the bottom margin of the parent block.
Horizontal margins never collapse.
Source: Box Model (w3.org)
I figured it'd be a nice addition to just put your code to the test in as many browsers as possible. I made a test page page of your html (slightly modified), with an absolutely positioned 50px high block that should fit right in between the collapsed margin, to make it easier to spot a difference:
http://files.litso.com/playground/margin.html
Then I ran this through browsershots.org to get screenshots of how browsers would display this piece of HTML:
http://browsershots.org/http://files.litso.com/playground/margin.html#
(I have no idea how long this will stay cached, but I guess you could always just run it again)
Interestingly, the positioning of the blue block is a few pixels off in a bunch of the screenshots. You can still tell the margins are collapsed correctly, but I do wonder what exactly the problem is with the positioning.
The only browsers that don't seem to collapse the margin correctly are Dillo 3.0.2 and Links 2.7 on Debian 6.0, neither of which seem to listen to padding or margin properties at all (nor to the absolute positioning for that matter). They would mess up your layout no matter what, and you shouldn't worry about it. People use browsers like these for a specific reason, and seeing your page exactly as you intended it to be seen is not one of them.
TL;DR: Yes, it's safe to say that all browsers collapse these elements reliably and consistently.
First of all, I am searching for a pure CSS solution. I can do it really easily with JavaScript, so don't bother giving me hint on how to do it in JS.
I have a web page with 3 container. 2 of them are fixed, the other one is static.
I want to give the static container a padding top and bottom equal to the fixed container.
The first fixed element have a fixed height, so that's not a problem, i give a padding equal to the height :
#header{
height : 100px;
position : fixed;
}
#content{
padding-top : 100px;
}
But the second fixed element is dynamic since we are using a CMS. Some element can be added by the client and we want the layout to adjust automatically.
You can easily see what i'm trying to do in this Fiddle, just uncomment the JS to see the desired Result.
P.S.: I support iE8 and older.
P.P.S.: I am totally aware that it may be impossible w/o JS. If so, just tell me in comment.
Since #header and #footer are fixed positioned, they are taken out of the document flow and have no relationship to #content anymore.
Therefor you have to options (imho).
1) give the footer a fixed height, so you can do the padding trick, same as with your header.
2) use Javascript, since there is no pure CSS solution (except for 1. point).
After experimenting with the css3 flex-box proporty, I quickly noticed some differences in Chrome and Firefox.
In particular: if you set a width on an element that should be flex,
firefox will flex the element according to what it needs, it takes the width style into account but its only a variable.
Chrome will respect the with style fully,
An example:
<div id="box">
<div class="flex-box">Test</div>
<div class="flex-box">Test Text</div>
</div>
If the 2 divs inside the box have the same width assigned, chrome will make them the same size. Firefox will reconize that the second div needs more space, and thus it gets more allocated.
who is right?
Remember the flex doesn't apply to the width, it applies to the free space after the minimum intrinsic width has been determined. This produces counter-intuitive results in several common cases, as has been pointed out on the www-style mailing list. I've found that, unless you want the CSS re-ordering or the multi-line (which isn't yet implemented in Firefox and Chrome), what you think you want to use display: box and box-flex for you really want to use display: table and display: table-cell.
But back to your actual question: I found Firefox and Chrome display identically if you set a width in pixels, but not if you set a width as a percentage. As far as which browser is doing it correctly at the moment, it's a fair bet Firefox is implementing what the spec originally intended as the original spec is describing what the XUL property does, and the XUL property is what this is all based on. As others have mentioned, whether or not the final spec ends up matching this original intention is unknown.
I don't think any browser is right or wrong as flexbox is still a working draft. At any time the spec could change and render another browser right or wrong.
http://www.w3.org/TR/css3-flexbox/
I disagree with robertc's statement "But back to your actual question: I found Firefox and Chrome display identically if you set a width in pixels, but not if you set a width as a percentage."
I am currently using the flexbox in an attempt to show how simple it is to convert a rather heavy in JS and CSS site to a very simple HTML/CSS3 site. Once conclusion I have come to with regards to setting width in pixels:
#main {
display: box;
}
#main > section {
width: 120px;
padding: 10px;
border: 5px solid #000;
}
In chrome, the total width = 120 + 20 + 10 = 150px
In ff, total width = 120px (the 20px padding are inside the 120 and the 10px border is as well)
Another inconsistency I found, in chrome, #main IS greedy and takes up 100%, as you would likely expect. In Firefox, you need to set with to 100% on #main in order for it to act as you would expect.
I'm still working on ironing out all differences in all supported browsers, I will try to post when I have more to add to this. Sadly, as cool as he flexbox model is, and as easy as it makes a lot of shit, its far from consistent.
One more thing, using CSS transitions to change dimensions works well with explicitely defined dimensions (ie. pixels)... but if the dimension is defined by the box's flex, the animation simply jumps between the flex values... no where near as smooth (though, instead of heaving flex of 5 and 1, you could have flex of 500 and 100). In fact, chrome will not animate between flex values, just jumps. FF on the other hand does this nicely.
I'm just really hoping things progress to the way FF handles flexbox, while chrome is close, I just don't agree with how some things are handled, and the lack of animation between flex values just plain sucks.
I am trying to make a table-like calendar page, using fixed width and height block level elements. There is an outer container, which sets the width, and the cells get aligned by float: left. It works well in every browser, except in IE6, where the list gets split after the 29th element.
If I make the outside container a bit more wide (by at least 3 pixels) the problem gets fixed in IE6. Because the elements are more than 3 pixels wide, it doesn't change how the page looks. But I really don't understand why it happens, and what should I do not to make it happen.
I tried IE7.js, but it didn't help.
I know IE6 is such a buggy old browser, but while my sites are simple I prefer making them IE6 compatible.
link to the page in question
You can fix it by adding this to the bottom of style.css:
/* IE6 hack */
* html #naptar-list a, * html #naptar-list div {
width: 77px
}
This works by using the Star HTML hack to feed to only IE6 the declaration width: 77px (1px less than the actual width), which in my testing, fixed the problem: I'm not entirely sure why.