H2 {position: sticky} [video]
air.mozilla.org
air.mozilla.org
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 issue of fixed headers is a styling issue, not an issue of what embedding types are supported; and that is solved by the "position: sticky" CSS attribute that this link discusses. There has been an experimental WebKit implementation of this for a while, this now adds an experimental Gecko implementation. Hopefully this will be standardized soon and available in non-experimental form.
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?
The header cells end up being layouted separately from the body cells, and so their widths are not constrained together.
Actually, I'm not sure if sticky positioning is different in this regard... This property might not solve the problem we ran into.
In any case, a sticky header is different from an absolute header, because it doesn't require a separate scrolling container. You just scroll the page, and the header follows along, until the table scrolls out of the viewport.
It's attempting to make something perform in a way it was not designed, nor intended, for. Just because a Honda Civic can't compete in an F1 race doesn't mean the Civic is broken.
It is a broken experience, and a defect in the HTML concept of a "table".
Honestly, we have to stop defending these terrible web technologies we're saddled with. We use them because they're the only universal-standard client application engine.
Not because they're good.
I would think that people who relied on books before computers came along would disagree.
HTML provides for a means to view tabular data and performs that function in a minimal and acceptable manner. People moving the goal posts on the requirements does not mean the current implementation is "broken" nor "defective". It simply does not perform an extra feature that people would like to have today.
I also don't believe I was defending anything, I was simply disagreeing with an unfair criticism against a technology because it wouldn't do what it wasn't designed to do based on current expectations.
The simple fact that HTML/CSS/Javascript allows for it to be extended and expanded shows it is not a defective means of displaying information. It means that there's the occasional lag in updating the specs to meet people's current expectations. Blame the people not keeping the spec up to date with current expectations and not the spec.
Once position:sticky is in common use I suppose we'll wait until the next new expectation of functionality appears that means something is "broken".
HTML/CSS/Javascript is good in many ways, but I agree it is not perfect and it never will be.
I was making applications in VB5 in the late '90s that solved this problem. Expecting it 15ish years later in a platform that includes tabular data as a core feature is not unreasonable.
HTML+CSS+Javascript is a poor general-purpose application development platform and an okay document engine. It is only made usable by the herculean combined effort of the entire 21st century software industry.
Nor did I say that such a feature was unreasonable, I'm just saying that people are complaining about a lack of feature that wasn't built in before the expectations of that feature. People want it and there have been people seriously attempting to implement a solution. But that kind of thing takes time and the problem is it isn't happening in a time table that makes enough people happy. So they complain and toss out unfair criticisms.
Your last bit proves my point, people are attempting to use these technologies in ways they were not designed to do and yet complain about them not being able to do it. You might as well hate your car because it doesn't fly.
Actually I think most in HN disagree with that. In HN taking the native side is a sure way to get downvotes.
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).
Wouldn't your way consume a lot of unnecessary CPU?
Even without this guard, with just the `old !== getScrollTop()` it doesn't eat so much CPU neither.
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
On iPads that docking wouldn't happen until after the scroll had completed instead of at the start of the scroll. I'm not sure if this happens on the latest iOS versions or not though. But it was fun explaining to project managers what was going on during QA.
Analytics shows us that this minor issue with iPads is of little concern. But at least I now have a suggestion for a solution if someone decides it's a big enough deal. Thanks for the tip.
All round, very very irritating.
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.
Then again, if implemented properly, the lack of sticky positioning should not break the usability, only enhance it whenever present.
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).
That should download the file directly, and you can watch it in a native player.
That one is a little too large a video a file size for my tariff, will have to watch later.
{position: sticky}
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.
There's a time and a place for this sort of thing. I personally get a little annoyed with fixed headers as it can break text paging. Text gets hidden under the header. When you hit page-down you get another page worth of text but the fixed element obscures the text.
Can position: sticky help with something like that?
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 know it's different, but the argument here http://dealloc.me/2011/06/24/d3-is-not-a-graphing-library.ht... applies in a similar way.
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.
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.
e.g. You have a table and you want the header row(s) to be fixed, but _also_ footer row(s) with totals.
They don't seem to be interested in feedback on that site though.
{position: sticky} will definitely be a great feature to have.