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.
Related
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.
I'm trying to accomplish something specific around platform constraints I'm under.
I created a somewhat self-explanatory jsfiddle of the problem at http://jsfiddle.net/MrV5M/4/
The specific problem:
On Chrome, the right border of the input box is cut off.
On Safari, the width of the content class cell exceeds the container so it spills over the border.
On IE9, the label doesn't float to the left of the content div
The main reason I care about Safari is because I'm working on a JQuery Mobile/PhoneGap app which is also a web app. I'm only supporting modern browsers, but this is driving me nuts. Normally I'd just use a table for the container, but the text-overflow: ellipsis styles on the content div don't work when inside a table. (Basically, I'm trying to keep the content to a single line and have ellipsis without enforcing a fixed width or calculating a width with Javascript)
Anyone have the l33t CSS skills to make this work? I sure don't... :)
Just add this CSS to your Stylesheet, and get peace of mind on your issue :D
* {
-webkit-box-sizing: border-box;
-moz-box-sizing: border-box;
box-sizing: border-box;
}
You may not like this answer. I made some adjustments in the css which fixes Chrome and IE9 issues. Take a look,
http://jsfiddle.net/MrV5M/11/
There are many ways to do what you are trying to do, but if you insist on using 'flex' stuff which is largely un-supported (even in the majors see here), you'll need to add the vendor prefixes to flex.
e.g... -webkit-flex, -moz-flex
Also, I don't think you need to be setting widths on elements that have the flex property.. not positive though.
So your browser issues:
-IE doesn't support flex at all so you're label won't float unless you use a float.
-The reason your input/content is spilling over the container and getting cut off is not really anything to do with flex.. but the way css works.. setting an element to 100% width means setting it to the width of its parent. But by default, css doesn't count the padding/border-width as part of that width. So you end up getting 100% width plus the L/R padding and border. But, since you are only supporting modern browsers.. box-sizing:border-box; to the rescue. Google it for details, but putting it on your input element should do the trick.
I've designed a fixed-width page which renders equally in Chromium, Firefox, Safari, but has a small issue in (from what I can tell) ALL flavours of IE. I've added some conditional styles for IE, which make things a bit better, but it's still off (by only a couple of pixels).
The site in question is here: http://www.brushesfacepainting.co.uk/brushes/home
IE and Chromium rendering side by side is shown here: http://www.brushesfacepainting.co.uk/images/renderissue.jpg
I added conditional styles for IE to fix the width of all the elements, prior to this, the banner style was much narrower than the body.
I assume I'm hitting up against an IE bug, but I can't figure out which one! Can anyone help please?
Thanks,
Lee
Your mainbodyie rule has a width that is different than the width in your standard css. (851px vs 848px). Fix that to match your other wrappers.
Also your page is not centered in IE - I suggest you wrap whole page in a fixed width wrapper with margin:0 auto to center whole page - so you don't keep repeating the width multiple times in your css for each layout element.
/* ONLY FOR IE */
DIV.mainbodyie{
width: 848px;
}
DIV.mainbody{
padding-right: 0;
}
Use a div structure for enclosing all content like header,middle,footer inside it.Add following code for this div:
.test{
overflow:auto;
margin: 0 auto;
}
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.
If you view this page in IE7: http://65.60.10.2/~marionin/ , why are the light purple headers ("Spotlights", "Serendipity Projects", "Marion Institute Blog") hiding underneath the dark purple band?
I have firebugged till my fingers hurt, but I can't figure it out. The column divs are written after the block div, so they should display on top.
Mucking about with the z-index doesn't help, even when setting the positions of the block and the columns to relative.
[Of course, as would be expected, everything looks fine in Firefox, Safari, Opera, and Chrome.]
Thanks for any help!
IE has terrible z-index bugs that are often impossible to grok. I was able to make it behave in IE 7 after some fiddling with the IE developer toolbar.
I noticed that for some reason many elements had z-index defined on them yet these weren't appearing in the HTML. Do you have a script running that is setting any z-indexes? I noticed that they were in reverse order, meaning that the high level elements had higher z-indexes than the lower level elements. This is one way to create numerous bugs in IE. The deeper the HTML appears in the hierarchy, the higher its z-index should be.
I started by removing the z-index on the relevant containers, from body down to the two <div>s in #main-content. I set position: relative on #main-content but left z-index undefined. I set position: relative on the two <div>s in #main-content and set the z-index to 100 and 200 respectively.
Within #content, the first <div>, I added z-index: 110 and the second <div> (the row of blocks with small pictures) I added z-index: 120.
That seemed to get IE 7 to behave correctly.
If there is anything else that has a z-index defined that I didn't mention, try removing it and starting from the ground up. The less elements there are with z-index defined, the less opportunity there is for IE to behave badly.
#block-block-11 {
position: static;
}
...quick fix to a larger issue eloquently detailed by CalebD.