Sticky table headers and columns: yes, yes, yes. That is very important for usability, and currently hard to do properly. If I could just add a layout attribute to a THEAD or COLGROUP, my life would be significantly easier.
We've spent a lot of time implementing this ourselves for a data table containing lab analysis values. It's a big requirement from our customers. You can imagine it's pretty important to be able to match rows and columns (sample types and dates) correctly when you're looking at these values.
The planning meeting about this was pretty funny.
Boss: "So, we'll just make the headers fixed, should be easy, right?"
Developer: "Heh-heh... Yeah, we could probably get that working decently in just a couple of weeks. We'll have to test it in all the browsers, of course, and do performance tests with big data sets. It's possible that we might not be able to get it to work well enough on all platforms, so we should have a backup plan."
Boss: "Sigh. This would be so much easier in Visual Basic..."
The boss is right though. This (and a lot of other things) is much easier in almost every other GUI lib I worked with. Some things like documents (flowing text with images etc) are easier in HTML, but that is what it was made for.
The thing is though. That really the semantic markup is already there in the table. So I don't see why the browser in this case can't just help you out a little. You could click the table, and the whole thing pop out in a 'table viewer'. Or the browser could use a tool tip, and ghost the headers on scroll or something.
If I want a fixed header on a table. Couldn't I just fix the body height on the tbody, and use an overflow: scroll, to achieve the same effect? or am I missing something?
Forgive me as I'm still unsure as to what position:sticky actually means. Is it to keep the headings on screen?
I'm wondering if, from UX perspective, in most cases it would be sufficient to draw the headers based on the mouse position. If the user hovers the mouse over a row in the able that causes the headers to pop-over one (or more) rows above the mouse position in a tool-tip like fashion (correctly aligned with the columns, of course).
This type of broken experience compared with what is possible in native applications is what makes me always take native projects over web ones, when given the choice.
This will be really awesome. For anyone who hasn't tried to implement a Sticky element before, it's actually not as trivial as you might think. (And when I was looking for an existing implementation, they didn't support the "constrain" effect that is explained in the video.
To do it correctly, you need to track the up to 4 different element positions.
You've got your actual sticky element, then you've got the parent of the element to ensure it's within the view port. Then you've got the scroll container as well. Plus, you might have a constrain/target node, to ensure that the sticky element doesn't extend passed an artificial bounding box.
Overall, doing all of these domGeometry/position calculations on each window.onscroll event leads to extremely inefficient JS. I ended up removing the Sticky altogether because on iOS it would basically make my application unusable.
Here was my implementation[1]. It was considerably harder to created than I expected it would be... coding advice/tips welcome.
My two cents. You'll never be able to match the scroll smoothly listening for scroll events. Use requestAnimationFrame and listen for changes in window.scrollTop.
Amen to it being harder to _get right_ than first appears...
I've been working on a floating/sticky scroll solution over the last couple of days and decided to go with fixed positioning to try and lessen the CPU load. Dealing with all the edge cases and trying to keep the code as sane as possible has been a complete bitch. Off loading all that to the browser would be a godsend.
I believe the problem with iOS (unless my info is outdated) is that it doesn't listen to the scroll event until it's completed. so sticky stuff won't move until the user has finished scrolling and lifted their finger from the screen.
I am a both sad and happy that it may be obsolete soon. Maybe I can add feature detection for this and short-circuit 1000 lines of logic if sticky position exists.
It's already implemented in Chrome (behind a flag, but it is there), and thereby soon in Opera. Perhaps even Safari. As for IE, yeah, you are going to have to resort to alternative solutions.
Then again, if implemented properly, the lack of sticky positioning should not break the usability, only enhance it whenever present.
Can someone explain what 'Position: sticky' is please?
As I'm having difficulty accessing the video:
(I still seem to have lots of issues trying to watch videos in the browser. Even embedded Vimeo never works for me (Chrome/Debian/Linux), seems flash video is the only thing that consistantly works).
It looks like it pins an element in a fixed position when it normal position has scrolled off the screen as long as it's parent container is visible on screen. It displaying it inline as normal when its position is visible onscreen.
It can be used to make sticky-headers like iOS lists have: e.g. showing the letter of the alphabet at the top of the screen when scrolling through an address book .
It will be really useful for keeping the row titles visible in a long scrolling table.
As always, its a good idea if used correctly. Often, sticky headers are used and cover half the screen on small devices. Use it only if it actually helps usability!
I hope this improves performance when scrolling on iOS etc. It's currently almost impossible to get that right using javascript, because it's all hardware accelerated and scroll events don't fire reliably.
Many web sites have elements that alternate between being in-flow and
being position:fixed, depending on the user's scroll position. This is
often done for elements in a sidebar that the page author desires to be
always available as the user scrolls, but which slot into a space on the
page when scrolled to the top. It can also be done for table headers
which remain visible after the top of the table has been scrolled off-
screen.
Lots of sites, such as news.google.com (the "Top Stories" sidebar) and
yelp.com (the search results map), use scroll event listeners in
JavaScript to achive this effect. However, browsers are increasingly
moving towards scrolling implementations that make use of hardware
acceleration to improve performance, for example by leveraging the GPU,
and doing scrolling on a thread other than the main UI thread.
In this situation, browsers may use fast scrolling but fire scroll
events asynchronously, which will result in rendering glitches on pages
that update element positions from JavaScript via scroll events.
Alternatively, the browser may fall into a slow scrolling mode when
scroll events are listened for; this impacts the perceived quality of
the browser's scrolling. To address this problem, common scrolling
behaviors like this should be exposed declaratively, through CSS.
I am not sure I like how CSS gets bloated with special case behaviors like this. Sticky headers seem to me like animated gifs - something that is hugely popular for several years and then goes away silently because it is more eye candy than useful.
That would be a fair argument if people weren't already building slower and massively more hacky solutions in Javascript. So clearly there is a demand for this 'special case' because people are already building workarounds. Sadly those workarounds will never be a smooth as browser-supported CSS property. Thus I think it makes a lot of sense to include this at the browser level.
And while you're right that, like any CSS property or HTML tag, there's the possibility of abuse, this particular property does have some genuine usability gains (table headings being a great example). So it seems silly to discourage the addition of sticky based on a vague fear of CSS becoming bloated and the potential of few evil sites over using it.
Sticky has more uses than just headers, for instance sidebars and other sorts of control panels can make use of it to improve usability as well. It's a usability feature, not a fad design feature.
I agree. The CSS standard seems like a giant hack job. Which I suppose is generally the case for non turing languages that have to stay relevant in a changing world.
It's neat and useful but having text sometimes scroll under other text is going to be disorienting for some.
Personally, though I like that it will be an option, I don't want it in my pages. For documentation it just gets in the way of other text to read. Headers are a marker and starting context- they don't need to continue to be displayed.
This seems like a very good idea, provided that the implementation makes sense. The current approach of using javascript to watch for scroll-offset is a bit clunky.
I'd like to see this for footers; have the footer at the bottom of the browser if the content is too small, or the bottom of the webpage if the content is large enough for the user to scroll. After skimming the video, I'm not sure if this would be possible with "position: sticky".
Thank you CSS, another way to keep ads and "social buttons" always in front of me. I want a browser addon that hides all position:fixed and position:sticky elements unconditionally, never seen a site that wouldn't be improved by that.
I guess it would be nice to add sticky attribute for "smart hide" of sticky things, like show them when you scroll up a bit, but hide when you scroll down, just as recent Chrome started doing.
I utterly loathe this feature in Android Chrome. My constant instinct is to pull down the status bar like you pull down the notifications and quick-menu. Scrolling up to see it screws me up.
This is especially huge for mobile web where the scroll event isn't fired until after scroll finishes and utilizing touch events leads to a pretty hacky and choppy solution. Bravo.
[+] [-] mbrock|12 years ago|reply
We've spent a lot of time implementing this ourselves for a data table containing lab analysis values. It's a big requirement from our customers. You can imagine it's pretty important to be able to match rows and columns (sample types and dates) correctly when you're looking at these values.
The planning meeting about this was pretty funny.
Boss: "So, we'll just make the headers fixed, should be easy, right?"
Developer: "Heh-heh... Yeah, we could probably get that working decently in just a couple of weeks. We'll have to test it in all the browsers, of course, and do performance tests with big data sets. It's possible that we might not be able to get it to work well enough on all platforms, so we should have a backup plan."
Boss: "Sigh. This would be so much easier in Visual Basic..."
[+] [-] tluyben2|12 years ago|reply
[+] [-] inthewind|12 years ago|reply
If I want a fixed header on a table. Couldn't I just fix the body height on the tbody, and use an overflow: scroll, to achieve the same effect? or am I missing something?
Forgive me as I'm still unsure as to what position:sticky actually means. Is it to keep the headings on screen?
[+] [-] Amadou|12 years ago|reply
[+] [-] pjmlp|12 years ago|reply
[+] [-] chrisacky|12 years ago|reply
To do it correctly, you need to track the up to 4 different element positions.
You've got your actual sticky element, then you've got the parent of the element to ensure it's within the view port. Then you've got the scroll container as well. Plus, you might have a constrain/target node, to ensure that the sticky element doesn't extend passed an artificial bounding box.
Overall, doing all of these domGeometry/position calculations on each window.onscroll event leads to extremely inefficient JS. I ended up removing the Sticky altogether because on iOS it would basically make my application unusable.
Here was my implementation[1]. It was considerably harder to created than I expected it would be... coding advice/tips welcome.
[1] : https://gist.github.com/Kalyse/6534936 (My personal Sticky implementation using Dojo).
[+] [-] yuchi|12 years ago|reply
[+] [-] corford|12 years ago|reply
I've been working on a floating/sticky scroll solution over the last couple of days and decided to go with fixed positioning to try and lessen the CPU load. Dealing with all the edge cases and trying to keep the code as sane as possible has been a complete bitch. Off loading all that to the browser would be a godsend.
It's still a work in progress but this is what I have so far: http://pastebin.com/PWCCERXk
[+] [-] dabernathy89|12 years ago|reply
[+] [-] mkoryak|12 years ago|reply
http://mkoryak.github.io/floatThead/
I am a both sad and happy that it may be obsolete soon. Maybe I can add feature detection for this and short-circuit 1000 lines of logic if sticky position exists.
[+] [-] anon1385|12 years ago|reply
[+] [-] kartoffelmos|12 years ago|reply
Then again, if implemented properly, the lack of sticky positioning should not break the usability, only enhance it whenever present.
[+] [-] inthewind|12 years ago|reply
As I'm having difficulty accessing the video:
(I still seem to have lots of issues trying to watch videos in the browser. Even embedded Vimeo never works for me (Chrome/Debian/Linux), seems flash video is the only thing that consistantly works).
[+] [-] sambeau|12 years ago|reply
It can be used to make sticky-headers like iOS lists have: e.g. showing the letter of the alphabet at the top of the screen when scrolling through an address book .
It will be really useful for keeping the row titles visible in a long scrolling table.
[+] [-] GhotiFish|12 years ago|reply
That should download the file directly, and you can watch it in a native player.
[+] [-] skeletonjelly|12 years ago|reply
[+] [-] yaix|12 years ago|reply
[+] [-] micheljansen|12 years ago|reply
[+] [-] panic|12 years ago|reply
Many web sites have elements that alternate between being in-flow and being position:fixed, depending on the user's scroll position. This is often done for elements in a sidebar that the page author desires to be always available as the user scrolls, but which slot into a space on the page when scrolled to the top. It can also be done for table headers which remain visible after the top of the table has been scrolled off- screen.
Lots of sites, such as news.google.com (the "Top Stories" sidebar) and yelp.com (the search results map), use scroll event listeners in JavaScript to achive this effect. However, browsers are increasingly moving towards scrolling implementations that make use of hardware acceleration to improve performance, for example by leveraging the GPU, and doing scrolling on a thread other than the main UI thread.
In this situation, browsers may use fast scrolling but fire scroll events asynchronously, which will result in rendering glitches on pages that update element positions from JavaScript via scroll events. Alternatively, the browser may fall into a slow scrolling mode when scroll events are listened for; this impacts the perceived quality of the browser's scrolling. To address this problem, common scrolling behaviors like this should be exposed declaratively, through CSS.
[+] [-] iSnow|12 years ago|reply
[+] [-] laumars|12 years ago|reply
And while you're right that, like any CSS property or HTML tag, there's the possibility of abuse, this particular property does have some genuine usability gains (table headings being a great example). So it seems silly to discourage the addition of sticky based on a vague fear of CSS becoming bloated and the potential of few evil sites over using it.
[+] [-] axefrog|12 years ago|reply
[+] [-] GhotiFish|12 years ago|reply
[+] [-] Shish2k|12 years ago|reply
[+] [-] blakeshall|12 years ago|reply
[+] [-] panic|12 years ago|reply
[+] [-] educating|12 years ago|reply
Personally, though I like that it will be an option, I don't want it in my pages. For documentation it just gets in the way of other text to read. Headers are a marker and starting context- they don't need to continue to be displayed.
[+] [-] troels|12 years ago|reply
[+] [-] syzo|12 years ago|reply
[+] [-] 6cxs2hd6|12 years ago|reply
e.g. You have a table and you want the header row(s) to be fixed, but _also_ footer row(s) with totals.
[+] [-] cousin_it|12 years ago|reply
[+] [-] k_bx|12 years ago|reply
[+] [-] Pxtl|12 years ago|reply
[+] [-] stoodder|12 years ago|reply
[+] [-] ananth99|12 years ago|reply
[+] [-] tyilo|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] anaran|12 years ago|reply
They don't seem to be interested in feedback on that site though.
{position: sticky} will definitely be a great feature to have.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] wildster|12 years ago|reply