So take a look at www.qualificationcheck.com under both Chrome and Firefox. Alt-tab rapidly back and forth between them focusing on that little green 'help & feedback' side tab.
It appears to move position! Whys this?
Its included by a 3rd party Javascript file. I've looked into it to figure out how it calculates its position.
First it sets top: 50% to get it roughly 50% of the way down the viewport.
Then it sets
margin-top: [ "-",Math.round(tab.dimensions.height / 2), "px" ].join("")
ie minus half the height of the tab so it shifts back upwards slightly so the 'middle' of it is actually 50% of the way down the viewport (rather than the 'top').
Using Chrome dev tools and then firebug in Firefox I can see that in Chrome margin-top ends up being -33px while in Firefox it ends up being -87px.
Why the difference?
Its annoying because I want to add my own tab above or below it but I can't determine where to put my own tab if I can't rely on the 3rd-party one to be in the same position all the time!
Sorry guys, neither of the other answers helped.
I resolved this by basically copying the 3rd party js and then tweaking it so I could position it and my new tab together as one.
So basically just a work around rather than an answer to the issue.
Try adding padding-top: ?px and it should be the same for both Firefox and Chrome. Some people on the net are reporting a similar issue with margin-collapse (not a bug, apparently):
http://www.sitepoint.com/forums/showthread.php?829681-CSS-margins-displaying-differently-on-Firefox-Ie-Chrome
Margin Discrepancies between Firefox and Chrome/Safari
Firefox (and Chrome since recently) interpret margin and padding differently. Margin and padding values are added to the div height/width. You can fix this (at least for FF) by adding this to your css (put it at the top):
DIV {
-moz-box-sizing:border-box;
box-sizing:border-box;
}
Related
I am making a simple web page, but on google chrome it looks perfectly fine, just how I want, but when I open the page in IE or Edge the nav-pill tabs are at the top of the screen instead of near the middle like they are in chrome.
Images:
I have the 'top' property of the div that they are in is set to 30%.
I have a lot more code, but I don't want to flood this with it, If you need more info let me know! Thanks in advance!
#bodyArea
{
width: 425px;
position: relative;
top: 30%;
left: 44.3%;
}
After testing the code you showed us i noticed as well that it didn't work in IE. From here i would conclude the percentage from top for position:relative is incompatible with IE (judging from this: https://msdn.microsoft.com/en-us/library/ms531177(v=vs.85).aspx IE takes a percentage of the parent container and it might not know the height of the container of your div). I am afraid i can't be of more help without knowing more of the code around your div.
I suspect this has to do with some bugs in the browser, involving opacity, transitions and translations.
I wasn't able to reproduce the glitch in a code snippet, so I'll have to point you to the live site:
tzork.com
My full source code is here: MightyPork/tzork, including the SCSS and Typescript that's compiled to CSS and JS. If you have time and can reproduce the bug, I'd be most grateful if you tried to find what's wrong. I've never seen anything quite like this before.
When you put mouse over the labels, they get a background and a border on one side, which should be 2px wide. Sometimes though, Chrome shows just one pixel. When I change the width to 1px, sometimes it shows no border at all (only near the corners).
You can clearly see how inconsistent it gets. My browser zoom is at 100%, so that is not the cause.
I'm not sure what's up, but it apparently depends on the current time = angle = position of the labels, and WINDOW SIZE.
I round the position to nearest pixel, so fractional position is not the cause.
I also tried rounding to odd / even pixel, that but didn't help either.
Another issue is that in Firefox, sometimes hovering the labels causes numbers on the clock face to move / change letter spacing. I don't get it, there's no connection at all.
In chrome sometimes there appear weird tiling glitch on the background image (notably when the dev tools panel is open).
Ok, so the solution:
I added this all over the place, and the render glitches have disappeared.
-webkit-transform: translate3d(0,0,0);
I don't get it.
Page scrolling using the keyboard (PgUp/PgDown, Space) sometimes gets difficult if there are elements with fixed positions at the top of the page, e.g. navigation bars: content that was not visible at the bottom of the viewport might be hidden by the fixed elements after scrolling.
How to address this problem? Do browsers calculate, how far they should scroll? I observed different behaviors for different browsers and also for the same browsers on different pages (for example, Firefox leaves about 80px of old content on http://www.sueddeutsche.de/, but far less on http://www.taz.de. Chromium leaves much more content.).
Is this a problem at all, i.e. does anybody beside me use the keyboard to scroll a web page? Do you know any statistics?
To illustrate the problem, I created a Fiddle:
https://jsfiddle.net/x7hj8c4m/
Try to scroll the content using Space on Firefox. The fixed element will cover text that was not yet visible before scrolling. If you add left: 0, it works.
Very interesting observation.
Firstly, pressing space is equivalent to pressing PgDn. And when PgDn is pressed, the page should scroll vertically by roughly "one page's worth of px". As shown by the OP's fiddle, Firefox in particular calculates this value differently, depending on whether it detects a fixed header.
From my own tests on IE, Chrome, Firefox, I deduced that:
Without a position: fixed element, Chrome and IE scroll down by ~87.5% of the document height; Firefox scrolls down by document height - scrollbar height - ~20px.
With a position: fixed; width: 100% element at the top-left of the screen, Firefox intelligently understands that the element perceptually reduces the document height, and so applies: document height - scrollbar height - fixed element height - ~20px. The condition appears to be quite specific: the element must be fixed exactly at the top-left of the document's box model with full width in order for it to work. The other browsers (Chrome, IE) don't perform such compensation, and performs the standard 87.5% scroll.
I don't know if this is relevant, but it might have something to do with support for position: sticky.
Scrolling by keyboard is a pretty basic behaviour that probably doesn't interact too much (if at all) with the DOM, so expecting it to account for fixed elements is probably too much. There seem to be browser-specific predefined increments (I have no idea if or how they can be customized), but note that the increments are usually smaller (presumably small enough) when you use the up/down arrow keys.
I have a simple table with css. When I add a bottom border to the middle row, the next row has a really weird border. it happens only in chrome, and I have no idea why.
I should say the I apply the bottom border to the middle row using javascript (because I don't know the size of the table beforehand). I tried to apply without javascript, and it works without the weird problem.
here is an example of the table, notice the borders in the middle:
http://ri-cloud.appspot.com/super_tacticko?create
here is the javascipt I'm using to create the middle line:
// add the middle line
var half = height / 2; // it has to be zugi anyway
var $middle = $('tr').slice(half-1, half);
$middle.find('td').addClass('middle-td');
If resizing the window fixes the issue (as it does in my case also) it is most likely a rendering bug... Chrome has a number of these that spring up from time to time, mainly because it tries to be faster than everything else by cutting corners (imo).
The only way to work around a bug is to keep trying different approaches until you find one that doesn't trigger the issue, either that or try programatically resizing your table/body after it's been created and then put it back to the right size again — this may force Chrome to redraw correctly... and should occur quickly enough that the users wont notice. A third approach could be to build the table entirely in JavaScript and once properly formed, embed it into the page.
The reason why the CSS method probably works is because it will be using Chrome's rendering methods at a different point in the rendering process to that of the JavaScript style modifications.
Basically, I have seen Chrome do some pretty strange things. The hacks I've used in the past to get around odd Chrome problems have been:
Use decimals in dimension calculations — i.e. 30.1px instead of 30px
Not setting opacity to full — i.e. 0.99 instead of 1.0
Not to use an ip address prefixed with a . when setting a cookie
Use overflow: hidden to repair strange renderings in certain situations.
Oh just for the record I'm viewing on Windows 7 via Chrome v25.0.1364.97
I have run into similar problems in Chrome on Windows 10. The cause of this problem is that Chrome is not working correctly with Windows text-size settings feature (IMHO changing DPI in Win OS). When I have switched from 125% text size to 100% text size, Chrome was rendering my HTML table correctly. As far as I have been testing, other browsers are working with this feature OK.
Finally I made a quick fix to this issue as follows:
table {
tr td {
border-color: transparent !important;
outline: 1px solid #666;
}
}
It is not bullet-proof, the sizes of borders are 2px, but better something than nothing.
I'm attempting to animate the slide-out of a menu with script. To do this, I need to animate the marginTop property of an element and increment it from -30px to 0px.
However, in IE8, the animation simply does nothing. I've traced this down to the fact that setting marginTop in script seems to have no effect. In Chrome and Firefox, this works fine.
Here's an example that will work with Chrome/Firefox, but not IE:
http://jsfiddle.net/rm58T/2/
Is this an IE bug, and if so, are there any workarounds for this behavior? Thanks!
Update:
Here's some screen shots of the bug.
In Chrome, my Fiddle looks like this (You can see the "Name of new menu" text, since we changed the margin with script)
In IE8/Vista, it looks like this. I can confirm in Developer Tools that topMargin is actually 0px as expected, however the elements were not re-drawn:
Another Update:
This bug repros (at least for me) on IE8 running on Windows 7, and also IE8 running on Windows 2008 Server. It does NOT repro for me on IE7 running on WinXP. I do not have any IE9 machines to test it.
Yet Another Update:
I found one potential work-around. If I set p.newmenu to position: absolute; instead of position: relative; then it works. However, in my case I'm hosting this entire thing in a popup menu and need this control to push out the bottom of the modal dialog, so absolutely positioning it is not an option. However, perhaps this knowledge can help in finding a workable solution. An example of this work around can be found here.
Would You Believe Another Update?:
I did find a workaround for now. If I use top: -30px; instead of a negative top margin, then everything works. top behaves a bit differently than a margin, though, and makes the UI not look quite as nice. In particular, when you use top: -30px, then you'll have 30px of whitespace under your element since relative positioning doesn't affect other page flow.
I'd greatly like to figure out why I can't use a negative top margin on IE like I can with other browsers, so I'm still hoping someone can provide an answer that will provide all the benefits of a negative top margin but also work with IE8.
The trigger for this behaviour is how IE8 handles the fieldset element.
You can work around it by setting the display for fieldset to inline (or inline-block).
div.modal.addmenu fieldset {
display: inline;
}
This isn't exactly a bug; it is just based on the fact that (to keep up in performance comparisons) IE was built since version 5.5 with a minimized preset of static definitions;
That means: Instead of spending any Element the whole and correct definition (depending on which god of specifications you hail out for ...) for the type it is, IE is using less.
TODO:
Give back what should be credited for acting as a top-model paragraph relatively positioned; DISPLAY it accordingly to its talents; any super-paragraph should do the catwalk inline, even if it is a block-head, you might try using sugar and whiplashes to remember your nasty P of its origin as a inline-block. It's a frenzy P, give some respect to its talents…
DOJO:
In fact, you as a rune-reading script-javalchemist be the one who has to have to take control over the brew the browser serves. Or it makes boom, silently ...
GODO:
Necessary things to do if you want to use negative-margins in browsers which don't play legally:
remember the elements you want to use of their display's origin; don't believe in browser-vendors that they would have done that already for you
IF you are just out for IE 7+ use display:inline-block;
IF you want to get negative-margins to effect on all notable browsers, but can forget about NS4, then use display:inline; or display:block;
Do not forget to build the foundation for your negative-margins: set position:relative;
MOJO:
If IE-Betas and older ones like 5.5 or 6 are in your point of interest, you have to ensure that your relative-positioned negative-margin paragraph has values for width and height; Depending on what you are trying to achieve, sometimes a height:auto; helps out.