Develop Reference

Potential CSS scroll snap bug in Chrome

Please check this CodePen. The problem is described there. There is also a demo. I've tested it on Mac and Windows.
There is the same behavior in Chrome (on Mac and Windows).
Meanwhile, other browsers (even Safari and Opera which are on WebKit too) do not jump to the nearest snap point instantly.
It is a bug?
If so, what is the correct place where I can report it? Or what is the correct place (WebKit related) where I can ask about it?
// Snippet of code required by Stack Overflow to post a question
slider.addEventListener("scroll", _.debounce((e) => {
const currentHeight = parseFloat(e.target.style["height"]);
e.target.style["height"] = currentHeight + (flag ? 5 : -5) + "px";
flag = !flag;
}, 50));

"Chrome introduced auto-snap after layout changes in M81." (from Scroll snapping after layout changes)
Issue 1181843: Scroll-snap jumps to the nearest snap position on repaint in Chrome
This behavior is intentional in Chrome, unfortunately.

Mac Safari 7 Rendering Issue scrollLeft() issue

I created a dynamic table that scrolls left and right, has resizable columns, has a fixed header, etc. This table works great on EVERY browser I've tried. Even IE8 looks good (missing features, but still good).
This issue arises when I try to view the table in Safari 7.0.4 on my Macbook.
Attached is what is should look like (the fixed header is on the bottom for demonstration purposes):
when you scroll, the fixed header, body, and fixed scrollbar all are connected via some jQuery scrollLeft() functions (scroll one, scroll all):
var tableHeaderSpace = $('.table-full-wrap-space'),
tableHeader = $('.table-full-wrap-header'),
tableBody = $('.table-full-wrap-body'),
tableScroll = $('.table-full-wrap-scroll');
tableScroll.bind('scroll', function() {
tableHeader.scrollLeft(tableScroll.scrollLeft());
tableBody.scrollLeft(tableScroll.scrollLeft());
});
tableHeader.bind('scroll', function() {
tableScroll.scrollLeft(tableHeader.scrollLeft());
tableBody.scrollLeft(tableHeader.scrollLeft());
});
tableBody.bind('scroll', function() {
tableScroll.scrollLeft(tableBody.scrollLeft());
tableHeader.scrollLeft(tableBody.scrollLeft());
});
$(window).bind("scroll", function() {
var tableHeaderOffset = tableHeaderSpace.offset().top;
if (this.pageYOffset >= tableHeaderOffset) {
tableHeader.addClass('isFixed');
} else {
tableHeader.removeClass('isFixed');
}
});
Again, this works great...but as you scroll right a bit more, the browser starts duplicating content within that fixed header:
The issue is is that no 'actual' content is being duplicated - this is some sort of browser fragmenting that is showing duplicates - without adding elements in the DOM.
The next picture is the browser doing some more "magic". at certain points in horizontal scrolling, the whole fixed header's colors gets inverted:
I wasn't able to get a snapshot of it, but it also once duplicated the "record count" bar below it.
Anyone have any ideas what's going on here? I tried to duplicate this in jsFiddle but no dice. From that, I would assume that this is an issue with my code, but the results are only with ONE specific browser on mac (safari), and it is doing some STRANGE stuff.
Last note - since I can't replicate this in jsFiddle, i'm not sure how I could report this to Apple (the working (or 'broken') example is proprietary and I can't give out access to it).
EDIT:
here's the jsfiddle where I tried to duplicate the issue (very rough - but it's functional):
jsFiddle Duplication Attempt

so - I knew this wouldn't be a hot topic question, but I thought I would still give it a go ahead.
as for the answer, I found some old table css that was overlapping my new stuff - which in turn was somehow flipping safari out so bad that it was fragmenting it.
previous old code: background: transparent;
new code: background: #fff;
This doesn't make sense to me - but until someone else comes up with an hypothesis, I'll mark this as the answer.
now my number-one contender for worst browser: safari - look out, IE.

Feature detection for position: fixed

I am trying to find a script that detects if a device places position: fixed elements relative to the ViewPort and not to the entire document.
Currently, standard desktop browsers and Mobile Safari (for iOS 5) do so, whereas Android devices place the fixed elements relative to the entire document.
I have found a couple of tests to detect this, but none of the seem to work:
http://kangax.github.com/cft/ Gives me a false positive when I pass it from an Android device.
https://gist.github.com/1221602 Gives me a false negative when I pass it in an iPhone with iOS 5.
Does anybody know where to find / how to write a test that actually detects that? I don't want to rely on browser sniffing.

