I have an element where I'm using the Twitter Bootstrap Affix plugin. If the window gets vertically resized to the point where it is smaller than the height of the item, I'd like to remove the affix functionality from the element since you wouldn't be able to see all of it in the window.
So far I've tried this in the console just to see if it can be removed, but it doesn't seem to be working.
$("#myElement")
.removeClass("affix affix-top affix-bottom")
.removeData("affix");
$(window)
.off("scroll.affix.data-api, click.affix.data-api");
Maybe I'm going about this the wrong way? How Can I programmatically remove the affix from an element that already had it applied?
I ended up going for a mostly CSS solution, similar to what #Marcin Skórzewski suggested.
This just adds a new class when the height of the window is shorter than the height of the element.
var sizeTimer;
$(window).on("resize", function() {
clearTimeout(sizeTimer);
sizeTimer = setTimeout(function() {
var isWindowTallEnough = $overviewContainer.height() + 20 < $(window).height();
if (isWindowTallEnough) {
$overviewContainer.removeClass("affix-force-top");
} else {
$overviewContainer.addClass("affix-force-top");
}
}, 300);
});
And then in CSS, this class just gets added:
.affix-force-top{
position:absolute !important;
top:auto !important;
bottom:auto !important;
}
EDIT
For bootstrap 3, this seems to be effective:
$(window).off('.affix');
$("#my-element")
.removeClass("affix affix-top affix-bottom")
.removeData("bs.affix");
Deprecated: Answer refers to Twitter Bootstrap v2. Current version is v4.
There are few options to try.
Use function for data-offset-top. Normally, you use the integer value, for number of scrolled pixels to fix the element. According to documentation you can use the JS function, that will calculate the offset dynamically. In this case you can make your function to return different number depending on the conditions of your choice.
Use media query to override affix CSS rule for small window (eg. height 200px or less).
I think, the second variant should be suitable for you. Something like:
#media (max-height: 200px) {
.affix {
position: static;
}
}
If you would provide jsfiddle for your problem others could try to actually solve it, instead of giving just theoretical suggestion, that may or may not work.
PS. Bootstrap's navbar component uses media query for max-width to disable fixed style for small devices. It is good to do that not just because the screen size is to small for navbar, but in mobile devices position: fixed; CSS works really ugly. Take w look at navbar inside the bootstrap-responsive.css file.
Your $(window).off is close, according to #fat (author of bootstrap-affix.js) you can disable the plugin like this:
$(window).off('.affix');
That will disable the affix plugin.
See: https://github.com/twitter/bootstrap/issues/5870
On line 1890 of bootstrap is a conditional for whether the default action should be prevented. This allows your to listen for events and if some condition is met, prevent the affix from happening.
line 1890 from bootstrap:
if (e.isDefaultPrevented()) return
Example:
$('someselector')
.affix()
.on(
'affix.bs.affix affix-top.bs.affix affix-bottom.bs.affix'
, function(evt){
if(/* some condition */){
evt.preventDefault();
}
}
);
Even though this was answered, I just wanted to give my solution for this in case someone ran into a similar situation as mine.
I modified the offset top option to a ridiculous number that would never get scrolled to. This made it so I did not have to do $(window).off('.affix'); and disable affix for everything.
$('#element-id').data('bs.affix').options.offset.top = 1000000000;
Related
My problem is very similar to this one except the thing that fixed element may change his height dynamically during application lifecycle (other data, viewport change, etc... ).
I'm using setInterval() function with 100ms interval to update offset of content element depending on header height.
jQuery(function($){
setInterval(function(){
$('article').css('padding-top', $('header').outerHeight());
}, 100)
});
Here is jsfiddle for it (change the width of the resulted page to see how it works).
For user experience it looks just great, but I'm curious is there a better way?
What are the disadvantages of this approach?
The major disadvantage is that you consume CPU every 100ms. And it doesn't do anything most of the time.
There is a better way. Just emit an event after the fixed element changes height and bind your css adjusment to it. Something like:
$(document).trigger('my_element_changed_height');
wherever the height changes and
$(document).on('my_element_changed_height', function() {
$('article').css('padding-top', $('header').outerHeight());
});
I suppose you can use jquery.ba-resize.js library. Here is a link: http://benalman.com/projects/jquery-resize-plugin
It allows you to use resize event on any DOM element. But if I'm not mistaken this library uses setTimeout functionality and I'm not sure that's better in performance.
UPDATE: time goes and web evolve, position: sticky
header{
position: sticky;
}
Old Answer:
Here is another solution that comes to my head. I was thinking how would be great have such position : fixed-relative :) (That fixed on viewport but doesn't desapear from normal flow) And here is an idea how to emulate this behaviour. Set header element position as relative.
header{
position: relative;
}
And add some listner to scroll event.
jQuery(function($){
$(window).scroll(function(){
$('header').css('top',$(this).scrollTop() );
});
});
It's much pretty than have infinity loop with setInterval or trigger some event across your application.
Unfortunately it will not work on most touch devices
So basically, I am attempting to use jQuery to give my navigation bar (Bootstrap navbar) a 100% width, but in pixels.
Of course, this has to be determined every time the browser/window is resized.
I came up with this, although it is extremely buggy. It uses the starting width of 'nav' as 'navsize', and upon resize of the window, navsize still stays the same.
$(document).on('ready', function () {
$(window).on('resize', function () {
var navsize = $('nav').width();
$('nav').css('width', navsize);
}).trigger('resize');
});
I have also tried var navsize = $('nav').innerWidth(); which was also no good.
The function is definitely being called upon resize since I have tested with console.log()
For all those who are wondering why I am doing this, I am using StickyJS to make my navigation scroll with the page. Although, since it is using 100% width, upon scrolling it becomes much smaller since the nav leaves its container.
This should work
$(document).on('ready', function () {
$(window).on('resize', function () {
$('nav').css('width', 'calc(100% + 1px - 1px)' );
console.log( $('nav').width() );
/// Use following ONLY if you specifically want to set the width in pixel
$('nav').width($('nav').width());
}).trigger('resize');
});
the console.log will have your width in pixel. Means whenever in future you will read the width , it will be in pixel.
calc(100% + 1px - 1px) converts the width and sets in px units, which we can read later on.
Are you sure that $('nav') exists?
I've done some testing using a basic bootstrap page and a slightly change of your code works.
Navigate to this page and open the console inspector.
http://getbootstrap.com/examples/starter-template/
paste the following code and you will see that the .navbar width will be logged on window resize.
$(window).on('resize', function () {
var navsize = $('.navbar').width();
console.log(navsize)
});
Cheers.
It'd be easier with the supporting HTML and CSS, but I will venture a guess based on the behavior alone.
Best Guess
It sounds like one of these options is likely.
you meant to use #nav, .nav, div.nav, etc and don't actually mean to select a "nav" element
your "nav" element is not display inline-block|block, which occurs in some browsers
you are using the "nav" tag in a browser that doesn't support it (IE 8)
your JS library doesn't support the "nav" tag
Alternative
Use JS to relocate your nav into the body (at the appropriate scroll depth) and give your html , body, and nav tags width 100%
Hope that helps.
I have a web application that sizes the html and body elements at 100% width and height and puts overflow: scroll on body to create full screen slide elements. I'm using jQuery Waypoints for sticky navigation and to determine which slide is currently visible.
Since the body element is technically the one scrolling, I set context: body. This works as expected in Firefox, but the waypoints won't fire in Chrome or Safari.
I can get the waypoints to fire by manually calling $.waypoints('refresh'); after scrolling to a point where they should have fired, but calling this after every scroll event seems like a very cumbersome solution.
$('body').on('scroll', function(){$.waypoints('refresh');}) —it works, but sure isn't pretty.
I'm assuming this has something to do with how each browser interprets the DOM, but is there a known reason why Chrome and Safari wouldn't play nicely with waypoints in scrollable elements?
I'm looking for one of two things, either what I've done backwards in my use of waypoints, or what the underlying issue is so I can fix it and make waypoints work properly for everyone.
For the record (and before anyone asks), I've done my research and this isn't an issue with fixed elements.
Edit: finally got a CodePen built for this. Take a look.
Remove overflow:hidden from html. Unfortunately looks like this is required - I hope it doesn't break your layout.
Next, you'll need #nav.stuck { position: fixed; } instead of absolute for a sticky header.
Use this js:
$('#nav').waypoint(function(direction) {
if (direction == 'down') {
$(this).addClass('stuck');
} if (direction == 'up') {
$(this).removeClass('stuck');
};
});
That works for me - see http://codepen.io/anon/pen/GgsdH
How about this?
$(window).load(function() {
$('#myheader').waypoint('sticky');
});
… instead of this:
$(document).ready(function(){
$('#myheader').waypoint('sticky');
});
This is of course stupid if you have a huge amount of images to load, but this solution saved my day.
Try min-height: 100% on body and html instead of height, if appropriate for your layout.
Delete overflows and heights in html and body, also context is not needed. Worked for me.
Not too long ago I asked about setting up a DIV which scrolls with the rest of the page. Post can be found here.
I've set this up, using the following code:
JS..
jQuery(function ($) {
var el = $('#sidebar'),
pos = el.position().top;
alert(pos);
$(window).scroll(function() {
el.toggleClass('fixed', $(this).scrollTop() >= pos);
});
});
CSS..
/* profile sidebar */
#sidebar>div{ width: 300px; margin-top: 10px; }
#sidebar.fixed>div{position:fixed;top:0}
A copy of the page can be found here. The alert was just some debugging.
The problem is, when you scroll a small amount, #sidebar suddenly appears at the very top of the page. In addition, sometimes as you scroll further down, the sidebar appears - and sometimes it doesn't.
Any idea what might be causing such seemingly random functionality?
I'm still trying to figure out why it works in the first place in the jsfiddle example, but anyway, I know how to fix it:
$(window).scroll(function() {
if($(this).scrollTop() >= pos){
el.addClass('fixed');
}else{
el.removeClass('fixed');
}
});
I tested this by unbinding the event you had and replacing it with this code. It seemed to work fine.
The reason I can't understand why it works in the example: toggleClass should be constantly adding and removing "fixed" if you have scrolled enough, because the conditional is true (true here means whether to toggle). The constant adding and removing of the fixed class causes the jumpy behavior.
You can watch this on your page: open up some dev tools (firegubg or Chrome) and watch what happens to your sidebar element.
[UPDATE]
Actually, I misread the docs. True means the class should be added (I don't think the docs are very clear though). Thus... the only way I could explain this is if #dunc was running jQuery v1.2 and the switch was getting ignored completely...
I'm building an auto-follow div that is bound to the $(window).scroll() event. Here is my JavaScript.
var alert_top = 0;
var alert_margin_top = 0;
$(function() {
alert_top = $("#ActionBox").offset().top;
alert_margin_top = parseInt($("#ActionBox").css("margin-top"));
$(window).scroll(function () {
var scroll_top = $(window).scrollTop();
if(scroll_top > alert_top) {
$("#ActionBox").css("margin-top", ((scroll_top-alert_top)+(alert_margin_top*2))+"px");
console.log("Setting margin-top to "+$("#ActionBox").css("margin-top"));
} else {
$("#ActionBox").css("margin-top", alert_margin_top+"px");
};
});
});
This code assumes that there is this CSS rule in place
#ActionBox {
margin-top: 15px;
}
And it takes an element with the id "ActionBox" (in this case a div). The div is positioned in a left aligned menu that runs down the side, so it's starting offset is approximately 200 px). The goal is to start adding to the margin-top value once the user has scrolled past the point where the div might start to disappear off the top of the browser viewport (yes I know setting it to position: fixed would do the same thing, but then it would obscure the content below the ActionBox but still in the menu).
Now the console.log shows that the event is firing every time it should and it's setting the correct value. But in some pages of my web app the div isn't redrawn. This is especially odd because in other pages (in IE) the code works as expected (and it works every time in FF, Opera and WebKit). All pages evaluate (0 errors and 0 warnings according to the W3C validator and the FireFox HTMLTidy Validator), and no JS errors are thrown (according to the IE Developer Toolbar and Firebug). One other part to this mystery, if I unselect the #ActionBox margin-top rule in the HTML Style explorer in the IE Developer Tools then the div jumps immediately back in the newly adjusted place that it should have if the scroll event had triggered a redraw. Also if I force IE8 into Quirks Mode or compatibility mode then the even triggers an update.
One More thing, it works as expected in IE7 and IE 6 (thanks to the wonderful IETester for that)
I'm having a problem with your script in Firefox. When I scroll down, the script continues to add a margin to the page and I never reach the bottom of the page. This occurs because the ActionBox is still part of the page elements. I posted a demo here.
One solution would be to add a position: fixed to the CSS definition, but I see this won't work for you
Another solution would be to position the ActionBox absolutely (to the document body) and adjust the top.
Updated the code to fit with the solution found for others to benefit.
UPDATED:
CSS
#ActionBox {
position: relative;
float: right;
}
Script
var alert_top = 0;
var alert_margin_top = 0;
$(function() {
alert_top = $("#ActionBox").offset().top;
alert_margin_top = parseInt($("#ActionBox").css("margin-top"),10);
$(window).scroll(function () {
var scroll_top = $(window).scrollTop();
if (scroll_top > alert_top) {
$("#ActionBox").css("margin-top", ((scroll_top-alert_top)+(alert_margin_top*2)) + "px");
console.log("Setting margin-top to " + $("#ActionBox").css("margin-top"));
} else {
$("#ActionBox").css("margin-top", alert_margin_top+"px");
};
});
});
Also it is important to add a base (10 in this case) to your parseInt(), e.g.
parseInt($("#ActionBox").css("top"),10);
Try marginTop in place of margin-top, eg:
$("#ActionBox").css("marginTop", foo);
I found the answer!
I want to acknowledge the hard work of everyone in trying to find a better way to solve this problem, unfortunately because of a series of larger constraints I am unable to select them as the "answer" (I am voting them up because you deserve points for contributing).
The specific problem I was facing was a JavaScript onScoll event that was firing but a subsequent CSS update that wasn't causing IE8 (in standards mode) to redraw. Even stranger was the fact that in some pages it was redrawing while in others (with no obvious similarity) it wasn't. The solution in the end was to add the following CSS
#ActionBox {
position: relative;
float: right;
}
Here is an updated pastbin showing this (I added some more style to show how I am implementing this code). The IE "edit code" then "view output" bug fudgey talked about still occurs (but it seems to be a event binding issue unique to pastbin (and similar services)
I don't know why adding "float: right" allows IE8 to complete a redraw on an event that was already firing, but for some reason it does.
The correct format for IE8 is:
$("#ActionBox").css({ 'margin-top': '10px' });
with this work.
try this method
$("your id or class name").css({ 'margin-top': '18px' });