Here's a question for you CSS experts out there. The circle dragon and leaves in the upper corners of http://www.thedragonheart.com/ load in all modern browsers except Safari (I'm running 7.0.5) on the latest OS X or iOS. What's the dealio?
If I set div.overbg's z-index to 0 (instead of -1), the leaves and dragon appear, but then the dragon overlays the title in the header, and it prevents body text from being selected. I've tried upping the z-index on #wrapper, header, header a, and header a img, all to no avail. How can I make div.overbg appear over the background image while under the header and body text?
Thanks!
You could solve this in Safari 7 by setting the z-index to what it normally is, then giving the style block the additional rule of pointer-events:none which would still allow the underlying text/elements to be selected as normal.
Provided there are no click elements on that circle or dragon, everything would behave exactly like you're expecting it to.
Of course, this would blow away support for browsers that don't have a full implementation of CSS 3, but it's the world we live in these days. You could always fall back to the negative z-index implementation for that scenario.
Edit: Without going into too much detail on your CSS, the likely culprit of your second failed scenario (the z-index on the header not appearing above those elements with a z-index) is likely due to the header not being given a positioning value other than static. You could probably fix this by giving it some stacking context by setting the CSS rule position:relative; on the element and then giving it a z-index greater than the stylistic elements.
e.g. .dragon{z-index:1;position:absolute;} .circle{z-index:1;position:absolute;} .header{z-index:2;position:relative;}
Related
I have two similar styles. When I viewed them in the chrome inspector they have different values although the styles applied are similar.
The margins of the elements have the 'auto' value but when computed by the browser there is a big difference between them although the width is the same.
For those who will be asking me to point it to a single stylesheet, I actually can't because the first style is for a wordpress theme and the other one is for a whmcs template.
Update:
added these two screenshots. both windows are maximized
auto is not a specific value, and on a block element basically means to let the browser decide. (As in, take up remaining space). I expect your browser window width, or a parent element is wider in the case where you see the larger margin being rendered. (See the "styles" tab instead of the "computed" to see the applied styles)
When you set auto for both left and right margin, it will center the element. If you set auto only for left margin, the element will align to the right side.
Read more at https://developer.mozilla.org/en-US/docs/Web/CSS/margin#Values
I figured out the problem. Chrome renders it differently. Other browsers display it correctly. Only the Chrome browser in my PC displays it differently. The Chrome browser in my mobile displays it correctly so I guess it is a browser issue.
My website http://www.rattletree.com/ works fine in other browsers, and used to work correctly in Safari, but I just noticed that the navigation elements are shifted up now. Can anyone recommend what needs to change in the css? Thanks!
I usually use firefox with firebug, but I'm not able to figure out how to use the dev tools in Safari to test css changes, so I'm chasing my tail here...
It seems that safari experiences problems whenever there is a negative margin greater than the size of the element in the relevant dimension ( height or width ).
The contents of .abovenavcontainer are all floated, with no clearfix, or float clear applied, so it has a height of zero, so the negative margin size ( 69 ) is greater than 0. Try adding a clearfix, or laying out the child elements without float, like, say, display: inline-block;
I have a ul with lis inside that I'm using as a tab list. The lis have an image and some text inside of them. For some reason, in chrome, the text doesn't appear on the same line as the image, but wraps to the next line.
I can't understand why this would happen, shouldn't the li expand to give enough space to fit both the image and the text? This problem doesn't happen on Firefox or IE. Testing with Chrome 22, Firefox 16 and IE 9 on Windows 7.
See this fiddle to see the markup (extracted from a longer page - also not the real icons).
It sounds similar to this problem, but the nowrap trick didn't work for me.
Update: I just realized I had a different zoom level set, 144%. At some zoom levels the issue happens, and others it does not. I guess it might have something to do with the ems for some sizes, and px for others? I still don't get why this would happen though, shouldn't it still get the proper amount of room?
Set a minimum width on the header. You also have the issue if you reduce the browser size. Figure out how small it can go before it starts to stack and set the min-width on the header to that size, that fixes it if the browser is zoomed too.
I'm using css gradients and padding to simulate buttons around an anchor tag. The problem I am running into is that firefox seems to make the button 3 pixels larger. 1 pixel on top and 2 on bottom. This seems to happen with not only the example i posted but everywhere on the page where i use the padding. I put up and example at http://wemw.net/example.php. In firefox the button top and bottom line up perfectly with the search box, but in chrome as i said its off by 1 pixel on top and 2 on bottom. I am using the w3 transitional(tried strict as well) doctype and a css reset. In the reset all anchor tags are set to padding: 0, so I'm confused as to why this extra padding is being added. Is there a workaround to this or is it just something you have to deal with when working with gecko and webkit browsers?
EDIT: So I logged over to windows and it is appearing the same in both browsers now. I'm assuming it is OS specific problems? Since no where near as many people use linux I'm going to change the padding to make it work, but in the interest of consistency can anyone offer a solution for cross-os cross-browser solutions? I do not own a mac and cannot easily test it there, but if windows/linux can have problems with the same versions of the same browsers is it safe to assume mac could also have issues i am unaware of?
It's not the padding on the anchor tag, it's the size of the text box that is inconsistent. <input> elements always caused such problems for me too, and I always found it extremely tedious to align them together nicely (you haven't yet seen it in IE8, have you?). I think that the easiest cross-browser solution here would be to remove the border from the text box and use a background image instead (or better yet, a background image on the element containing the text box) properly aligned with the button.
I am using http://tympanus.net/jPaginate/ to implement pagination. Under Chrome 11, Demo 5 looks normal but under IE9 or Firefox 4, the last page number is shown and gets moved to a new line.
I think the div has overflow:hidden set so that the hidden page numbers are not supposed to be shown, unless ">>" or "<<" is mouseover. This used to work properly in IE8 and Firefox 3.
How can I implement a workaround for IE9 and Firefox 4?
Set a fixed height to the div, otherwise it will stretch to accomodate all the content.
[EDIT]
Ah, it does not solve your issue, plus, seeing that the paginator is generated entirely by the plugin, I believe it's the plugin that is messing something up. It might also be that jQuery's width() function refuses to cooperate with FF4 and IE9. I happen to have a problem with width() resizing list elements in a nav menu on one of my sites, and it also happens with FF4 and IE9 only. Odd... You could try increasing the width of the <ul> containing the pagination elements with jQuery after generating the paginator, but that's a provisional solution.
The page that you were referring to has the problem no longer.
I assume the element had display:inline-block property set -- that was the problem I had with my case.
To solve this case, you need to set vertial-align property.
From the spec:
The baseline of an 'inline-block' is the baseline of its last line box
in the normal flow, unless it has either no in-flow line boxes or if
its 'overflow' property has a computed value other than 'visible', in
which case the baseline is the bottom margin edge.
Giving the ul.jPag-pages li element a fixed width solved my problem under ie9 and ie10