Hello FoundationTheme Weavers… Does the FoundationTheme have a sticky :hover fix for buttons and links on touch screen devices? Noticed that even the Foundation Theme site pages has this UI glitch on my iPad.
Also, if it does not is there a reason, e.g. it creates some other conflict or such? I ask as I could simply pull in my own Java Script fix if needed.
Kind Regards,
Dave
If you mean the flash as it fixes, then this is an iOS thing. It is unrelated to Foundation. During inertiall scrolling, elements that go from relative to fixed position do not get immediately redrawn.
You will get the same effect with other Plugins that you try to use or indeed your own code. For example this one http://stickyjs.com/ does exactly the same.
The issue is quite well documented on stack overflow.
Hi Andrew… Thank you for your response. No, actually referring to a common issue where buttons and links stick in there hover state when returning to the page via the browser back button.
Regards,
Dave
The problem is that when you use the back button, is that the browser loads a 100% cached version of the page and zero JS is ran again. This is why the back button is so fast.
Hi Joe… Thank you for clarifying the cause, much appreciated. Is there a fix built into the overall Theme or do I need to do this manually? I know how to pull in a simple Javascript fix but was just curious if the Theme already had a fix built in, e.g. modernizer or such.
Kind Regards,
Dave
So… I take that as a No.
I see the Foundation Theme site takes an approach of using lest drastic colors for the hover and normal state, which makes the issue less pronounced.
Are there any problems with using a hand coded fix to this issue when working with the Foundation Theme?
Regards,
Dave
If you have the knowledge to fix it on your own, then that is great. If you feel like sharing the that when you are done, I may be able to release it as a bug fix for everyone.
Hello Joe… Here is the Javascript I am currently using. Hope this may be of some help. Please note I am not an expert developer, like yourself, so you may spot something I have missed with this approach.
Kind Regards,
Dave
/* This snippet fix's an issue where touch devices get stuck on the hover state of a n item using an <a> tag */
if (!("ontouchstart" in document.documentElement)) {
document.documentElement.className += " no-touch";
}This may have unwanted ramifications. You are adding the no-touch class to your webpage when you are indeed on a touch device.
Hi Joe… How I have been using this is to link to the script and add the class to a specific tag, e.g. a Button, Link text and such. So I am not making the entire page, No Touch, just a given element. Seems to work great and definitely fix’s the issue on the touch screens.
The one thing that I have noticed though, is that the Google Speed test shows this script as a render-blocking script issue and that it should be fixed.
So I guess back to my original question, Is there a way to do this in the Foundation Theme or a Foundation approved stack?
Or, should this actually not be done and just live with this bad UX behavior? Could certainly just make the hover states similar to the normal state thus eliminating the need for the fix and making the issue less pronounced.
Kind Regards,
Dave
http://www.w3schools.com/jsref/prop_document_documentelement.asp
I am not sure what you are seeing as a render blocking script. You can use the SEO Helper stack with its Page Speed option to make this better. Foundation v1.6 improves this even more.
I have no idea what your website is and I could be wrong but it seems that you may be focusing on the 1%. There are a lot bigger things that you need to make sure that you get done before these extremely minor details that don’t really impact much at all.
Apologies Joe… It appears I am not being clear, thank you for your patience. I currently use this script to improve UX on hand baked sites, not sites deployed from RapidWeaver using the FoundationTheme or Foundation as a hand baked site either.
Fully agree with not obsessing with a tiny speed tweak, all this was related to the sticky hover state on touch devices. Just curious if your RapidWeaver FoundationTheme has some sort of fix for this UX issue?
Kind Regards,
Dave
OK, let me come at this another way… As I take from the silence that there is not a built in way through Foundation or another Stack developer to either resolve this UX issue or simply bring in my fix.
Actually glad I brought this up because this is the type of thing that comes up from time to time and want to be sure RapidWeaver will allow me to quickly implement fixes like this.
Please note this code is from one of my non RapidWeaver sites, hand built. I have included both the Javascript as well as the CSS for a simple footer link. This fix has been soak tested and seems to be solid. The only thing I have noticed was the Google speed testing tool recommendation that I mentioned earlier in this post.
Would appreciate any input how to go about doing this sort of thing in RapidWeaver.
KindRegards,
Dave
The Javascript
if (!("ontouchstart" in document.documentElement)) {
document.documentElement.className += " no-touch";
}
The CSS
.link-Footer a {
color: #ACB8BF;
font-family: 'luengoultralight', Helvetica Neue, Helvetica, Arial, sans-serif;
font-style: normal;
text-decoration: none;
}
.no-touch .link-Footer a:hover {
color:#83919B;
}You can easily add whatever custom code that you want in Rapidweaver either per page (via the page inspector) or site-wide (via the site-wide settings) or even via a Stacks HTML stack within your page. The method you choose will influence the location of the rendered code.
What you need to remember though as with any none hand coded site is that there will be other elements and classes that you have not created directly. So although you are “only” targeting your button with the no-touch class on your site, you will target anything else that may use such a generalised class name. Scoping is obviously important but you may find you need to make class names a little less generic for safety as well.