According to the contributors at Modernizr, you cannot do this without detecting the browser in use. The contributors are quite well-established in the field.
Testing for position: fixed on iOS and Android devices is listed under the Undetectables wiki page in the Modernizr project.
The MobileHTML5 website lists the support for position:fixed. http://mobilehtml5.org/

Actually, the guys from the Filament Group did a smart thing with their Fixedfixed putting the user agent string of known false positives in their test.
Check it # http://github.com/filamentgroup/fixed-fixed
Someone could complete it with some false negatives too, and make it a modernizr aditional featur test.

I've created another check if position:fixed is really supported in browser. It creates fixed div and try to scroll and check if the position of div changed.
function isPositionFixedSupported(){
var el = jQuery("<div id='fixed_test' style='position:fixed;top:1px;width:1px;height:1px;'></div>");
el.appendTo("body");
var prevScrollTop = jQuery(document).scrollTop();
var expectedResult = 1+prevScrollTop;
var scrollChanged = false;
//simulate scrolling
if (prevScrollTop === 0) {
window.scrollTo(0, 1);
expectedResult = 2;
scrollChanged = true;
}
//check position of div
suppoorted = (el.offset().top === expectedResult);
if (scrollChanged) {
window.scrollTo(0, prevScrollTop);
}
el.remove();
return suppoorted;
}
This function was tested in Firefox 22, Chrome 28, IE 7-10, Android Browser 2.3.

jQuery animate scrolltop on Opera bug

Has anyone tried using
$(“html, body”).animate({scrollTop:0}, 'slow');
on Opera browser?
It does a weird effect especially if you scroll on a long page, it seems like the page go first to the top and then it scroll down to the right point. It is a weird disturbing effect...
Is there any workaround to fix it? thanks

The attribute was not defined properly in the past. It was introduced by IE, I think, then reverse engineered to be implemented by different user agents. It has been since described in CSSOM (still a working draft). As of today, there is still a bug indeed in Opera which is being in the process to be fixed.
## Possible hack.
A solution will be
$(window.opera?'html':'html, body').animate({
scrollTop:0}, 'slow'
);
Be careful because if Opera fixes it at a point, the code is likely to behave strangely.
Why?
In Firefox and IE quirks mode, you have to set the property on the "body" to make the page scroll, while it is ignored if you set it on the "html".
In Firefox and IE standards mode, you have to set the property on the "html" to make the page scroll, while it is ignored if you set it on the "body".
In Safari and Chrome, in either mode, you have to set the property on the "body" to make the page scroll, while it is ignored if you set it on the "html".
Since the page is in standards mode, they have to set it on both the "html" and "body, or it won't work in Safari/Chrome.
Now here's the bad news; in Opera, when you read the scrollTop of the body it is correctly 0, since the body is not scrollable within the document. But Opera will scroll the viewport if you set the scrolling offset on either the "html" or "body". As a result, the animation sets two properties, once for the "html" and once for the "body". The first starts at the right place, while the second starts at 0, causing the flicker and odd scroll position.
Better solution not involving user agent sniffing
From http://w3fools.com/js/script.js
// find out what the hell to scroll ( html or body )
// its like we can already tell - spooky
if ( $docEl.scrollTop() ) {
$scrollable = $docEl;
} else {
var bodyST = $body.scrollTop();
// if scrolling the body doesn't do anything
if ( $body.scrollTop( bodyST + 1 ).scrollTop() == bodyST) {
$scrollable = $docEl;
} else {
// we actually scrolled, so, er, undo it
$body.scrollTop( bodyST - 1 );
}
}

This http://www.zachstronaut.com/posts/2009/01/18/jquery-smooth-scroll-bugs.html#opera might be a better solution without using any Opera specific functions and accounting for quirks mode.

$("body:not(:animated)").animate({ scrollTop: destination}, 500 );
return false;
works for me, in opera as well.
EDIT: does not work in firefox though

