I have a paging control on my site that has it's container element set to margin:auto so that the pager control are centered within the element. It works great on all browsers except for IE7. In fact, I just realized my site has several issues with IE7 and I'm trying to work through them all. However, I've been stuck on this one for some time.
Take a look at this page.
(I know there are other IE7 issues on this page, focusing on the pager controls first). If you use IE9, you can hit F12 and set the "Browser Mode" to IE7 in the menu bar. Compare it to the same page in any other browser/version.
Can anyone tell me specifically why this is happening based on the CSS/HTML I'm using? I've been trying things for what seems like hours and I'm not really getting anywhere with it.
The problem is that you're relying on display: table to shrink-wrap the ul to the width of the lis inside it. Unfortunately, display: table is not supported in IE7.
Switching to display: inline-block is one way to fix this.
On previous_next_container_forum ul.list_paging, remove display: table and add:
display: inline-block;
*display: inline;
zoom: 1;
The ul is now exactly as wide as the lis inside it, without the use of display: table.
To actually make it centered, you need to add text-align: center to a parent element, such as .previous_next_container_forum.
Related
Can anybody explain to me why the two boxes "Badrum" & "Sovrum" get on top of each other in Safari but in all other browsers they lay side by side.
It used to work in Safari but I can't remember any changes I've done that should affect this.
http://linusfrimodig.se/karin/
I could not figure out the cause, however if you change the flex-flow property to nowrap, it should work (overloading the line 15118 of flatsome.css):
.row, .gallery {
-webkit-flex-flow: row nowrap;
flex-flow: row nowrap;
}
Based on what you mentioned, I can only think of 2 scenarios where such a thing can occur. This question is still too vague to answer, and to get more accurate feedback please provide us not only your problem, but also your code and what you have tried so far.
The scenarios are:
1) The <div> or whatever content "below" the overlaying div is floated, and there has not been a clear: attribute added to the immediate next <div>, or is not optimised for the browser which you see the problem in (-webkit-, -o-, -moz-).
2) The margin of the second <div> is great enough that it lays side by side the floated <div>, or otherwise doesn't get optimised by that browser you're using, and ignores the margin and overlays the first <div>.
Do provide us some code, anything you've tried, as you've mentioned "It used to work in Safari but I can't remember any changes I've done that should affect this.", which means you have tried something.
Here's presentation of the issue. Clicking on "content" square toggles display: table-cell on the pre-content div. In IE10 and FF24 it does not make the red line visible at all, while in chrome 30 it does.
I'm trying to create dockable panel on full-window application which either floats on top, either is one of the two columns, and I'm docking the panel by switching classes: either one with position: absolute, either one with display: table-cell.
Why is there such a difference in behaviour? Any ideas how to fix this?
It appears to be caused by your #pre-content divider being displayed as block by default. For some reason this has 11px width (I'm not sure why, however).
I'm not sure what you're trying to achieve, but can you not simply set this to not display at all by default instead?
#pre-content:not(.table-cell) {
display: none;
}
JSFiddle demo.
Note that I've had to use the not() selector here as IDs have higher specificity than classes, and #pre-content would override .table-cell.
I am new to css and started working on a few simple projects. I ran into a really weird issue styling buttons, though. The following code will not result in a link:
But for some reason, this will:
My question is basically, how in the world to you set the size of a link without having to use float? And why would float work?
Thanks!
It is because an 'a' element is usually displayed inline. You can over-ride it by using display:block;
More on 'display' here: http://www.w3schools.com/cssref/pr_class_display.asp
Regarding float:left;
When floating left, the browser automatically over-rides the display to be a block.
Since "a" is inline element, you must display it as an inline-block
a { display: inline-block; }
to keep it inline but be able to change it's dimensions, padding, margin and basically everything else that you could do with an "div".
There is a IE7 and lower issue with inline-block so you may want to use css "hack":
a {
display: inline-block;
*display: inline; //* stands for IE7 and will not affect Chrome, Firefox and other browsers including IE8+
*zoom: 1;
}
If you look at this code: http://jsfiddle.net/b3KaM/2/
in IE7 the <a> tags do not stretch to their parent <li> width even if display: block; is set. You can see the difference with the background color set to red on the list items and yellow on the links.
it obviously work fine in FF/Chrome & friends.
EDIT:
the complication here is that I cannot set a fixed width - the link text should stay on one line and the whole list should expand as needed.
I'm aware that this as been asked before and I've found a few questions on SO but I could not find a valid solution to this issue - any ideas anyone?
If not - is it safe to say that is not possible to achieve the same result on IE7 as on other browsers, i.e. it's an Internet Explorer bug with no workaround?
This problem is caused by a rendering phenomenon in IE7 and lower known as hasLayout.
To fix the problem, you must simply prevent your a elements from "gaining layout".
Unfortunately, there's massive list of stuff that causes an element to "gain layout".
Your a elements currently have overflow: hidden and min-height set. If you remove those properties, it will work in IE7.
With block you have to give the width also for the element.For example:- http://jsfiddle.net/b3KaM/8/
According to microsoft, IE8 and IE9 support the :after selector. I use this selector to force elements to have the proper height, if all the elements inside are floated. This allows backgrounds to show up properly, without having to specify a set height.
My after code typically looks like this:
.after:after{
content: '.';
height:0;
line-height: 0;
display:block;
clear:both;
visibility:hidden;
}
So now to the bug. When I added a few :after to my page at https://spartanstats.com/reach-stats-gamertag and I hover over each of the li elements in the middle of the page, IE9 grows the page by one line each time.
EDIT:
Upon further investigation the :hover property on each of the dynamically generated li elements is seemingly the root cause of the problem. Removing the hover code for the li's fixes the problem. Of course this isn't the fix I was hoping for. I'll keep investigating.
Currently I'm lost in finding the solution to this issue. But I know my users will potentially hate the site when it starts growing out of control!
Came across this issue myself. It may be related to this issue
Apply min-height: 0% to the containing element.
Have you tried using
content: '';
instead of
content: '.';
Having a character in your after element and setting it to use
display: block;
visibility: hidden;
will still cause the element to take up space on the page unlike when you use:
display: none;
My guess is that even though you're setting the height of the :after element to 0, the . in the element is causing Internet Explorer to render an unwanted height.