I am using Css3 effects to make my menu look fancier , no issues with that however , I dont know for some strange reasons , when I click on the menu items , they dont redirect to desired pages ie my href="abc.aspx" wont work in Firefox , Opera , but works well in Chrome.Here is the Css3 code which I use
#Menu a:active,
#Menu a.active:before,#Menu a:hover:before
{
Content: ' ';
position:absolute;
z-index:-1;
width:0px;
height:0px;
left:50%;
top:50%;
border-radius:50%;
box-shadow:0 0 35px 30px #ADD7E7;
}
My menu looks something
However when I remove that Css3 styling , the href works.Can anybody help me out with this as to why this happens.
Any suggestions are welcome.
Thanks
The problem may stem from styling #Menu a:active together with the pseudo elements. Try separating them or even just remove #Menu a:active from the definition altogether. Then you can set your z-index back to -1 as it will only be being applied to the pseudo element.
I've set up a jsfiddle here.
It is most likely because of this line in your css:
z-index:-1;
The default layer is 0 of the document but since on hover you are setting it to -1, you won't be able to click on it.
The z-index:-1 places the element behind the body. As such, it can't be clicked because the body is obscuring it.
This is however a little ambiguous if you haven't defined a background colour for the body, as transparent background colours may not catch clicks.
Avoid negative z-indices. They can go pretty much as high as you want in the positive numbers, more reliably then negative.
Related
I'm having a problem on a website with Safari 7 (on OSX).
The website address is:
<Edit: Address not valid anymore. Sorry.>
If you click on vertical newsletter button, on the right edge of the content box, an overlay will pop-up.
This overlay looks good on most browser, but there is a problem with safari.
The overlay content is an absolutely positioned box of fixed width. It contains a div with the class "bg", which is a div with CSS position set to fixed and CSS top, right, bottom left set to 0.
The desired (and normally obtained) effect, is that this bg box sizes up to the width and height of the viewport. In safari, it just behaves as if it had it's position set to "absolute" - it just sizes up to the width and height of the container div.
Is this a known issue with Safari? Is there a bug filed? An update?
I could probably fix that by rewriting small parts of the HTML, CSS and JavaScript (if someone has an easier solution, you're welcome to share it!) but I'd like to understand what's happening at first.
I'm not sure what's going on with that positioning thing, but here was my approach to get the same result across the browsers:
#overlays .overlay { /* line 1081 */
...
width: 100%;
height:100%;
...
}
#overlays .overlay .content.text { /* line 1185 */
...
margin:0 auto;
...
}
You could use Z-index but Z-index is not reliable with position:fixed, as shown in this fiddle: http://jsfiddle.net/mZMkE/2/ use translateZ transformation instead.
transform:translateZ(1px);
on your page elements.
EDIT: In your code, Add this css:
.bla, .projects, .contact {
-webkit-transform:translateZ(1px);
-moz-transform:translateZ(1px);
-o-transform:translateZ(1px);
transform:translateZ(1px);
}
and then remove z-index refs from those elements and .intro.
Also You can try in other browsers as well
I have two boxes. The first one contains simple text. The second one contains a submit input with no borders, paddings, margins.
So, why the input takes more height than the simple text?
I know that I can play with the padding and remove the box height, but for my purposes I need to set it a static height, and prepare this box to be reusable for both inputs and simple texts.
I have tried to play with line-height and vertical-align properties, without success.
What is causing that extra line-height?
There's an example to play with it.
Edit: I recently see, that the issue is only with Firefox...
I think it could be for the line-height property in the Firefox CSS:
But... in first place I can't believe what my eyes are seeing. An !important in the internal browser stylesheet? That's normal? Could this be a possible answer?
Similar question with the same answer.
But the trick Leniel suggest doesn't work for me...
The extra padding is on your .buttonarrownext class.
Fixed CSS Class:
.buttonarrownext {
cursor:pointer;
position:relative;
border-radius:4px;
text-align:center;
background:white;
border:1px solid red;
padding: 0px; /* changed the padding here */
margin:0px auto;
display:inline-block;
}
A JSFiddle to demonstrate.
As mentioned in my comment, it displays fine in IE and Chrome, but not FF. A quick solution is to replace the input with a button.
updated html would be:
<div class="container">
<div class="buttonarrownext">Siguiente</div>
<div class="buttonarrownext"><button class="reset">Siguiente</button></div>
</div>
There's no real difference as you can still fire a submit event with a click handler for the button...
It will be interesting to find out why FireFox does this though...
Updated fiddle - http://jsfiddle.net/QfPGW/2/
I have a div class set up with the following CSS style:
div.multiple_choice{
border: 1px solid black;
max-width: 300px;
max-height: 200px;
overflow: auto;
}
The problem is, when the text inside doesn't force the DIV to reach the maximum height of 200px, the vertical scroll bar still shows up. I can click on the up and down arrows but it only moves the contents up and down by about a pixel or two.
This is occuring in Google Chrome (version 18.0) and Iceweasel 11.
As it turns out, another CSS style was causing the issue:
body{
line-height: 1;
}
Anyone interested in learning about how and why this would cause an issue, can read about the line-height property here
I was having an issue with this, and I found that having position: relative on the child elements was causing the problem. Obviously this can't be the solution for everyone, especially if position: absolute is being used, but for me it worked.
Just to put in evidence the #Kuba Orlik's solution (he posted as comment on the accepted answer) that's the only one that worked for me.
Add this on inside elements:
line-height: normal;
Note: Explicitly normal not 1 because it's different
I have encounter this problem.But I solved this use the following css style:
div.yourcontainer{overflow-y:auto;}
If the container was higher than max-height,the vertical scrollbar will show.
I had this problem when trying to wrap a list (flex column) of react components in a div, I resolved it by changing margin of elements within each list item to be 0.
The approach to troubleshoot this for me was to inspect the list items (perhaps each <li> in OP) and see what styles were making the div think each list item was larger than what was visible to the human eye.
Here is an example of inspecting a rogue margin on an icon within a list item in my project:
Solution is to set the style of that icon to have a vertical margin of 0, though in my application I just made all the margin 0 and added some padding-right.
I also had this problem using Bootstrap and nav. It occurred because bootstrap definds the li in nav-tabs as: .nav-tabs > li { margin-bottom:-1px; }. To counteract this, you must also do:
.nav-tabs > li:last-child {
margin-bottom:0;
}
Without setting the last-child, the following example would always show scroll, no matter how much content is in the list:
<ul class="navs nav-tabs nav-stacked" style="max-height:80px;overflow:auto;">
<li></li>
...
</ul>
I came across this bug earlier today. In my case a list of child elements had display: inline-block instead of display: block. Switching to display: block for my list of child elements in the truncated div fixed the issue for me.
In my case, the problem was with the font. We use font-family: Galano Grotesque. Apparently, this font is rendered higher than the computed height.
<div>
<p>some text</p>
</div>
So even without max-height, when the inner p and the outer div were both computed as 20px height, there was still a scroll bar (with overflow: auto) because the font was about 1px higher than expected.
So the solution can be any one of:
Use a different font.
Add padding to the outer div. This way it will be large enough to cover the extra pixel that comes from the font. In my case, adding one pixel of padding to the bottom and one to the top solved the problem.
Set line-height to a bit larger value (in my case, from 1.25 to 1.4), so it won't interfere with the font.
Set line-height to normal because then the actual value will be influenced by the font. However, according to Mozilla, this is not the preferred way.
The reason for the vertical scroll is obvious: the scrolled content is higher than scrolling area. But when you observe their heights, they are equal!
The causes are multiple but all come down to a common one: an element inside the scrolled content overflows it and makes the result taller.
How to fix this?
find the guilty element by looking near the bottom edge of the scrolled element (or to the right if you're scrolling horizontally), because they are the most likely to overflow. You should observe a height larger that their parent's.
see what makes them overflow, be larger than their container. As other answers suggest, it can be line-height, some margin, etc. Change those properties to make them fit, or as an alternative, set overflow-y: hidden to their immediate parent.
I'm running into a vertical positioning problem with a couple of elements on a page in Firefox 5. When I set a line-height on a piece of text, and give it an equal height, it doesn't center vertically the way it should. Instead it sticks to the top of its line-height.
The page in question is here: http://www.tyndale.ca/~missiodei/
Here are the two problem elements along with their CSS. In both cases the text is pushed up in FF5 but displays properly (vertically centered within its line-height) in Chrome/Chromium.
the large title link in the banner (#blogtitle a)
position:relative;
display:block;
margin:0;
padding:0;
color:#fff;
text-decoration:none;
letter-spacing:.1em;
font-family:"Palatino Linotype", Palatino, serif;
font-weight:bold;
opacity:0.6;
height:120px;
line-height:120px;
any of the drop-caps that float at the beginning of new sections of body text (p.openingPar:first-letter)
font-size:3em;
font-weight:bold;
position:relative;
float:left;
height:48px;
color:#ccc;
line-height:48px;
margin-right:4px;
You might not see these drop caps unless you look at the page using Chrome or Safari, since most of them aren't showing up at all in FF. (I'm not sure why these styles aren't being respected either).
Finally, it would be helpful to know whether this is a problem unique to FF5 or whether 3.6 and 4.0 have the same problem. I don't have any old versions of FF available for quick testing.
Thanks ahead of time for help. I've imprinted my keyboard on my forehead bashing my head over this one!
The vertical centering seems to work fine for me....
The lack of first letter styling is https://bugzilla.mozilla.org/show_bug.cgi?id=8253
Try using <span class"dropcaps">W</span> instead of styling your opening first letter in the paragraph by selector :first-letter. Let us know if it works.
On this page (http://www.bonniesphere.com/blog/elsewhere/) the "li" items have an image instead of a bullet. But the image is centered vertically, and in multi-line entries it doesn't look good. Can anyone tell me if there is something in the CSS that should be changed?
Here's the relative code:
.entry ul {list-style-type:none;}
.entry ul li{padding: 0 0 0 15px;background: url(img/ol.gif) no-repeat left center;margin-left:10px;}
Many thanks for your help...
replace center with top:
background: transparent url(img/ol.gif) no-repeat scroll left top;
.entry ul {list-style-type:none;}
.entry ul li{padding: 0 0 0 15px;
background: url(img/ol.gif) no-repeat left top center;
margin-left:10px;}
Just typed that out of the top of my head, but the "top" attribute might do it.
You could try and replace the left or center with the top tag, can't check for you as my webdeveloper addon is playing tricks on me. :(
I checked locally, it's the center tag. But there's still an extra bit of whitespace needed.
.entry ul li{padding: 0 0 0 15px;background: url(img/ol.gif) no-repeat left 4pt;margin-left:10px;}
Basically you need to specify the offset from the top. You had center which obviously centered the image vertically.
As a rough guess, I used 4pt but it depends on exactly where you want to position the image. With 4pt it roughly aligns it to the first line, but any change in font-size will screw up the positioning.
Personally, using top for the vertical position is a little too high for my likings.
This is very odd... I tried all three suggestions above, and none of them changed anything. A little more info, if it helps: it's a Wordpress blog (on my server) and I'm editing style.css through the theme editor. (That shouldn't make any difference...)
Do you suppose there's something elsewhere in the CSS that's making the image stay aligned at the center, over-riding this code??
Thanks for your suggestions... I had Firebug but had never used it - so with a combination of Firebug and the "compare" feature of BBEdit, I was finally able to figure it out! The template author had supplied a fix for the bullet points, but when I uploaded the most recent version of the theme, the problem occurred again. I found it, and voilà...
Thanks to the two programs, I was also able to find a fix for something else that wasn't working.
I'm a happy camper! At least... until the next time I run into something I can't fix...
:-)