I've checked out the other page jump questions here on SO and I haven't found anything that matches, so here we go...
I'm working on building a website that uses CSS3 transitions and a bunch of hash-links as opposed to using jQuery to load/transition different pages/elements (just for fun/to prove that I/CSS can). The problem I'm having is that when I click on one of my links, the scrollbar automagically jumps down about 100px for no apparent reason.
I don't recall it doing this the entire time, so maybe something in my CSS went weird. I also added some <a name> tags at the top to try to pull it back up, but that's not working either. I also tried putting onclick="window.scrollTo(0,0);" in the links as well and that doesn't work either :(
Any ideas/help would be awesome, as it's really annoying/poor usability to have to scroll every time you navigate to the page. You can view the page here.
System Info:
Browser(s): Chrome 16.0.912.75, FireFox 9.0.1, Opera 11.6
OS: Windows 7
I'm not familiar with CSS3 transitions, so I don't fully understand what you're doing. However:
I assume this behavior that you find undesirable has something to do with the browser's native behavior of scrolling an element into view based on the fragment identifier in the URL. I'm not sure if overriding that with <a name> elements would work, but in any case you've incorrectly set the name values by prefixing them with a hash. E.g should be <a name="about"></a> not <a name="#about"></a>.
At least for debugging purposes, I'd try adding a click event listener and calling preventDefault() in it to see if it stops the scrolling.
It would be helpful to state what browser (including OS and version) you're experiencing the issue in.
Notice that it is not just jumping down to a random place, it is jumping down to the element that has the ID of the hash. (Try adding #footer to the end of your url) I do not think you can get around that without using preventDefault in JavaScript.
Related
I'm writing my own site as a hobby (any html/css/js I know is self taught), but I've run into a issue that I can't seem to really understand (and thus I don't know how to fix it). I can't handle/fix this by myself unfortunately.
I tried taking away as much unneeded code as I could, reducing the site to the bare minimum where it still exhibits the unwanted behavior. I'm sorry for amateurish/hacky code, I'm not doing this professionally after all.
Here is a jsfiddle showing the code. It exhibits my wanted behavior: Click on any of the "Folders" and it expands and shows the "content". So far, so good.
If I now load the exact same code onto a site (I'm using netlify here), it still behaves as I want it to: Netlify link
If however I access it on a mobile browser (for reference I tried it on Google Chrome, Firefox and Brave browsers, all on Android) I get some behavior that I don't want:
If I expand one Folder, it works as intended, but if I expand the second folder as well the Folder name and its contents seem to change font size (they get noticeably bigger). If I close the normal one and reopen it it also changes size. For reference,
this is what it looks like.
It almost seems like me switching the display property to block changes the font size to something else, but I only defined one font size in the whole css.
I really don't know why this happens and I'd appreciate any help that explains it or points me in the right direction.
Thanks.
Edit: I managed to contact a third party who tried the site on their phone (iOS) and there the site did not exhibit the same weird/unwanted behavior. I'm not sure what exactly to do with that information.
I might have finally found a working solution to this weird and unexpected behavior. In your CSS, in the body section, add the following rules:
font-size-adjust: none;
text-size-adjust: none;
-webkit-text-size-adjust: none;
Those rules do not really have wide-spread support, apparently, and might change or their support get dropped at some point. One works only for Firefox, the other only for Chromium-based browsers, and yet another seems necessary for legacy Chromium-based. See:
https://developer.mozilla.org/en-US/docs/Web/CSS/font-size-adjust
https://caniuse.com/?search=font-size-adjust
https://caniuse.com/?search=text-size-adjust
Only with all three of those rules did I successfully prevent this font scaling for mobile Chromium, mobile Firefox Quantum (the old Firefox <=68 was not affected), both on Android, and for Chromium mobile mode on a Linux desktop. At least as far as my tests indicate.
Although I still fail to understand how and why such a rule would even be necessary: There definitely is no other conflicting rule in your example to affect rendered font size. My very wild guess would be that, under certain circumstances, some mobile browsers do not apply font-size rules correctly to hidden elements, causing this obscure cascaded font scaling.
Not at all the answer, but the described behavior can be reproduced even on a computer (Ubuntu Linux in my case; non-android device) using the given netlify link in Chromium, when using the mobile mode in Chromium DevTools. Maybe by reproducing it this way, somebody gets behind the cause of this behavior.
Upon opening the second folder, the font-size is indeed set to something 42.073px or something similar, depending on the responsive mode selected in the mobile mode. This is only shown in the "Computed" tab of DevTools, but there is no rule for this size in the "Styles" tab. I don't see any apparent cause for this text size change, sorry.
A few notes, however, on your HTML code (though none of the below seems to solve your problem):
Better put the <script> tag inside the <body> tag, right before the closing </body>. Or put it inside the <head>, but then make sure it get executed after page load. Outside <body> or <head>, your <script> is somewhat in limbo – unexpected side-effects included.
Similar goes for your <meta> tag. Put it inside the <head>.
For valid code and to reduce and even avoid unexpected side effects, surround your complete HTML code with an <html> tag, and define a doctype, e.g. <!doctype html> at the beginning of your HTML. Validate your HTML, for example here: https://validator.w3.org/#validate_by_input
I'm loading 2 embedded svg-lets in a page. One animated one not. They're loaded in sequence with a setTimeout.
When I load the animated first all goes well, the animation starts as expected and the second static svg is correctly displayed afterwards. When I first load the second, and afterwards the animated one, the animation does not start.
Code is here: jsfiddle switch #svg1, and #svg2 in the javascript.
Upon browser checking I found out this is probably a webkit bug as chrome and safari both show this behavior FF 12 and Opera are well.
Can this be fixed with JS code or should I file a bug with webkit?
== Added
I think the question should be rephrased why the animation does not start after the svg is loaded with a settimeout.
As Jared investigated below it works when the element is present in the DOM and is reordered via dom manipulation into the focus element, Chrome and webkit need a kick with a beginElement() call to the animate element. This still doesn't work out for elements constructed from plain text. As I only do have a mac and I still consider this a hobby project I leave MS IE completely out of the loop.
Well, it took quite a bit longer than I anticipated, but I got it worked out. Basically, the method you were using with the semi-SVG and the regex on the markup, etc., was to say the least not quite the way to get it done.
The answer is to use svg DOM animation methods and attributes, especially to start/stop the animation when you want it to run. Apparently, Firefox was just fine with reinitializing the element and the animation just by manipulating the inner HTML/markup. Chrome (Webkit?), however, actually needs you to programmatically access and control the element. I have not checked in IE, Opera or Safari.
I redid the example, leaving out the arrow altogether, as it is unrelated to the problem. I instead concentrated on creating and testing the animation functionality. The critical points you were missing before were:
var $lasso = $('#lasso'),
animater = $lasso.find('animate')[0],
...
animater.beginElement();
...
animater.endElement();
Here is the demo I made, which is significantly different that what you have in your question:
http://jsfiddle.net/9hBfs/
What I call the "lasso" effect is still there, though.
I would reference the Mozilla Developer Network (MDN) site, as they have a lot of great information and are a highly trusted authority:
https://developer.mozilla.org/en/SVG
https://developer.mozilla.org/en/SVG/Element/animate
http://www.w3.org/TR/SVG11/animate.html#animation-mod
http://www.w3.org/TR/SVG11/animate.html#InterfaceElementTimeControl
http://www.w3.org/TR/SVG11/animate.html#RestartAttribute
I created a mobile site in html and jquery, but it is not loading properly in Chrome (or on an iphone). There is no backend to the site - all changes to content would happen right through editing the html. Inside of my html, I made no specific reference to ajax. And, each page links through "#pageid. The problem is that as I navigate the site, various pages do not display correctly unless I hit "refresh." URL is mobile.shorelinelake.com. I am VERY new to this, so please be patient with a newbie :) Thanks for any help!
http://mobile.shorelinelake.com (if you click through to "Lake" and then "Sailing," or "Cafe" to "Menu," you can see the problem - the page jumps after loading, cuts off the header, places content below the footer, or will entirely hide jquery elements...)
One thing I noticed right away is that your using an old version of Jquery and Jquery Mobile. There have been alot of improvements since the alpha that you are using. Also you are linking to a few files that aren't there. Phonegap.js and ajax-loader.gif for some reason are not found. In my console I see 196 warnings that I believe are all related to you using old versions.
Also you have 31 html errors. One example is here
line 88:
<a href="tel:16509657474" div data-role="button" data-theme="c" class="ui-btn-text">
You have alot of stranded </p> tags. Most of them are in the menu page. Fixing these errors is necessary to troubleshoot your problem. Try running your document through an html5 validator to find these mistakes.
I also recommend breaking this into smaller pieces. Here is my reasoning:
Easier to maintain and edit.
Keep the dom size reasonable. Jquery will remove the old pages from the dom keeping it very manageable.
Faster page loading resulting in a better user experience. Your user will probably not be going to each page. Only load what they need to see.
Bandwidth could be costing your user extra money on a mobile device.
I am unable to replicate the problem when I want to but it seems like every now and then, my site using FCKeditor will load the interface but not the content (Clicking the buttons don't do anything). No javascript errors show and once it starts doing it, it usually is tough to get back to normal. The way I found to work best is to click the refresh button multiple times in a row, then the FCKeditor loads correctly. I have only seen this in Firefox
Has anyone else run into this problem or know a solution. It is a little annoying for me but I am afraid my client would be really confused
I have experienced the phenomenon you describe in FCKEditor's successor, CKEditor. Somehow, the IFRAME that contains the WYSIWYG content doesn't get loaded. What always helps is switching to source code view and back, but that's no solution.
I have seen the problem described on the Internet but with no solution.
Caching is not the problem, I think. Sometimes, if you press "reload" 20 times, it will break at the 21th time, and work again on the 22nd time.
What minimized the number of occurrences for me was to activate the thingy to the editor's bottom that shows the element path (body > p > span, I forgot it's name). I don't now why but since I turned it on, it very rarely breaks any more.
I have had this problem. I solved it by pre-loading FCKeditor in a hidden iframe during the login process so that when it got to the pages where it was used it was already in the cache.
i would strongly advise to upgrade to CKEditor which can not only be spelled out verbally without offending anyone, but also optimizes the loading time to minimal. I find it much more responsive than his F- friend.
I encountered this problem with firefox (not reproducible) and chrome (reproducible).
The solution that worked quite well in both cases was to wait for some milliseconds before initializing CKE :
setTimeout(function() {textarea.ckeditor({customConfig : 'custom/schnonfig.js'})} , 100);
My layout breaks if I change the window size in IE7/AOL, so I added a simple javascript function that fires on window.onresize, but no matter how I change the location I get problems.
It was suggested I post a link and here it is: http://sinaesthesia.co.uk/
I already use PHP to detect browser and include an IE7-only inline stylesheet (and for mobile browsers), and my page looks nearly identical to the way it does in FF, Opera, Chrome, Safari and IE8, but when I change the window size, some things go wonky, and come back into line if you refresh. Any advice is welcome :)
I advise you to fix the real problem: your layout breaking when the browser is resized. Reloading the page onresize is definitely not a best-practice.
If you post a link to your page, you might get some good insight into the sources of your problems.
I think that fixing layout issues like yours with javascript is not a good idea.
A better approach would be to detect what is broken. and add a conditional comment to include an IE only stylesheet.
You should fix the layout problems instead.
There is no way to refresh a page in the way you want to do it. On reload, everything will be redrawn, and the blinking/not blinking is dependent on the exact state of the users' browser.