Nearly every solution for this I have seen or implemented uses a combination of 2 divs with tables inside to work the scrolling.
Yes, we use a variation of that theme as well.
It works to a useful degree, as long as you have enough control over the dimensions that you don't wind up with the row heights differing between the row headers table and the data rows table.
Of course the mark-up is semantically poor, but then HTML's enforced columns-inside-rows nesting for tables is already horrible to work with if you want to show a data record per column and use the row labels for the fields rather than vice versa, making any sort of templating system fragile as well. Rather like floats, this is one of those areas where no amount of CSS tweaks can now make up for underlying weaknesses in the spec of HTML itself.
Tables just aren't built to do that well in my opinion.
We could do better than what we have, though. Hopefully we will before too long, if position:sticky becomes standardised, complete with the notes about making it work properly in a tabular context where some other positioning explicitly isn't required to.
I'm not sure how effectively we'll be able to write a comprehensive polyfill without resorting to JS, so maybe we'll have to settle for gracefully degrading to having the entire table scroll without locking the row headers in place. At least the table mark-up will be more sensible than having two completely separate table elements with some sort of wrapper(s).
Yes, we use a variation of that theme as well.
It works to a useful degree, as long as you have enough control over the dimensions that you don't wind up with the row heights differing between the row headers table and the data rows table.
Of course the mark-up is semantically poor, but then HTML's enforced columns-inside-rows nesting for tables is already horrible to work with if you want to show a data record per column and use the row labels for the fields rather than vice versa, making any sort of templating system fragile as well. Rather like floats, this is one of those areas where no amount of CSS tweaks can now make up for underlying weaknesses in the spec of HTML itself.
Tables just aren't built to do that well in my opinion.
We could do better than what we have, though. Hopefully we will before too long, if position:sticky becomes standardised, complete with the notes about making it work properly in a tabular context where some other positioning explicitly isn't required to.
I'm not sure how effectively we'll be able to write a comprehensive polyfill without resorting to JS, so maybe we'll have to settle for gracefully degrading to having the entire table scroll without locking the row headers in place. At least the table mark-up will be more sensible than having two completely separate table elements with some sort of wrapper(s).