I am using jquerymobile 1.4.2.
I tried with all the functions which are specified using jquery(scrollTop).But it snot working in my page.
Is it possible to scroll to a specific position using css when we reload a page or when submit a button.
Your problem is that you have the script at the top of the page. I see you wrapped it in a $(document).ready() but that alone isn't always guaranteed to work, like in your case. $(document).ready fires when the dom is loaded, the dom tells the browser that somewhere in the page there is an image, but the browser won't know the size (in pixels) of that image until it's completely loaded. This causes your issue:
1) dom starts loading
2) dom is done, $(document).ready() fires
3) the script tries to animate the scrollTop but it won't work because the page has not yet reached its complete height (because the images are not loaded), so there is no scrollbar.
4) the images load but the script has already done its job
Solutions:
1) add height and width attributes to your images
2) use $(window).load() instead of $(document).ready()
A hint for the future: if the problem is "sometimes it works, sometimes it doesn't" it's a timing problem 90% (or even more) of the times. So try to figure out what happens and when.
No, there's no way to do that in CSS. Sorry!
Maybe, you should try for this one : jQuery.mobile.silentScroll()
Related
I want to be able to append the #web-messenger-container element to an element instead of the document.body.
I've tried using Smooch.render without setting the embedded attribute to true and it works fine on some browsers, but on others, the smooch CDN calls are cancelled. It is related with this issue: https://github.com/smooch/smooch-web/issues/666
I don't want to use embedded mode, I just want to move the Smooch button to another container. I've tried moving the iframe element with JS but it causes the iframe to reload and the Smooch window disappears.
I would say if you want to append #web-messenger-container to a different element, embedded mode is the way to do that. Without embedded mode Smooch's host JS will call render() to append the iframe on it's own so trying to call it second time will give you nothing but grief I think.
If all you want is to render your own open/close button, that's pretty straightforward. You can specify a custom button width and height of '0', and trigger Smooch.open() / Smooch.close() however you like.
For example:
https://jsfiddle.net/alavers/ve5uhjnd/
In a HTML page, an element can be repositioned for lots of reasons - style changes (margin, padding, height, etc) to the element, insertion or removal of other elements, or style changes to other elements.
I need to ensure that a jQuery dialog is always positioned next to an anchor, so if the anchor moves so will the dialog. However, I do not control the page that the dialog is displaying on (I inject some JS dynamically). I thought that I could observe changes to the offsetTop property of the element (and all it's parent elements) with a MutationObserver, but offsetTop changes do not seem to raise mutation events.
Can someone confirm that offsetTop changes will not raise a mutation event, or show me how I can watch the offset top?
Alternatively, if there is some other technique to ensure that a dialog stays with it's anchor, I'm all ears - but please be aware of the constraint that I don't control the page itself, only the dialog :)
FIDDLE:
In the following fiddle, clicking the "Margin" button modifies the margin-top of the anchor element, causing the style attribute to change, this triggering a reposition. However, clicking the other buttons does not cause a reposition, even though the offsetTop attribute has changed. I need the other two buttons to cause the position() function to be called.
http://jsfiddle.net/ustmssx7/2/
CONSTRAINTS
I do not control the HTML or the Javascript - my JS get's injected into someone else's page, so I am very limited in what I can do.
FALLBACK
My fallback solution is to poll the window.anchor.offsetTop every 100ms or so, and reposition if it changes. However, polling sucks, so if I can react to events instead that would be much better.
offsetTop cannot be observed with MutationObserver because only HTML structure changes can be observed. So any HTML data visible in the actual HTML of the page.
For your example, what you actually want is to observe the entire structure of the page, since any number of things can affect the position of the popup, and on any change to the page at all, you'll need to re-position your popup. Keep in mind though that there are still ways to modify the rendering state of the page without modifying the HTML of the page, like CSS animations and hover effects and such. Those would not be solvable with this type of solution.
I'm running into something really weird with my HTML/CSS.
When I reload the page sometimes one of my elements ends up positioned where it's supposed to be (centered vertically) and sometimes it ends up out of the viewport (something like 700px above the top of the page).
That the page acts differently on different page loads is only half of the weirdness. If I remove body's height: 100% property and re-add it in the web inspector everything magically fixes itself. (body is this element's direct parent.)
My instinct tells me that the answer to the first part of the weirdness is that there's some race condition going on causing things to happen in a different order randomly. But I'm not sure what that might be or why it's affecting things.
What could cause removing and re-adding an identical CSS attribute from an element to cause the page layout to change?
I can't reproduce in a jsfiddle unfortunately but here's a gif of this in action:
Edit: A new piece of the puzzle. I've discovered that this only happens in Chrome and appears to happen only if the page is loaded with an empty hash on the URL.
http://myurl.com works
http://myurl.com/#foo works
http://myurl.com/# intermittently has issues
There was a workaround to trigger a re-flow posted by #Huangism below but there are some caveats (some complications with timing when exactly to trigger a re-flow and also triggering a re-flow on a working page causes a flash of the content).
I think this is a weird bug with chrome, try this
After the content is shown, using jquery - hide the div that contains that content, check it's height and show it
Assuming $el is your jquery div element
$el.hide().height();
$el.show();
Try it and see if it fixes the issue or not
Try setting the height using js or jquery.
It looks like when you reload the page your CSS attributes are set to your body tag via style="" and then quickly removed. Its likely something in your js
Good grief this is hacky. Would still love an explanation for exactly what's going on and the proper way to deal with it but...
After figuring out that somehow an empty hash being appended to the URL was part of the issue an acceptable workaround seems to be completely removing an empty hash if present by using the html5 history API.
My code looks something like this:
// when the page is ready...
$(function() {
// if the url ends with a "#" (and the browser supports it...)
if(window.location.href && window.location.href.indexOf('#') == window.location.href.length - 1 && window.history) {
// clear the darn empty hash using the html5 history API
window.history.replaceState({}, '', './');
}
});
I´m tryin` to start a html-file always on a defined id.
I know that´s possible if you use that:
go to...
But this happens only if this link was clicked.
How can i force it all the time?
To start on a defined anchor (hash-defined) you will need to use JavaScript. The hash anchor in the end of a URL is used by the browser just after the navigation completes and you can't force it to "auto"-move without any client-side code.
To achieve similar effect with javascript perform the following function when the page is loaded:
function jumpToId( id ){
location.hash = "#" + id;
}
Of course, you will need to supply the id you want to jump to as the parameter to this function.
Please note, that in case JavaScript is disabled in the client's browser, the scrolling will not be performed. It is not a big deal, however, because majority of users have JavaScript enabled all the time (especially in today's social network-driven world :-) ).
Do you want it to scroll to the area or just immediately pop the user to it? For scroll you could use jQuery and just set it to scroll to the div using $(document).ready().
Here is an example. If you just want them to pop to it you could change the 1000 to 1 and it appears to immediately pop to the div.
Example Here Using jQuery
On an HTML page, a link like this:
Location on Page
...should navigate to this spot on the page:
<a name="pagelocation">
But in my experience, it sometimes misses - especially when linking from another page (like <a href="somepage.html#pagelocation">). By "misses," I mean it scrolls to the wrong spot on the page - maybe close, maybe not.
Normally, the target location ends up at the top of the screen. I know this can fail if there's not enough room below the anchor to scroll it to the top of the screen.
Why else would it fail? Does it depend on layout at all? How can I fix it?
(I'm keeping this general because I'd like a catch-all reference answer.)
Update 1
Thanks for the pointers so far about non-explicit image sizes. But what about on a page where all the elements have explicit size? (I'm dealing with one now.)
Quite often the scrolling can occur before the page has finished loading. If you have images without widths and heights, the page will jump, then load the image and re-layout itself, making the place you previously jumped to seem wrong.
Edit: Anything else that can change page layout should also be considered with suspicion... this include javascript and CSS that's not loaded in the <head> (never mind that all CSS should be loaded in the head; it isn't always).
If the page is bounced through a redirect, I believe IE will scroll the end page but Firefox won't.
JS Solution
Run this function on document ready.
function goToAnchor() {
hash = document.location.hash;
if (hash !="") {
setTimeout(function() {
if (location.hash) {
window.scrollTo(0, 0);
window.location.href = hash;
}
}, 1);
}
else {
return false;
}
}
I believe the behavior you are seeing is the result of the browser locating to that spot on the page before all images have finished loading. Once the images finish loading, then the layout of the page has changed (the page is likely longer vertically, for example), causing the location of where the anchor should be to have changed - but the browser still thinks it has already navigated to that anchor.
As mentioned above, this is probably due to images being rendered late and 'adjusting' the layout as they load.
If you can specify the size of the images then that much room can be allocated before they render, which should prevent the problem.
As a side note I've had this problem before in the form of using forward/back between enough pages that the images needed reloading, causing me to end up in the wrong place after they had rendered.
I have also seen this happen when JavaScript creates a drop-down menu at the top of a page. Then, once the menu has been finished, it is hidden, scrolling up the content below.
In the meantime, the browser has already set the target location at the top of the window. Hiding the menu a the very top of the page moves the target location up off the top of the window.
Note that you can add id="pagelocation" to just about any HTML element, for the same result, which saves you adding the additional anchors for link destinations.
OK. I think this is new. Using HTML5's autofocus will cause a misfire, as will jQuery's focus() method. Took 90 minutes of trial and error to discover this because I thought the issue was image related :)