I have a single background for my site fixed to the top center. I have some blank s that, on mouseover, should toggle the display of an absolutely positioned with a different background that should line up against the original background.
The functionality all works fine; however, the with the background doesn't always line up. It varies depending on the size of the screen by 1px.
This is happening in Chrome, but not Dreamweaver. I haven't tested other browsers.
Any ideas?
The problem was in fact a subpixel rendering issue. I just changed the element's css from "left: 0px;" to "left: -0.5px;" and everything works fine.
Thanks to Mike Robinson for his comment and link: http://css3wizardry.com/2010/10/05/subpixel-rendering-2/
Dreamweaver's Live view is a joke, don't trust it for anything other than a rough preview, particularly single pixel differences. Test in the major browsers and use a CSS reset or normalize.css before applying your own styling if things like single pixel differences are an issue for you.
CSS Reset - Resets all styling to 0 so all browsers will start with the same baseline styles. The downside is you have to style every element you intend to use, things like lists will no longer have default styling and appear as plain text. http://meyerweb.com/eric/tools/css/reset/
Normalize.css - This is a little more user friendly than a reset, it gives all the base elements the same styling so that all the major browser defaults are covered and rendered the same. http://necolas.github.com/normalize.css/
Related
So I've got a page on a site that displays exactly like it should in both IE and Chrome, but not Firefox. The link is http://www.jakerevans.com/?page_id=61. In both IE and Chrome, the spinning animation (written with D3.js) displays fully through the padding-left and padding-top, but not in Firefox. Anyone have any idea how I can make this padding in Firefox transparent? Any other possible solutions? I'd really like to resolve this through CSS if possible, and not go back to the drawing board with the D3 code. Obviously I will if I have to though.
Thanks a lot for the help!!!
You need to explicitly set overflow: visible on your <svg> element.
The SVG specifications state that all SVG elements that create viewports should have overflow: hidden in the browser's default stylesheet. However, browsers disagree over whether this should include the padding area or not: if you follow the description in the SVG specs, as Firefox does, padding would not be included. However, general CSS/HTML layout does not consider content in the padding to be overflow, so Webkit/Blink/IE browsers do not clip it with overflow:hidden.
it doesn't seem to be the issue of the padding, it's like to be the firefox transform origin thing, see this Setting transform-origin on SVG group not working in FireFox
Have hit a problem I've never encounted before.
I have a element, its a panel that is fixed to the right side of the screen, and the css for the positioning is:
.myPanel{
position:absolute;
left:0;
}
This works fine, the mark up for the panel is generated by vaadin.
Now everything works fine, however every now and then when I refresh the page the css position:absolute
is being ignored.
Naturally I open my devtools and see that according to the styles tab position:absolute IS being applied, it just doesnt look like it.
Now the odd bit
When I uncheck the tick box to remove the position:absolute styling nothing changes (as I'd expect) but when I re-check it, and the position:absolute is reapplied, the panel then shows correctly.
So even though there is no new css, removing then re-adding position:absolute fixes it.
I've always been under the impression that dynamically added elements will still take css styles that have been loaded pior. Is that incorrect?
I have ONLY had this in chrome, currently version 39
Any ideas?
UPDATE:
if at some point the css was being overridden I'd expect dev tools to flag that (style with a strikethrough etc) but its not. I have tried adding !important to it but get the exact same result (see is applied in devtool, disable and reenable fixes it).
I've noticed in the dom that vaadin is loading my custom javascript in the head, then the css, then its own inbuilt javascript.
This seems to be working according to the spec. If width and height
for a replaced element (which input is one) is auto, it's supposed to
use the elements intrinsic width and height, which might cause
absolute positioning to be overconstrained.
One fix is to wrap your inputs in a div, absolutely position that, and
use width/height 100% on the inputs. Note that Firefox also has this
behavior, and it is indeed in the spec, so it's better to fix the
website than to change Chromium.
~#9 chromo...#gmail.com
As per you saying:
I've noticed in the dom that vaadin is loading my custom javascript in
the head, then the css, then its own inbuilt javascript.
I would say this would be the case for all browsers. For more info, see a previous answer of mine in relation to this
Its a known bug which looks te be solved and the appears again, see also https://code.google.com/p/chromium/issues/detail?id=313221
I've been looking at this small issue for a while and I can't seem to fix it. It's an firefox only bug it's fine in IE Chrome etc.
This website I made for a client shows the issue. On the start of the page you see 2 wheel PNG images Three of these images are there, you can switch the z-index by clicking the round circles on the bottom of the image.
As you see the Black colour is slightly more down, I can't seem to wrap my head around the issue since the line height is 0 and the way the black image is positioned is the same as the grey one. They are slightly downsized due to a max-size: 100%, but resizing them to the proper (1000px) doens't seem to help either, (did this locally).
If you open the pictures in photoshop or w/e they're exactly aligned.
Anyone have any idea why it goes wrong on Firefox only?
--> example
Removed the example since it's a website.
Very weird issue indeed. The only thing way I could get it to go away was to absolutely position the wheels. this would require you to set a height on #infographic and take off the margin-top:-100%;. Depending on how you use the #infographic container this solution might not be ideal for you, but at least something to consider to help solve your issue.
It's because of the whitespace between the elements. Unfortunately, some browsers observe it and thus some space is shown although it shouldn't. You can use this workaround:
Generally work with rem instead of em, you need it for this workaround to work easier. First you have to set the font-size of .infographic to zero. Every element inside your .infographic will now become a font-size of zero because you're using em. That's the reason why you should now change to rem, at least for the elements inside .infographic.
Now you're done.
I have an extremely strange problem in IE that I can't seem to track down. I have two boxes, both floated left, with a margin-left on the right box to give some spacing between the two. In Firefox (of course), it all displays correctly, but in IE when the page is first loaded, the boxes have no separation (no margin).
Here's the crazy part. If ANY CSS changes on the page at all, the box magically jumps to the correct position. And when I say any, I mean any. I modified the final font name of 3 in the font-family list of the body tag, and the box shifted to the correct position (this wasn't a change that would even modify the look of anything on the page).
I could post my HTML and CSS on the page, but it's fairly routine. I just wondered if anyone had come across or heard of this problem in the past? Incidentally, IE8 seems to render it fine.
Thanks.
Follow-Up:
So I was able to at least patch the problem by floating the box on the right to the right, and removing its margin-left property. Because my container div is just wide enough to accommodate the two boxes, this works for my situation, but it wouldn't be nearly as nice if the two boxes weren't contained so tightly in their container div.
Older versions of IE can be pretty buggy about how they handle floats. Try defining a width on your floated elements. This will help make the layout more explicit (so harder for IE to misunderstand) and trigger hasLayout if you haven't already (a weird internal IE property that causes a lot of layout bugs).
I'm having a problem aligning an image to the top the text in an <h2> element because the space between the top of the text and the top of the elements box is different across browsers (so far it's been different between IE7, Safari 4, and FF3 - haven't tested anything else). Particularly noticeable because I'm using a large font (48px). Is there any way to reset this so they're all the same? It isn't margin/padding.
This seems like it'd be an easy fix if I just take the text out of the header element and put it in a div, but it is in fact a header element and I'd like to still use it if at all possible.
No, that's not possible.
You can specify the margin, padding and line-height to get them as close as possible, but beyond that there is nothing you can do. Text will always be rendered differently in different browsers and on different systems.
How text is rendered depends on a lot of factors besides just how the browser positions it, like the fonts installed on the system, the font size the user selected and font smoothing settings. You can never expect text to be rendered at the same pixel position on all systems.
Have a look into reset stylesheets, which are designed to reduce inconsistencies across different browsers thus saving a lot of work in the long term. Also see:
Reset Reloaded
YUI Reset CSS
Blueprint CSS
A reset stylesheet would be the obvious first step (see, for example, Eric Meyer's 'Reset Reloaded': http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/ ).
This essentially overrides browser rendering defaults back to 0, so all margins and padding is at 0px, all fonts are at 1em, line-heights at 1em etc.
If you want to omit the use of a reset-stylesheet, you can just use the following:
h1,h2 /* etc... */
{padding: 0;
margin: 0;
}