Ahoy!
I've built a little script to check the size of the left-hand margin on page load, resize a div there to fill it, and change the header div to float next to it.
Here's the code:
function buildHeader() {
var containerMarginLeft = $(".container_16:not(:first)").css("margin-left");
var headerHeight = $("#header").height();
$("#stripe").width(containerMarginLeft).height(headerHeight).css("float", "left");
$(".container_16:first").css("float", "left");
$("#header").css("margin-left", 0).width(950);
}
$(document).ready(function(){
// Manipulate layout for the first time
buildHeader();
// Manipulate layout when window is resized
var resizeTimer = null;
$(window).bind('resize', function() {
if (resizeTimer) clearTimeout(resizeTimer);
resizeTimer = setTimeout(buildHeader, 100);
});
});
And the demonstration is here: http://robertmay.me.uk/mockups/plane.html (it creates the line that stretches on the left).
Now, it works in webkit browsers. It doesn't work in Mozilla, and I've not even tried it in IE.
Anyone have any ideas as to why it doesn't seem to work in Mozilla? I have a feeling it might have something to do with the CSS.
$(".container_16:not(:first)").css("margin-left");
This line gives a result of '0px' in Firefox regardless of how wide the window gets. However, Firebug Lite in Safari shows this value as changing depending on the width of the window.
The problem seems to be with the .css('margin-left') part of the statement, since $(".container_16:not(:first)") returns the same element in both browsers. Indeed, Firebug in Firefox shows the Computed Style for this element as having '0px' for marginLeft and marginRight, but this is non-zero in Safari.
As expected, changing from 'margin-left' to 'marginLeft' makes no difference, nor does accessing the attribute directly, like $(".container_16:not(:first)")[0].style.marginLeft, because Firefox is computing it wrong in the first place.
Sorry I don't have an answer, but hopefully this will lead you in the right direction. For me though I would try to align the layout using just CSS, resorting to JavaScript fixes only as a last resort.
Related
I'm using SlickGrid.js library and it is excellent!
Only major problem right now is with Internet Explorer (confirmed in 9, 10, and 11), but the standards compliant browsers like Chrome and FF work fine.
Problem: When grid is scrolled and then hidden and then re-shown in IE the scroll position is reset to top of grid, and the viewport/data is either cut off or completely hidden (depending on scroll amount).
Here is a fiddle that demonstrates the SlickGrid.js IE bug (using the author's simple example 1):
http://jsfiddle.net/crwxoc17/1/
Anybody have a generic fix for this or patch to slick grid?
I can call grid.resizeCanvas() to sorta fix the issue, but it resets scrollbar to top and it's very annoying to do this for every single grid just to deal with Internet Explorer.
Semi-working fix, but still screws up the scrolltop:
function onShowGrid1() { grid.resizeCanvas(); }
(Reviewing JS code now, but I have not yet confirmed whether the bug is Microsoft's or SlickGrid's)
This issue applies to any element in IE with overflow set to scroll or auto and whose visibility is toggled. There's a simple example here: https://jsfiddle.net/qkhxL6r8/4/
That said, if you'd like the scrollTop position to be preserved you could extend SlickGrid or create a wrapper a class that subscribes to the onScroll event, records the scrollTop value, and sets it on the viewport element when showing or hiding the grid. I modified your example code as a proof of concept here: http://jsfiddle.net/h9cu2cmp/4/
var lastScrollTop;
var scrollTimeout;
function updateScrollTop(e, args){
clearTimeout(scrollTimeout);
scrollTimeout = setTimeout(function(){
lastScrollTop = args.scrollTop;
}, 30);
}
//...
grid.onScroll.subscribe(updateScrollTop);
$('body').on('click', '.toggle-button', function(){
$("#myGrid").toggle();
if(lastScrollTop !== undefined){
$("#myGrid").find('.slick-viewport').get(0).scrollTop = lastScrollTop;
}
});
If you're using a remote data provider you can trigger ensureData for the updated scrollTop with grid.onViewportChanged.notify()
Situation:
Suppose we are reading the content somewhere down the page that is built to be responsive. Suppose also that we resize the browser window to a smaller size and that some content above get extended down due to the thinner width, hence making the whole page longer. Then as we resize, whatever content we are looking at will get pushed down the page accordingly.
Example:
Suppose we were to look at the Helper classes section in this page. Then shrinking/expanding the window a sufficient amount moves the bit we were reading down/up the current view.
Prompt:
Is there any way we can fix this? I.e. maintain our current view of the page regardless of what happens to the contents above it when we resize the window.
Thoughts:
I am thinking that we could at least start with javascript and put an event on window resize. Then automatically scroll the page to the top-most element that was in our view on event fire. I don't know how this will affect the performance, however, especially in bigger pages.
There's also the problem of refering to the top-most element in current view. The top of our current view might be cutting off the top portion of some elements, not to mention that there's usually more than 1 element layered on top of one another at any point within the page. The notion of top-most element I've mentioned is not very well-defined :(
Also rather than a problem of responsive design in general, instead it seems to me like this is a problem with the default scrolling behaviour of web browsers? Or perhaps I am missing some circumstances where the current behaviour is desirable.
Edit 2 4
Updated fiddle (see fullscreen result) based on Rick Hitchcock's solution's solution.
With jQuery:
//onresize:
var scrollAmount;
if (topNode.getBoundingClientRect().top >= 0) {
scrollAmount = $(topNode).offset().top - topNode.getBoundingClientRect().top;
} else {
scrollAmount = $(topNode.offset().bottom - topNode.getBoundingClientRect().bottom;
}
$(window).scrollTop(scrollAmount);
The fiddle is acting a bit weird even in the same browsers, I've uploaded the same script using a free hosting here.
Still need to incorporate the IE, Opera and Safari fix for elementFromPoint.
Edit 3
Thanks for all the help, Rick Hitchcock. Welcome to stackoverflow, by the way :)
The discussion is turning into cross-browser compatibility issues so I've accepted your answer since we've pretty much got the answer to the original question. I'll still be fixing up my implementation though. The focus being cross-browser issues, topNode criteria, and topNode cut-off handling.
An edge case
While playing around with it, I noticed that when we were at the bottom of the page in a small viewport, then switch to a larger viewport (let us assume now that some more elements that were originally above the element we saw now came into view due to shorter container from wider viewport) the window cannot always lock the topNode to the top of the viewport in such a case since we've reached the scroll bottom. But then switching back to the small viewport now uses a new topNode that got into the viewport during the switch.
Although this should be expected from the behaviour being implemented, it is still a weird side-effect on scroll bottom.
I will also be looking into this in due course. Initially, I am thinking of simply adding a check for scroll bottom before we update topNode. I.e. to keep the old topNode when we've reached scroll bottom until we've scrolled up again. Not sure how this will turn out yet. I'll make sure to see how Opera handle this as well.
Here's what I've come up with:
(function(){
var topNode;
window.onscroll=function() {
var timer;
(function(){
clearTimeout(timer);
timer= setTimeout(
function() {
var testNode;
topNode= null;
for(var x = 0 ; x < document.body.offsetWidth ; x++) {
testNode= document.elementFromPoint(x,2);
if(!topNode || testNode.offsetTop>topNode.offsetTop) {
topNode = testNode;
}
}
},
100
)
}
)();
}
window.onresize=function() {
var timer;
(function(){
clearTimeout(timer);
if(topNode) {
timer= setTimeout(function(){topNode.scrollIntoView(true)},10);
}
}
)();
}
}
)();
If there were a window.onbeforeresize() function, this would be more straightforward.
Note that this doesn't take into account the scrolled position of the element's textNode. We could handle that if only the height of the window were resized. But resizing the width would generally cause reformatting.
This works in Chrome, Firefox, IE, and Safari.
Edit
How it works
The code's closures make variables private, and the timers prevent the code from running constantly during scrolling/resizing. But both tend to obfuscate the code, so here's another version, which may aid in understanding. Note that the onscroll timer is required in IE, because elementFromPoint returns null when it used in onscroll event.
var topNode;
window.onscroll=function() {
setTimeout(
function() {
var testNode;
topNode= null;
for(var x = 0 ; x < document.body.offsetWidth ; x++) {
testNode= document.elementFromPoint(x,2);
if(!topNode || testNode.offsetTop>topNode.offsetTop) {
topNode = testNode;
}
}
},
100
)
}
window.onresize=function() {
if(topNode) {
topNode.scrollIntoView(true)
}
}
topNode maintains the screen's top-most element as the window scrolls.
The function scans the screen left to right, along the 3rd row: document.elementFromPoint(x,2)*
It doesn't scan along the 1st row, because when IE does scrollIntoView, it pushes the element down a couple pixels, making the top-most screen element the previous element. (Figured this out through trial and error.)
When the window is resized, it simply positions topNode at the top of the screen.
[*Originally, onscroll scanned left to right along the 11th row (in pixels) until it found an element with just one child. The child would often be a textNode, but that wouldn't always be the case. Example:
<div><ul><li>...<li>...<li>...</ul></div>
The div has only one child – the ul. If the window were scrolled to the 50th li, scanning left to right would incorrectly return the div due to the inherent padding of lis.
The original code has been updated.
]
I have been writing a small script that shortens documents that are being output on a JSON feed of mine.
I realised that with longer messages, on minimising it could skip a few and you'd have to scroll back to find where you were and so added a scroll function to take you back to the top of the message on minifying. This turned out to be quite annoying when it fired every single time - so I thought, why not make it fire only when the top of the element is above the screen?
And this is where I am stuck --> $(window).scrollTop(); simply doesn't want to output the screen height for me, it's infuriating. I tried with different browsers and the only one .scrollTop() worked for correctly was Internet Explorer.
Here is the function below:
function jexpand(id){
var elm=$('#d'+jdesc[id].i); // element
var ofs=elm.offset().top; // element height - works fine
var top=$(window).scrollTop(); // Y U NO WORK?!!!
if(jdesc[id].e==true){ // boolean to check whether to expand or contract
jdesc[id].e=false; // change boolean flag
if(ofs < top) $('html').animate({scrollTop:($('#'+jdesc[id].i).offset().top)-(20)+'px'},'slow'); // animate to top minus 20 pixels
elm.html(jdesc[id].d.substring(0,347)+'...<br><div class="readmore"><span id="'+id+'">Show More</span></div>');
}else{
jdesc[id].e=true;
elm.html(jdesc[id].d+'<br><div class="readmore"><span id="'+id+'">Show Less</span></div>');
}
$('.readmore span').click(function(){jexpand(this.id)}); // reset click trigger
//alert(top+' <-> '+ofs);
}
When I uncomment the alert() at the bottom in a browser other than IE (I tried chrome, mozilla, chrome android, boat browser android) I get a message akin to:
[object Window] <-> 1077.5625
[object Window] is obviously not a number that can be greater or less than the element height! So what does this mean, is there another flag I need to ask of it? At first I assumed it might be the wrong element I was refering so tried top=$('body').scrollTop();, html, etc, I even tried using div wrapper elements but to no avail.
I am using jquery 1.11.0 and with 1.9.1 I had the same issue.
Am I trying to return the screen top in the wrong way or have all my browsers gone loopy?
EDIT:
Weirdly I've found an issue which may explain things a little, when I typed $(document).scrollTop() into a console it gave me the correct screen height however if I make a var top; outside of the function I get this error 'window.webkitStorageInfo' is deprecated. Please use 'navigator.webkitTemporaryStorage' or 'navigator.webkitPersistentStorage' instead..
I am using a webkit borrowed from html5up and this is somehow interfering with the code. Now to find out what it is....
Sorry for the confusion, without this script everything works fine grr...
Try this way
JS CODE:
$(window).scrollTop(0); // this will scroll to top of the page
LIVE DEMO:
http://jsfiddle.net/dreamweiver/fZrz7/6/
Happy Coding :)
What about $(document).scrollTop()? It always worked for me.
Try smth like this..
if($(window).scrollTop()>500){
elm.html(jdesc[id].d.substring(0,347)+'...<br><div class="readmore"><span id="'+id+'">Show More</span></div>');}
else{
elm.html(jdesc[id].d+'<br><div class="readmore"><span id="'+id+'">Show Less</span></div>');
}
If work try next with
var ofs=elm.offset().top;
Try this:
$(document).height(); //returns window height
$(document).scrollTop(); //returns scroll position from top of document
$(selector)[0].scrollHeight;
$(document).prop('scrollHeight');
See the following fiddle:
[edit: updated fiddle => http://jsfiddle.net/NYZf8/5/ ]
http://jsfiddle.net/NYZf8/1/ (view in different screen sizes, so that ideally the image fits inside the %-width layouted div)
The image should start the animation from the position where it correctly appears after the animation is done.
I don't understand why the first call to setMargin() sets a negative margin even though the logged height for container div and img are the very same ones, that after the jqueryui show() call set the image where I would want it (from the start on). My guess is that somehow the image height is 0/undefined after all, even though it logs fine :?
js:
console.log('img: ' + $('img').height());
console.log('div: ' + $('div').height());
$('img').show('blind', 1500, setMargin);
function setMargin() {
var marginTop =
( $('img').closest('div').height() - $('img').height() ) / 2;
console.log('marginTop: ' + marginTop);
$('img').css('marginTop', marginTop + 'px');
}
setMargin();
Interesting problem...after playing around with your code for a while (latest update), I saw that the blind animation was not actually firing in my browser (I'm testing on Chrome, and maybe it was firing but I wasn't seeing it as the image was never hidden in the first place), so I tried moving it inside the binded load function:
$('img').bind('load', function() {
...
$(this).show('blind', 500);
});
Now that it was animating, it seemed to 'snap' or 'jump' after the animation was complete, and also seemed to appear with an incorrect margin. This smacks of jQuery not being able to correctly calculate the dimensions of something that hadn't been displayed on the screen yet. On top of that, blind seems to need more explicit dimensions to operate correctly. So therein lies the problem: how to calculate elements' rendered dimensions before they've actually appeared on the screen?
One way to do this is to fade in the element whose dimensions you're trying to calculate very slightly - not enough to see yet - do some calculations, then hide it again and prep it for the appearance animation. You can achieve this with jQuery using the fadeTo function:
$('img').bind('load', function() {
$(this).fadeTo(0, 0.01, function() {
// do calculations...
}
}
You would need to work out dimensions, apply them with the css() function, blind the image in and then reset the image styles back to their original states, all thanks to a blind animation that needs these dimensions explicitly. I would also recommend using classes in the css to help you manage things a little better. Here's a detailed working example: jsfiddle working example
Not the most elegant way of doing things, but it's a start. There are a lot more easier ways to achieve seemingly better results, and I guess I just want to know why you're looking to do image blinds and explicit alignment this way? It's just a lot more challenging achieving it with the code you used...anyways, hope this helps! :)
To see the issue go to this page and click the next text. The small, medium fullsize text will be off to the left (in IE8 or IE9, works fine in Chrome, FireFox) and will not be aligned with the left edge of the image.
Code (http://moments.qa.chucksoft.com/Scripts/mvc/views/show/Showview.js) Line 154:
ShowView.prototype.setImageSrc = function (imagesrc) {
var image = $('img#image');
image.attr('src', imagesrc);
image.load(function () {
var container = $('div#imagecontainer');
container.fadeIn(200);
var resizer = new Resizer();
resizer.resize(this.width, this.height, maxWidth, maxHeight);
var image = $(this);
var imageWidth = (resizer.width + 23);
container.width(imageWidth);
});
image.attr('src', imagesrc);
};
From what I can tell the container.width(imageWidth); is not rendered in IE8 or IE9. If the page is refreshed then it works. Using the built in developer tool shows the correct value in the html but if you use selector tool in the developer tool outline does not reflect the changed width value.
I've tried using vanilla javascript. That did not work. I've tried setting the image source twice. That did not work either.
I'm at a loss on how to fix this issue. Any insights would be much appreciated.
Update
To clarify, the issue arises when you transition from a landscape image to a portrait image, otherwise everything works as expected.
... ?
I have yet to figure this issue out. I have taken a different direction.