I'm sorry your feelings were hurt when I declined to install your wonderful app that offers access to your website. Perhaps I just wasn't open to the awesome possibilities your app was offering me, but I already have a web browser that works just fine and couldn't be arsed to install more stuff. It's not you, it's me. I'm a bad, bad person. I get it. Now, about your "Scroll Up Bar"... It is indeed a very fine looking user interface, but my web browser already has one. I just can't seem to stop doing things that hurt your feelings, but could you please give me the option to turn that thing off?
If you're really having trouble justifying your job, perhaps I can help you out with a small suggestion. You may have noticed a trend towards wider aspect ratio screens over the last few years. Screens have gotten so bloody wide that practically nobody wants to read a column of text that is fully as wide as their screen! People were designing websites with UI elements on the sides even back when screens were slender 1.33:1 twigs instead of the McDonald's super-sized behemoths we have on our desks today. Perhaps you should take your bar, rotate it 90 degrees, and stick it on the side where there's space for it!
Sincerely,
An ungrateful, lazy, bad person who just can't be pleased.
No, you're not alone. I almost always choose desktop mode where available, primarily because mobile sites disable zoom and choose settings for margins and font sizes that make their text almost unreadably large - frequently only two or three words per line, with masses of whitespace all around.
Reading such articles feels claustrophobic, because you're stuck in this long tunnel of text, with little visual indicator of how long it lasts, inducing anxiety about wasted time. If you're somewhere in the middle, it's a long trip back up to the top.
The close to optimal mobile browser for me was the original (AOSP) Android browser around 2.3. It rewrapped text on double-tap to fit in the visible page area, meaning you could choose what effective font size worked well for you. And zoom still worked, so you had a good handle on where you were on the page, and an easy way out of it.
Neither Firefox nor Chrome on Android are as good a browser for me. Unfortunately, getting the AOSP browser back is awkward, unless you want to use Dolphin or similar, and besides, it no longer has the rewrap functionality.
PS: Google are the evil people here. They deliberately removed this feature from Chrome and AOSP browser, and are punishing sites that don't serve mobile-specific content - i.e. content that is less usable for people who prefer zoom-based navigation.
My general preference is the format that Readability will render.
Just the damned copy.
If you've got navigation elements, don't cram them into sidebars. Put them at the top of the page (but not fixed), or bottom (dittos).
For a huge number of sites, I disable presentation of headers, footers, and sidebars entirely. I'm not on the sites frequently enough to care to use them.
Some mobile sites do pretty well by removing extraneous elements, others cram in more fixed elements (top, bottom, or side), all of which send me running. There's simply not sufficient real estate to deal with that crap.
Increasingly, Web design isn't the solution, Web design is the problem.
I've suggested gently to the author of this site that he'd do better with balanced left/right margins, a 45em or so content width, semantic markup, and white backgrounds, but he's apparently not interested:
Seriously, when the easiest way to read content is to grab plain text via lynx or w3m, add Markdown, and re-export the page as HTML or PDF, you're doing it wrong.
I completely agree; what's more I find it really ironic that at the birth of the smartphone, Steve Jobs said (paraphrasing) "Great, now we have phones that can view the desktop web! Now we'll never have to write mobile specific sites again."
The best is when the desktop site fully loads and then some loading page comes up so that it can further load the "mobile experience" and then that "experience" turns out to be a total travesty.
I used to call these type of things, short-lived fads really: User Interface (UI) element of the week. Fortunately, UI isn't changing that often anymore. However, Javascript and the "mobile" platform are bringing "User Interface element of the week" back.
I am seeing lots of weird scrolly things these days. And, pages that blink out and then reappear, as they get rendered and rerendered and rerendered again by Javascript. Lots of other annoying Web 2.0 thingies that do little more than annoy. If I was a better writer, I could probably write a weekly WTF about "User Interface element of the week."
Yes, "fixed bars" are annoying. We've had "fixed bars" on non-mobile for as long as I remember: Main Menu Bar, Title Bar, ooh and now a "Tab Bar" which is just the modern version of Windows MDI, maybe Windows MDI, Navigation bar(s) which sometimes takes up a quarter of the screen height I kid you not, the Bookmarks Bar which gets hidden the first time I open the browser and all corporate links get deleted what a pain.
Including your "bar" in the contents and letting it scroll away might be easiest, and the author noted medium's clever idea.
Fixed bars are annoying and should rarely be used. But what's even worse is when the mobile version helpfully removes the content or feature that you'd like to see.
Please just have one site, make it efficient, and be done with it.
They're a problem on non-mobile, as well. If the bar is over content, but the scrollbar isn't adjusted for it, pressing space or pagedown doesn't move down one page worth of visible content. I don't get why breaking pagedown is acceptable. It's my preferred way to read long text.
It is also my pet peeve. It is a big disadvantage, and I haven't ever needed the top bar (or wished it was there when there isn't one) so for me top bars are a feature with negative score.
I guess we spacebarers are a minority and most people use the mouse wheel or the down arrow.
Thank you! It is a huge peeve of mine as well. There needs to be a good post somewhere to publicize this issue. Something you can point to when you find a broken site that lays out the solution so it can be fixed.
But I'm not sure exactly what the mechanism is that causes this; I thought it was simple a case of forgetting to add top padding to the page body, but that doesn't always seem to be the case. Last time I saw a site that did this, it already had the padding but still misbehaved in Chrome. Yet the paging worked correctly in Firefox! Further testing showed Safari worked, so (in this case, at least) it seemed to be webkit-related.
But that's just one scenario. I suspect there's a number of ways people get this wrong, and it's unfortunately not just a single simple fix for all cases.
Yes, this is quite a pet peeve of mine. Every other site nowadays seems to do this, even ones that I thought should know better (arstechnica is one that comes to mind)
Firefox Browser for Android's default settings requires you to scroll up somewhat rapidly on the page you're currently reading to reveal the browser's auto-hidden URL bar and menu. I tend to loathe this functionality because it means slightly losing my place every time I want to multitask when reading something.
I suppose it wouldn't be so bad as part of a website when viewed from a desktop environment, because you can easily highlight where you left off on the page much easier than you can on a tablet, for example.
The sole reason is branding. Websites don't want you just reading content; they want you reading content on their site. The most obvious way to remind you that you're reading it on their site, and thus convince you to come back, is a fixed header bar.
This really depends on the device. iOS devices with their fancy inertial stuff scrolling is very pleasant but if you're using entry level cheap devices, scrolling is not as easy or pleasant. Specially with the new trend of infinite scrolling sites where your scroll down for days...
> I don't get why these bars are being used everywhere
I Blame it on the design patterns of (Twitter) Bootstrap. A lot of sites are put together with it. Although the default nav-bar is not bolted to the top it is easy to read how to do that in the docs and implement it because it seems like a good idea at the time. Others, not using Bootstrap then copy the 'new convention'.
Personally I believe that for some content, e.g. a Tumblr style blog, the nav-bar at the top (and fixed) makes a lot of sense. If you also have pet-peeve infinite scroll (as many do on Tumblr blogs + Pinterest), then it is helpful to have a fixed header as there is no footer.
Worse than taking up screen space, these bars often exhibit laggy scrolling behavior and cause other UI bugs. There are very few well working implementations of such fixed bars, partly due to difficulties like the position:fixed implementation in Mobile Safari[0] - unless that has been changed in iOS7.
I highly recommend to refrain from using position:fixed on mobile devices.
Mobile web moves too quickly to care about what was true 2 entire years ago :) iOS got position: fixed a couple versions back, and iOS users upgrade rapidly.
So, the advice not to use position: fixed on mobile may still be good, but iOS isn't the reason why.
What's worse is some sites that do this can't seem to differentiate between iPads and iPhones and seem to use percentages everywhere in their CSS. As a result, you get a huge header (which feels larger in landscape orientation).
I've had helpful 'popups' on mobile sites that I couldn't close because the close button was perpetually out of screen, as they were not designed for the small screen. To my surprise, I've seen this on a number of big sites.
It baffles me that nobody ever noticed this bug, but on the other hand I can see how this would happen. The developers probably never noticed because they already had the cookie that prevents the popup from showing. Still...
Another big annoyance is when the mobile mode is solely based on the user agent string and there is no way to deactivate it other than changing the user agent (for example Google Search). It’s almost as if no Google employee has a tablet device. I would be genuinely interested in seeing behind the curtains of decisions like this one.
The problem is that he's assuming the primary goal of the site's UI is to make reading the content as enjoyable and efficient an experience as possible.
Sadly, that's rarely the case.
A site like Forbes gets paid every time you click through to another article. Once you've landed on an article and you're reading it, your value to them has been expended. Thus they have almost a diametrically-opposed interest to yours- you want to read the content uninterrupted, and they want you to click another link.
I wouldn't say 0 loc CSS is nothing to lose, I've been using Markdown to format some really basic notes, and here's my stylesheet for styling markdown documents: http://staticresource.com/styledown.css
It's still a work-in-progress, but it's great for documenting my code as I work on websites. Here's a demo page with some tests of the markdown output I generated on the command-line using pandoc: http://staticresource.com/misc/demo.html I'm grabbing web fonts from Google. It's responsive and reads well on desktop, tablet, and phone. The styles still work offline (with no web fonts)
There isn't a whole ton of CSS there (I work with files 500 loc CSS up to 5k or 7k a a time. I whipped this up in one morning because I was tired of my IDE's markdown live preview, so now I have folders on my server that are watched, and any time I save a markdown file it automatically regenerates the HTML in the same folder.
I was all ready to complain that I want some sort of nav/menu thing always stuck at the top, but I'm actually OK with the solution presented where it just shows as soon as you scroll up without having to scroll all the way.
FIxed bars and JS pop-ups are the window pop-ups of the 90's and really I'm just waiting for someone to make a chrome extension that takes care of 'em in the same way.
The only real issue is that mobile browsers don't allow extensions of any kind (at least the ones I've used don't). So there is no real way to add such customizations to mobile browsers, and we're left hoping they go mainstream enough that someone either creates a browser around that feature (ie useragent switch, which is kind of annoying to use because it means copying the url and switching apps), or a dev in a mainstream browser makes it their weekend project. Neither one of these options is ideal, in the first you're left with a bunch of browsers that do one thing, in the latter you're going to end up with a feature that will slowly stop working as the dev's main work builds and his manager tells him to drop it.
An interesting way to solve the issue is to hide the bar when scrolling down, and show it when scrolling up.
This pattern is one of the many irritating things about the mobile Chrome and iOS 7 browsers that prevents me from using devices implementing either.
I typically stick to reading around the top of my device, and occasionally I want to re-read something I just read. Instead of just getting to re-read the hidden lines, I have to continue scrolling while stupid chrome or a fixed bar appears, and then finally lets me scroll the content.
It's probably the case that a lot of people love this, but I hate it. If I want to see the browser chrome or navigational elements, I'm happy to tap the top of the window to scroll me there. I don't want the browser trying to figure out what I want to do based purely on scrolling.
I suspect this was influenced by the browser behavior in iOS 7. Almost all the browser chrome (full address bar and status bar) disappears when you start scrolling but reappears if you scroll back up quickly.
In fact, the iOS behavior is rather more nuanced:
* Scrolling down hides chrome
* Swiping up quickly reveals chrome
* Scrolling up slowly does not reveal chrome
* Scrolling to the top of the page reveals chrome
* Over-scrolling past the bottom reveals chrome
It's often interesting to see how much consideration Apple puts into small details like this.
This is also the best implementation. I think there's some stuff lost in translation when done on the web. Dollars to doughnuts these UI patterns don't have a speed function in them to adjust for intent.
The thing about this is that there is, as far as I can tell, no good solution for the fact that it can take a long, long time to return to the top of a page with a lot of text on a mobile device. If I read 3/4 of a lengthy story on my phone and I want to navigate somewhere else on the same website my only practical option is to revisit the main page of the site and start navigating from there.
Do any mobile browsers have a "return to top of page" function? My keyboard has a "Home" key, my phone does not.
I don't know what mobile phone you use, but on iOS tapping the status bar scrolls back to the top of the page (or anything else that scrolls in the system).
Seriously? Pretty sure this has been in iPhone Safari since 1.0 (tap top bar to scroll to top), or at least as long as I can remember. I realize other browsers/platforms may not have this but that's a pretty big one to leave out...
We feel your pain. It may not seem like it since we develop ever more complicated UI schemes to overcome the W3C's frankenstandards (seriously, who comes up with a coordinate system based on a 'nominal arms length away' from the screen and then creates another set of units for mobile. I know there's a lot of smart people who contribute great data standards from the W3C, but when it came to presentation standards they either 1) completely forgot their linear algebra or 2) didn't bother to look at Postcript's coordinate system or both).
Some of us are reinventing the browser as it should have been written (with polyfills and shims), but this will take a while to get right. (For those that remember, Alan Kay originally said there should be no browser, just a code container, we are once again getting close to something he said decades before).
We understand that the W3C has set the expectation that everything bad on the web happens because of us devs not following their "standards" (even when alt changes to title changes to picture caption in as many years), but at some point it might be worth asking them "why are your presentation standards so inconsistent and hard to follow?"
Sincerely,
A webdev who is tired of cajoling CSS and JS to reinvent the same god-damned three column layout that should have worked in the 90's (oh wait, you didn't realize that Postscript predates the web? Yes, yes it did. So the W3C could have sought presentation layer experts of its time in drafting presentation standards, but didn't).
Someone has already mentioned my JS lib to handle this below, but as the author I feel compelled to mention it myself with some additional explanation.
I built headroom.js [0] to handle exactly this. It simply adds classes at scroll up or down so you can be as fancy as you want (or not!) with the show hide effect. You can set a custom offset (eg. Don't invoke the hide/show mechanism until 100px down the page), you can set a tolerance (eg. Must have scrolled more than 10px before hide/show) and a few other features for more advanced usage.
And for fun I built a little playground so you can explore the various features and find a configuration you like [1]
(meta: I submitted it here, but it never gained traction, someone else submitted it to designer news and it absolutely blew up, can't believe it almost has 4000 stars!)
I honestly loathe the "scroll up bar" feature in Chrome browser because it throws off my instincts about how to interact with the UI. If something auto-hides into the top of the screen, my instinct is to pull it down from the top if I want to see it again. That just brings up the Android notification system.
[+] [-] beloch|12 years ago|reply
I'm sorry your feelings were hurt when I declined to install your wonderful app that offers access to your website. Perhaps I just wasn't open to the awesome possibilities your app was offering me, but I already have a web browser that works just fine and couldn't be arsed to install more stuff. It's not you, it's me. I'm a bad, bad person. I get it. Now, about your "Scroll Up Bar"... It is indeed a very fine looking user interface, but my web browser already has one. I just can't seem to stop doing things that hurt your feelings, but could you please give me the option to turn that thing off?
If you're really having trouble justifying your job, perhaps I can help you out with a small suggestion. You may have noticed a trend towards wider aspect ratio screens over the last few years. Screens have gotten so bloody wide that practically nobody wants to read a column of text that is fully as wide as their screen! People were designing websites with UI elements on the sides even back when screens were slender 1.33:1 twigs instead of the McDonald's super-sized behemoths we have on our desks today. Perhaps you should take your bar, rotate it 90 degrees, and stick it on the side where there's space for it!
Sincerely,
An ungrateful, lazy, bad person who just can't be pleased.
[+] [-] Aardwolf|12 years ago|reply
I always feel totally alienated by the mobile page, there is information left out, annoying badly-implemented JS scrollers, etc...
The "desktop" site looks always more nice and familiar, and you can zoom and scroll around as you wish to read everything.
[+] [-] barrkel|12 years ago|reply
Reading such articles feels claustrophobic, because you're stuck in this long tunnel of text, with little visual indicator of how long it lasts, inducing anxiety about wasted time. If you're somewhere in the middle, it's a long trip back up to the top.
The close to optimal mobile browser for me was the original (AOSP) Android browser around 2.3. It rewrapped text on double-tap to fit in the visible page area, meaning you could choose what effective font size worked well for you. And zoom still worked, so you had a good handle on where you were on the page, and an easy way out of it.
Neither Firefox nor Chrome on Android are as good a browser for me. Unfortunately, getting the AOSP browser back is awkward, unless you want to use Dolphin or similar, and besides, it no longer has the rewrap functionality.
PS: Google are the evil people here. They deliberately removed this feature from Chrome and AOSP browser, and are punishing sites that don't serve mobile-specific content - i.e. content that is less usable for people who prefer zoom-based navigation.
[+] [-] dredmorbius|12 years ago|reply
Just the damned copy.
If you've got navigation elements, don't cram them into sidebars. Put them at the top of the page (but not fixed), or bottom (dittos).
For a huge number of sites, I disable presentation of headers, footers, and sidebars entirely. I'm not on the sites frequently enough to care to use them.
Some mobile sites do pretty well by removing extraneous elements, others cram in more fixed elements (top, bottom, or side), all of which send me running. There's simply not sufficient real estate to deal with that crap.
Increasingly, Web design isn't the solution, Web design is the problem.
I've suggested gently to the author of this site that he'd do better with balanced left/right margins, a 45em or so content width, semantic markup, and white backgrounds, but he's apparently not interested:
http://www.billdietrich.me/Reason/ReasonConsumption.html
Seriously, when the easiest way to read content is to grab plain text via lynx or w3m, add Markdown, and re-export the page as HTML or PDF, you're doing it wrong.
http://redd.it/256lxu
[+] [-] lelandbatey|12 years ago|reply
I explain the feeling a bit more here: http://lelandbatey.com/posts/2014/02/shoot-your-mobile-site/
[+] [-] jgh|12 years ago|reply
[+] [-] EC1|12 years ago|reply
[+] [-] mmphosis|12 years ago|reply
I am seeing lots of weird scrolly things these days. And, pages that blink out and then reappear, as they get rendered and rerendered and rerendered again by Javascript. Lots of other annoying Web 2.0 thingies that do little more than annoy. If I was a better writer, I could probably write a weekly WTF about "User Interface element of the week."
Yes, "fixed bars" are annoying. We've had "fixed bars" on non-mobile for as long as I remember: Main Menu Bar, Title Bar, ooh and now a "Tab Bar" which is just the modern version of Windows MDI, maybe Windows MDI, Navigation bar(s) which sometimes takes up a quarter of the screen height I kid you not, the Bookmarks Bar which gets hidden the first time I open the browser and all corporate links get deleted what a pain.
Including your "bar" in the contents and letting it scroll away might be easiest, and the author noted medium's clever idea.
[+] [-] masterleep|12 years ago|reply
Please just have one site, make it efficient, and be done with it.
[+] [-] nostromo|12 years ago|reply
Here's what the EC2 console looks like on mobile:
http://i.imgur.com/MfbCdhU.png
It appears that Amazon is doing this on purpose...
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">
Yes... user-scalable=no
[+] [-] hiphopyo|12 years ago|reply
http://ux.stackexchange.com/questions/57990/how-usable-are-b...
[+] [-] mercer|12 years ago|reply
[+] [-] RobotCaleb|12 years ago|reply
[+] [-] rbonvall|12 years ago|reply
I guess we spacebarers are a minority and most people use the mouse wheel or the down arrow.
[+] [-] pimlottc|12 years ago|reply
But I'm not sure exactly what the mechanism is that causes this; I thought it was simple a case of forgetting to add top padding to the page body, but that doesn't always seem to be the case. Last time I saw a site that did this, it already had the padding but still misbehaved in Chrome. Yet the paging worked correctly in Firefox! Further testing showed Safari worked, so (in this case, at least) it seemed to be webkit-related.
But that's just one scenario. I suspect there's a number of ways people get this wrong, and it's unfortunately not just a single simple fix for all cases.
[+] [-] paol|12 years ago|reply
[+] [-] rl3|12 years ago|reply
I suppose it wouldn't be so bad as part of a website when viewed from a desktop environment, because you can easily highlight where you left off on the page much easier than you can on a tablet, for example.
[+] [-] ohleg|12 years ago|reply
[+] [-] pera|12 years ago|reply
[+] [-] vertex-four|12 years ago|reply
[+] [-] soapdog|12 years ago|reply
[+] [-] Theodores|12 years ago|reply
I Blame it on the design patterns of (Twitter) Bootstrap. A lot of sites are put together with it. Although the default nav-bar is not bolted to the top it is easy to read how to do that in the docs and implement it because it seems like a good idea at the time. Others, not using Bootstrap then copy the 'new convention'.
Personally I believe that for some content, e.g. a Tumblr style blog, the nav-bar at the top (and fixed) makes a lot of sense. If you also have pet-peeve infinite scroll (as many do on Tumblr blogs + Pinterest), then it is helpful to have a fixed header as there is no footer.
[+] [-] WorldWideWayne|12 years ago|reply
One place that didn't work is at Forbes.com because they're using CSS to implement that particular annoyance.
[+] [-] pfalke|12 years ago|reply
I highly recommend to refrain from using position:fixed on mobile devices.
[0] http://remysharp.com/2012/05/24/issues-with-position-fixed-s...
[+] [-] badman_ting|12 years ago|reply
So, the advice not to use position: fixed on mobile may still be good, but iOS isn't the reason why.
[+] [-] SoftwareMaven|12 years ago|reply
[+] [-] mercer|12 years ago|reply
It baffles me that nobody ever noticed this bug, but on the other hand I can see how this would happen. The developers probably never noticed because they already had the cookie that prevents the popup from showing. Still...
[+] [-] tambourmajor|12 years ago|reply
[+] [-] dkrich|12 years ago|reply
Sadly, that's rarely the case.
A site like Forbes gets paid every time you click through to another article. Once you've landed on an article and you're reading it, your value to them has been expended. Thus they have almost a diametrically-opposed interest to yours- you want to read the content uninterrupted, and they want you to click another link.
[+] [-] dredmorbius|12 years ago|reply
[+] [-] fdsary|12 years ago|reply
Plain html works great on any device, is very readable, accessible and lightweight. There's nothing to lose in having 0 loc css.
[+] [-] err4nt|12 years ago|reply
It's still a work-in-progress, but it's great for documenting my code as I work on websites. Here's a demo page with some tests of the markdown output I generated on the command-line using pandoc: http://staticresource.com/misc/demo.html I'm grabbing web fonts from Google. It's responsive and reads well on desktop, tablet, and phone. The styles still work offline (with no web fonts)
There isn't a whole ton of CSS there (I work with files 500 loc CSS up to 5k or 7k a a time. I whipped this up in one morning because I was tired of my IDE's markdown live preview, so now I have folders on my server that are watched, and any time I save a markdown file it automatically regenerates the HTML in the same folder.
Anyway, you can't say there's NOTHING to lose having 0 loc CSS. Here's what that same markdown demo that looks like with no CSS: http://staticresource.com/misc/demohtml.html
Think they are equivalent?
[+] [-] lnanek2|12 years ago|reply
[+] [-] jrajav|12 years ago|reply
[+] [-] vxNsr|12 years ago|reply
The only real issue is that mobile browsers don't allow extensions of any kind (at least the ones I've used don't). So there is no real way to add such customizations to mobile browsers, and we're left hoping they go mainstream enough that someone either creates a browser around that feature (ie useragent switch, which is kind of annoying to use because it means copying the url and switching apps), or a dev in a mainstream browser makes it their weekend project. Neither one of these options is ideal, in the first you're left with a bunch of browsers that do one thing, in the latter you're going to end up with a feature that will slowly stop working as the dev's main work builds and his manager tells him to drop it.
[+] [-] erso|12 years ago|reply
I typically stick to reading around the top of my device, and occasionally I want to re-read something I just read. Instead of just getting to re-read the hidden lines, I have to continue scrolling while stupid chrome or a fixed bar appears, and then finally lets me scroll the content.
It's probably the case that a lot of people love this, but I hate it. If I want to see the browser chrome or navigational elements, I'm happy to tap the top of the window to scroll me there. I don't want the browser trying to figure out what I want to do based purely on scrolling.
[+] [-] dmalik|12 years ago|reply
[+] [-] hiphopyo|12 years ago|reply
http://ux.stackexchange.com/questions/57990/how-usable-are-s...
[+] [-] dj-wonk|12 years ago|reply
[+] [-] pimlottc|12 years ago|reply
In fact, the iOS behavior is rather more nuanced:
It's often interesting to see how much consideration Apple puts into small details like this.[+] [-] rrrx3|12 years ago|reply
[+] [-] ajanuary|12 years ago|reply
[+] [-] JamisonM|12 years ago|reply
Do any mobile browsers have a "return to top of page" function? My keyboard has a "Home" key, my phone does not.
[+] [-] micampe|12 years ago|reply
[+] [-] badman_ting|12 years ago|reply
[+] [-] hrvbr|12 years ago|reply
[+] [-] coldnebo|12 years ago|reply
We feel your pain. It may not seem like it since we develop ever more complicated UI schemes to overcome the W3C's frankenstandards (seriously, who comes up with a coordinate system based on a 'nominal arms length away' from the screen and then creates another set of units for mobile. I know there's a lot of smart people who contribute great data standards from the W3C, but when it came to presentation standards they either 1) completely forgot their linear algebra or 2) didn't bother to look at Postcript's coordinate system or both).
Some of us are reinventing the browser as it should have been written (with polyfills and shims), but this will take a while to get right. (For those that remember, Alan Kay originally said there should be no browser, just a code container, we are once again getting close to something he said decades before).
We understand that the W3C has set the expectation that everything bad on the web happens because of us devs not following their "standards" (even when alt changes to title changes to picture caption in as many years), but at some point it might be worth asking them "why are your presentation standards so inconsistent and hard to follow?"
Sincerely,
A webdev who is tired of cajoling CSS and JS to reinvent the same god-damned three column layout that should have worked in the 90's (oh wait, you didn't realize that Postscript predates the web? Yes, yes it did. So the W3C could have sought presentation layer experts of its time in drafting presentation standards, but didn't).
[+] [-] WickyNilliams|12 years ago|reply
I built headroom.js [0] to handle exactly this. It simply adds classes at scroll up or down so you can be as fancy as you want (or not!) with the show hide effect. You can set a custom offset (eg. Don't invoke the hide/show mechanism until 100px down the page), you can set a tolerance (eg. Must have scrolled more than 10px before hide/show) and a few other features for more advanced usage.
And for fun I built a little playground so you can explore the various features and find a configuration you like [1]
[0] http://wicky.nillia.ms/headroom.js/
[1] http://wicky.nillia.ms/headroom.js/playroom/
(meta: I submitted it here, but it never gained traction, someone else submitted it to designer news and it absolutely blew up, can't believe it almost has 4000 stars!)
[+] [-] hiphopyo|12 years ago|reply
[+] [-] Pxtl|12 years ago|reply