
H2 {position: sticky} [video] - izietto
https://air.mozilla.org/intern-presentation-ford
======
mbrock
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..."

~~~
inthewind
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?

~~~
mbrock
Setting an absolute position on the THEAD works (except, I think, in old IE),
but only with fixed column widths. The usual hack involves using JavaScript to
keep the columns in sync.

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.

------
chrisacky
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.

[1] :
[https://gist.github.com/Kalyse/6534936](https://gist.github.com/Kalyse/6534936)
(My personal Sticky implementation using Dojo).

~~~
dabernathy89
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.

~~~
talmand
I ran into that problem with a project not too long ago. It wasn't for
something sticky though; a modal with video would dock itself to the bottom of
the page on scroll to allow for content viewing but having the modal still
visible.

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.

~~~
codingninja
To mitigate this, simply bind to the "touchmove" and "touchstart" events as
well.

~~~
talmand
Wouldn't that bind the functionality to user interaction beyond just
scrolling?

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.

------
anon1385
Great job guys, it only took 11 years (plus however long it takes to get this
into IE/Chrome/Opera…) to finally solve the problem of table headers in CSS:
[http://lists.w3.org/Archives/Public/www-
style/2002May/0153.h...](http://lists.w3.org/Archives/Public/www-
style/2002May/0153.html)

~~~
kartoffelmos
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.

~~~
hober
Chrome (really Blink)'s implementation was inherited from Safari's
implementation from before Blink forked from WebKit.

------
inthewind
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).

~~~
sambeau

      {position: sticky}
    

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.

~~~
inthewind
I've seen this kind of behaviour on a few sites. I thought it was achieved by
having the position fixed on the element, as soon as JS detected that the
element was moving out of the document window.

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?

~~~
etherealG
i think the correct fix for this is for the browser to realise that some of
the height is obscured by position:fixed elements, and only scroll the rest of
the height on a page-down keypress. a javascript version of the same wouldn't
be possible, so yes, this can help. whether it's implemented like that yet i'm
not sure, perhaps open a bug with webkit / gecko if not.

~~~
asadotzler
Firefox already does this and has for some time.

~~~
inthewind
Really? Not for me, and I' m on Nightly. Perhaps we are talking about
different things.

[http://pastebin.com/5eDi9WDW](http://pastebin.com/5eDi9WDW)

------
yaix
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!

------
micheljansen
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.

~~~
panic
It does! In fact, this is the reason sticky positioning exists. See the
original proposal at [http://lists.w3.org/Archives/Public/www-
style/2012Jun/0627.h...](http://lists.w3.org/Archives/Public/www-
style/2012Jun/0627.html):

 _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
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.

~~~
axefrog
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.

~~~
mordae
You mean like in the bootstrap documentation, where with a small enough
viewport you cannot access bottom of the menu?

~~~
jasonlotito
That's a failure of the implementation, not a failure of the concept. Having
dealt with implementing things like that in the past, I can't offer an excuse
other than laziness for those implementations. However, it doesn't take away
from the concept.

------
blakeshall
I'm surprised no one has said anything about the intern. Decent presentation
and solid work. Good on him.

------
panic
This has been available on iOS since iOS 6. I'm surprised more people don't
know about it!

~~~
educating
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.

------
troels
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.

------
syzo
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".

------
6cxs2hd6
I understand this works for sticky headers. Footers, too?

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
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.

------
k_bx
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.

~~~
Pxtl
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.

------
stoodder
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.

------
ananth99
It'd be awesome if this is possible for a horizontal setup too!

~~~
tyilo
It is. The intern said that in the video.

~~~
ananth99
Ohh I see. Guess I missed it. :)

------
anaran
That was a very good presentation.

They don't seem to be interested in feedback on that site though.

{position: sticky} will definitely be a great feature to have.

------
wildster
If everyone is using hacks like Bootstrap it makes sense to incorporate more
of it into CSS.

------
nkerkin
Will this support horizontal scrolling also, e.g. freeze a table column?

~~~
tyilo
yes, he says so in the video.

------
dep_b
How about some usable centering of blocks instead?

------
Yaggo
Great feature. Also landed on webkit.

~~~
makepanic
`position: sticky` was working in Chrome(ium) a while ago but somehow the
removed it.

~~~
thomasbachem
Because of this:
[https://code.google.com/p/chromium/issues/detail?id=145027](https://code.google.com/p/chromium/issues/detail?id=145027)

------
edo
This is awesome, great work!

------
altero
Congratulation! Turbo Vision had this only 25 years ago, JS is catching up :-)

~~~
andrew_gardener
correct me if I'm wrong, but isn't the point of this that its CSS and not JS?

------
ryanseys
This is just awesome!

