I've been working on trying to fix an issue with print CSS and IE where things would disappear when printing in landscape mode.
It appears the issue is that the element I'm trying to print (a large DIV with content inside it) spans two pages when put into landscape mode. What is happening is when the element spans two pages, the first page is blank, and the second page is printing what would normally be left over from the first page.
I think it's related to contained floats:
wrapper div
floated div1
floated div2
If I set the two nested divs to float: none in the print CSS file, then IE will print them, albeit not in the layout we'd like.
Before I spend another hour on this, anyone know what, specifically, is the issue here and if there's a known workaround?
The problem for me was that I was setting display:inline-block for the main container div. This along with declaring a width is a method to make a parent div extend to contain the floats inside.
I've removed display:inline-block and used clearfix instead. Problem fixed.
It seems to be a problem with tables, but it may just be the nesting, but it is an IE bug.
http://support.microsoft.com/?kbid=257097
Still trying to work around the problem myself.
Related
I'll admit that CSS is not my cup of tea, so it's possible that I'm missing something obvious here. My problem is that when I have an element that has both CSS properties of "clear: both;" and "height: 100%;" the element actually ends up going past the page height. Here is an example: http://jsfiddle.net/d9mv7/
Notice that the blue frame causes a scrollbar to appear and exceeds the page height despite being "100%". When "clear: both" property is removed, it renders as expected (JsFiddle still adds an unneeded scrollbar, but when rendering normally, I don't have that issue).
My intent is to have the bottom div (the blue one in JsFiddle) go until the bottom of page height, but stop at the bottom of the page, drawing the border correctly, same way as on the sides. The problem is that I do have content above the div that has a float property, requiring div to have the "clear: both" property to render correctly (unless there is another way without having to hardcode the pixel size).
I've tried wrapping both the top (float element) and bottom div inside an additional div, such that their height is relative to that div instead of the page. This seemed to make the overlap smaller (and scrollbar shorter), but did not make it go away. Using "overflow: hidden;" will not work for me either, since it still makes the div and the content go beyond the bottom, only hiding the scrollbar. How do you guys suggest I handle this (preferably without JavaScript)?
As the two other posters suggested, I ended up going with a JavaScript solution. If someone can find a CSS-only solution that makes no assumptions about size/contents of the divs, please post it and I will change the accepted answer. Here is how I'm handling it for now (this uses jQuery, but similar logic can be done with native JS):
$('#second-panel').height(document.height-$('#first-panel').height());
Alternatively, if your divs have margins/padding/borders that are thick enough to matter and you want them included in the measurements as well (because element.height() doesn't), you can use outerHeight:
var secondPanel = $('#second-panel');
var borders = secondPanel.outerHeight()-secondPanel.height();
secondPanel.height(document.height-$('#first-panel').outerHeight()-borders);
I'm attempting to get this menu working in IE7. I've squashed every bug but this one.
When you hover a list item, the UL's within the drawer that pops out won't float next to one another properly. If you look at the page in Chrome, that's how I was setting up the CSS before (display inline block, etc). That didn't work either so I tried floating them left.
Floating left fixed an issue I had with extra text-indent on the left of each li, but the ul's still will not float properly.
Does anyone have any ideas?
http://playground.willpracht.net/megaMenu.html
Redo your code to remove as many of the > selectors as you can. They are making everything much harder to deal with. It's like giving everything an id, and makes overriding things longer and longer and longer.
Honestly I would have sub-divs instead of just menus, because you're making the first li's look like headers but semantically making them no different from all the other links. Actual headers with links inside make more semantic sense. For example there's a link called tools and then the rest of the sibling links are... tools.
Anyway, when floating things, look at your widths. I see a lot of elements with no widths declared at all. In IE, with floats, this is important. I would set widths (they can be in em if you want) of the sub-divs, and then widths for the floating ul children inside. Their combined widths together should not equal 100%. For example, if a div is 140px wide, don't try two floated ul's inside each with widths of 70px, even though that should fit, and will in most browsers.
I have some example mega menus if you'd like to see, but there are many already out there and I don't believe I have one with floating ul's inside the submenu.
I have no idea what I'm doing wrong, but for some reason, I'm experiencing a bug with my markup that is causing my body element and my html element to not take up the entire viewport in the browser.
I can't get to the bottom of this. It first reared its head when I tried to add a 10px purple border to the top and bottom of my body.
If you inspect the page in Firebug, you you can see that there's a huge chunk of the page that is not highlighted when you hover on the html element or the body element. And the border that I applied at the bottom is hanging up very far on the page.
Does anyone know why this is? Could it have to do with my using HTML5?
Here's the page in question:
http://electricorangecreative.com/test/index.html
And here are my style sheets:
http://electricorangecreative.com/test/reset.css
http://electricorangecreative.com/test/style.css
Use a sticky footer technique.
I've had a look at the current test page and it looks like the only outstanding issue is the vertical scrollbar still appearing without need to. Easiest fix for this is to simply remove any margin or padding you have on elements you've set to height:100%. The culprit I identified is div#wrapper. Take off the padding there and the issue is resolved (in FF at least - not tested on other browsers). Since the padding is added to the height you end up with an element that stretches over 100% vertically. Use margins on children instead of padding - should be fine!
I am trying to just create a basic layout, but i am having trouble to get it to auto-adjust the height.
Something is wrong with the DIV-container since it's not adding the padding correctly to the top and bottom elements. It should be the size of the highest block, right now its the menu block.
Any ideas?
Website
in the container that holds your divs (the one whose height is not adjusting), use a css clear fix. Your container div will adjust once you use this method.
Add overflow: hidden; to the CSS for that particular <div>.
Inspect your HTML by using Google Chrome or Firefox with the firebug addon. Is so easy to see where and where not there is correct padding, margins etc... Additional ye see all css for a selected element as well...
Btw. When you are using padding, are you sure the rows above and below are cleared ?
Tried using margins instead?
removed
So if you look at the tabs and look at hw2, you'll notice it has a little extra spacing that overlaps the spacing on the right. That's because wrapped the div in the <li>. You will notice the others not having it. I don't understand why is it making that extra little spacing after I wrap it.
Just for the record, this is for CSS spacing which has nothing to do with the JS.
Update: I found a ghetto work around!
Is it a space (or the absence of one)?
display: inline will respect whitespace.
You are putting a block level element (div) inside an inline element (li), which is invalid. Most browsers do a reasonable job of rendering this sort of thing, but the results are unpredictable.
I would suggest using divs for the higher level menu. You could use a container div for the menu and float divs within that for the individual tabs.
I ended up just changing the css for that page.