Firefox CSS and/or D3 difference - html

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

Related

Does each browser render css differently?

I designed a page and was testing in chrome. After completing it, when I checked in firefox, I noticed few inconsistencies. For example, one thing that surprised me was the popup I made. I was doing like :
$('#login-pop-up').css('top','3200px');
It showed fine in chrome, but in firefox it showed way below. I do not know what does that mean ? When I set a property of top to 3200px, why it doesn't remain the same in firefox when the testing-machine is same.
Does each browser render css differently ? top for firefox won't be same as chrome or opera?
It depends on the relative elements on your document. CSS is a stylesheet and almost all browsers target basic CSS properties same way. For eg: position:absolute with top and left margin specified (with width of the element and height also specified) should return same results on different browsers.
There are some CSS properties which are inbuilt, that the color of the font should be black, there should be a 1px border on input boxes, bla bla..
Source: ME

Very difficult to solve and strange CSS3 opacity transition issue (...must be a bug?)

I am absolutely tearing all of my hair out with this highly frustrating and strange CSS problem I am having.
I am using the Bones boilerplate to make a website, and it has been great, until now...
It uses fluid grid system and I have recently tried to create a simple gallery which I have made into a grid (4 images, each one wrapped in a quarter column, with first/last classes added to the first/last images).
If you hover over the images (especially noticeable on the first three for some reason), you will notice that they change width by a pixel or two for some crazy reason. The images are set to max-width:100%, and I have a feeling this is somehow the culprit, because if you give the images a "fixed" width (example .gallery-icon img {max-width:165px;}, it fixes the issue, but being a fluid grid system, I can't go down that route, as the images stay 165px if resizing the browser, and even if I set 4 different widths depending on media, in between media sizes, the images wouldn't align properly.
If it wasn't for the transition effect problem (if i turn the transition off, the images lower opacity fine, but no animation), it would work as I want it to work :(
Please help guys!
Here is a empty demo site that has the bones boilerplate running and nothing more than the gallery on the page. Let me know if you see the shaking issue.
(I couldn't recreate it on jsfiddle, so I installed it on an old domain I had lying around hehe)
EDIT: I have just noticed that the problem seems to happen to images that are bigger than the div in both width and height. Images 1 + 3 are this and they have the bug, whereas images 2,4 seem to be okay? and images 2+4 have a smaller height than the div..... But even if I set the images a max-height, the problem continues..
EDIT2: Added a quick video to show the problem (latest Firefox and Chrome) http://www.youtube.com/watch?v=uL81hLfMvvw
Thanks to vals for pointing out the GPU aspect... This reminded me of this CSS-Snippet which tends to solve Chrome rendering issues:
-webkit-transform: translateZ(0);
I've applied this to the container (div.post) containing the problematic item (i.icon-) which has a fraction width, problem solved!
Credit: I've got this solution from this answer to fix incorrectly rendered (fixed) elements after navigating to an page anchor.
I would say that it is really a bug in Chrome (I am using 24.0.1312.57 m).
The issue is not really on images 1 + 3, I have seen it on image number 2.
I think that the issue arises when you have the width of the image being a fraction (say 146.71 px). In stationary display, this gets rounded to 146 px. In the transition this gets rounded upwards (more correctly !) to 147 px.
use the following css hint to promote the affected element to a new composite layer (It solved the same exact issue to me):
.<your-css-selector> {
will-change: <css style about to change. example: opacity>;}
This indicate the compositor to isolate the paint process of the element into a new composite layer. When inspecting layers in chrome dev tools you can make sure the element has been promoted, and thence the issue solved. The element will appear in a new layer with the following 'Compositing reasons: has an active accelerated animation or transition. Has a will-change compositing hint.'
Looks like after promoting the element to a new layer this way, the browser is able to render the final state of the transition correctly.
Ivan.
On thins link you can find solution for Mozilla bug.
You need to add 1 CSS rule:
-moz-backface-visibility: hidden;
I suggest using jQuery to handle your opacity rather than using the CSS3 attributes because you are correct in that your max-width is messing, unhappily, with your transitions.
$(".gallery-icon img").hover(function(){
$(this).fadeTo(fast, 0.7);
}, function(){
$(this).fadeTo(fast, 1.0);
});
Using jQuery will fix a lot of these little glitches with transitions and make sure your opacity change is done cross-browser-compatibly (yes, I know that there are lots of tags for transitions for browsers, but there aren't attributes for all browsers.) :) Hope that helps!

Absolute positioning varies by 1px

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/

Horizontal CSS Nav Padding differences in Firefox,IE9 vs Chrome, Opera

I have a weird problem on a CSS menu. There's a difference in padding applied by both
Firefox & IE9 vs Chrome & Opera browsers. The space left after the last menu item at the end of the menu is different on both the browsers.
Please see the chrome.jpg and firefox.jpg inside zip file to see what I mean.
I have also attached the source html file.
here is the zip file -
https://www.sugarsync.com/pf/D6612639_7394829_952554
Chrome:
Firefox:
This is not padding but likely a difference in how the fonts are rendered in different browsers. Yeah that is pretty much impossible to solve unless you make the menu items fixed width. :)
The firefox version looks bolder (see it?!)... These are brainbreaking problems not fun to deal with but quite easy to explain.
IE9/Firefox use a different technique to render text than Chrome/Opera do.
IE9/Firefox use DirectWrite, and so the text comes out ever so slightly wider, adding up to a few pixels difference over all the menu items.
Read more here: http://www.basschouten.com/blog1.php/font-rendering-gdi-versus-directwrite
And read this, particularly the "Hinting and spacing differences" section: http://blog.mozilla.com/nattokirai/2011/08/11/directwrite-text-rendering-in-firefox-6/
Short of setting a fixed width on each menu item (don't), you can't fix it. However, you don't need to fix it: a few pixels difference between browsers does not matter. Remember, the users of your site are only looking at it using one browser.

css border radius bug in chrome with percentages

Hi I'm having troubles with a problem in chrome. I think it might be a bug but I can't find much info on it. Basically I want to apply border radius on an image. The border-radius will be 50% forming a circle. The reason I've set it as a % is because i wont explicity know the width/hieghtt of the image.
Any ideas why chrome doesn't display the border correclty? I haven't tested in FF < 4. but FF4 works well as does IE for a change
What are you trying to do? Do you want a circle to appear behind the image? That is what I see in FF. In Chrome, the circle is clipping the edges of the image.
According to the spec -- http://www.w3.org/TR/css3-background/#corner-clipping -- content is supposed to be truncated.
The content of replaced elements is
always trimmed to the content edge
curve.
Which, to me, means that Chrome is following the spec correctly on this.
Webkit doesn't currently clip corners of images. Remove the src tag from the image and you'll see that the border is being rounded correctly.
One workaround is you could set the background-image property in css: http://jsfiddle.net/tEzwJ/
I figured out a way around it, by adding the border and the border-radius onto the parent . I then applied the border radius to the image too. Although there is a minute gap It works in chrome now. I haven't tested it in FF3.6. But FF4 displays the same result