I've had this problem, too. This is what I use and it works. It's not browser sniffing, but it's not particularly nice code, to me. It works tho, for now.
Calling scrollTop on html element in Opera 11 / IE 8 / FF 3.6 returns a number larger than zero
Calling scrollTop on html element in Chrome 10 / Flock 3.5 / Safari 5 (for Windows) returns 0
So just test that:
If the browser is Opera, you test for a number larger than 0 on scrollTop, and call scrollTop on only html, a la
var html = document.getElementsByTagName('html')[0];
var body = document.getElementsByTagName('body')[0];
$(html).animate({scrollTop:0+'px'},{'duration':1000,'easing':'swing'});
If the browser is Chrome, or Flock or Safari than scrollTop will return 0 and you test for that, acting accordingly:
$(html,body).animate({scrollTop:0+'px'},{'duration':1000,'easing':'swing'});
So, you'll set the effect on html for standards mode FF and IE (quirks should be covered, too. Ugh), and body for Chrome and Safari.
In Opera, which attempts to scroll both html and body, thus leading to mass freakishness, scrollTop returns a number greater than 0, so you call only html and you don't get the flickery nonsense.
So you can safely use both html and body when necessary, or just html when the browser is Opera.
And don't forget yer preventDefault() or that'll be another weird flicker you'll have to worry about. ;)
Hey, I'm no JS ninja, but I try hard and this works for me, and I don't have time right now to investigate it as much as I'd like, so I thought I'd post this here and help. If I'm wrong I'll hold up my hands and say it. ;) So feedback, please. :D
Tom.

Yep!
I had a problem with action of animate({scrollTop: }) function called in click() function.
The best way is http://www.zachstronaut.com/posts/2009/01/18/jquery-smooth-scroll-bugs.html#opera, which was written here by Divya Manian.
One need to use event.preventDefault() before calling scroll function or animate function to end click event before start scroll event.
Something like this:
$(<clicked_element>).click(function(event){
event.preventDefault();
$('html, body').animate({scrollTop: <value>}, 600);
});
EDIT: It's important to apply scroll method to $('html, body') elements

How do I keep a bar on the bottom of a page in IE 6,7,8 or how do I force IE to redraw the interface?

I need to glue a bar to the bottom of the client view in the web browser. Traditionally I would use position:fixed; except that I need to support my IE 6 clients. I've got a very extensive hack to glue the bar to the bottom of the page and over the content, however when the user scrolls down or right, the bar stays fixed on the page.
To correct this issue I use a javascript event that gets fired using setInterval and when running the function in IE (8)'s debug tools the event fires and changes the position top and position left attributes but the page doesn't redraw the element. The code works but the element is not moving, see below.
Just so you know, the fix has to work in IE quirks mode... it can't work if the other IE versions are trying to use a standard. Believe me, I've tried.
P.S. This is really aggravating because I'm double checking IE9 support as well... get this the element does not move with the scroll bars in IE 6, 7, and 8 but moves in IE 9 and it still displays "IE Quirks Mode." And Microsoft said that this release wouldn't effect anything,...
HTML Structure
<body>
<div id="j_zoom_area" style="zoom:100%;">
The Application area the the zoom is changed (by the bar) for accessibility...
</div>
<div id="j_protectorite">
<div class="j_bar">
<div class="j_plate">Zoom Controls, Help, Search, other misc controls</div>
<div class="j_plate">Copyright info, privacy policy, etc...</div>
</div>
</div>
<script type="text/javascript" language="javascript">
j_doBar();
</script>
</body>
The CSS for the bar is https://kscserver.com/ERP-API/Style/includes.css.
The particular javascript for the bar correction.
//This controls the scrolling of the bar
function j_FixBarSlowly(){
var nTop = 0;
var nLeft = 0;
nTop = (document.body.scrollTop + document.body.clientHeight) - 67;
nLeft = document.body.scrollLeft;
//document.title = document.body.scrollTop + '+' + document.body.clientHeight + '-67' + '=' + nTop + 'px';
document.getElementById("j_protectorite").style.Top = nTop + 'px';
document.getElementById("j_protectorite").style.Left = nLeft + 'px';
document.getElementById("j_protectorite").style.Bottom = '';
document.getElementById("j_protectorite").style.Position = 'absolute';
//Ie6,7,8 hack to force redraw
}
function j_doBar() {
//j_FixBarSlowly();
//if (setInterval != undefined) {
// setTimeout("j_doBar();",5);
//} else {
setInterval("j_FixBarSlowly();",5);
//}
}

I'd suggest using an IE fix hack, such as Dean Edwards' IE7.js.
This script runs when your page loads in IE and fixes some common problems in older versions of IE. The documentation lists the things it deals with, and includes position:fixed;.
Hope that helps.
(Of course, the best solution - for your sanity - is just to give up trying to make IE6 look identical to newer browsers, and just live with a non-sticky footer in IE6. As long as it doesn't affect usability, I don't see a problem with IE6 users having a slightly less perfect page layout. But I know some people don't have the luxury of doing that; if your users are demanding it, they're the ones you have to listen to, not me!)

After further testing the best solution was to use an I Frame for the page content and have a div at the bottom of the page content. Of course a few javascript tweaks for proper sizing and you have a perfect solution.
Just for a visual reference.