when the script was written it only addressed the tables used in the core and to the best of my knowledge none of those have tfooter or colspan. As the script is something that a developer has to include (its not automatic) probably no one saw this as a problem.

As you have a fix for the tfooter part then please submit a pull request with those changes.

Thank you Brian. I don't actually have a working fix yet, so far I simply looked in the source to see what was going wrong - it looks like it should be straightforward - just repeat everything done for the header with the footer if it exists and has the same column count - there will, however, be a nasty case where the footer uses colspans (as I have seen done in some extensions and example code) which will have to do something different which might be quite tricky.

Personally I rarely (never) use colspans - generally I use the footer to repeat the header rows if the number of rows might be bigger than will fit on the screen, so there is always the same count of visible columns. (yes I know I could simply make the header row sticky which would be a better solution in this case)

So my solution would ignore this case, which would perhaps be bad for some people. I guess one could simply check for colspans in the footer - or in fact anywhere in the table, as colspans anywhere would likely break the,table.columns code - and simply disable the table.columns script if they were found. Would that be acceptable?

However now comes the rub, as I've been here before - I have never successfully submitted a pull request for Joomla as I have never been able to understand how to run the test required and I'm not about to change my personal quirky development routines in order to accommodate them - life is too short.

So I am not actually able to submit a pull request once I have it working anyway. I need someone who understands the way of the Joomla to take my code and sprinkle the secret magic testing dust over it. This has been my problem since I wrote my first module for J1.5 (I actually started with 1.0.11, and even briefly tried Mambo before that).

If anyone would like to take it on after I have my version working then that would be great. Since footers are never used in core tables I guess it wont matter to most people, and I'll simply bundle my corrected version of table.columns with my components as required. Same as happened with the bugs in string.truncate which have never been fixed in the core (and are still there in j5)

I've also just noticed that it (table.columns) doesn't work if you are using <colgroup> to set column widths and styles. So that will need dealing with too.
Since this is the neatest way (for me) of setting which columns should show or hide on mobile and how the widths should be distributed and any whole column styles required then its a bit of a show-stopper for using table.columns.

My gut feeling here is to say that this is a "wont fix"
It works perfectly with the core implementation of tables.
It has to be optionaly added by extensions if they want to use it
Even if someone made the pull request for you for your code you still would not use it as it doesnt address other non-core wierd cases.

Having said that if someone was to contribute the code that satisfies your need I would be happy to test it.

This is a Feature Request

Yes I agree Brian. Leave as is and possibly look to add a note somewhere in the documentation that table.columns will not work with tables that have a <tfoot >, <colspan >, or ,<colgroup > elements.

For my own purposes I can adapt the code to work with what I use, and other extension devs can do the same. I'll post whatever I do and link to it here in case someone else stumbles across this problem and can make use of it.

I'll leave this open for now to make it easier for others to find. it needs to be tagged as a feature request not a bug

Did you ever manage to adapt the code?

Short answer "No"
Short reason: I no longer find it necessary as I've changed the way I use tables.

I made a start with getting it to work with <tfoot> elements which is the simplest case as it just involves replicating what it does for <thead> with <tfoot>. But the thing I really wanted was to have it work with <colgroup> which is more complicated. (<colspan> is really really tricky but I don't use that myself, and is probably impossible to fix to work with table.columns.js except on a case by case basis.).

In my components I was using <tfoot> to replicate the header so that if the user scrolls down to the bottom of the table she still has visibility of the column titles even if the header has scrolled off the top.

I also use <colgroup> as a much cleaner way of setting classes and styles across the whole table rather than sprinkling them around both header and individual <td>s.

Since I've started migrating my components to j5 (a long slow process since I am also generating a couple of new ones which take priority) I have decided to switch to using javascript to freeze the header row of the table in position, and just scroll the rows below it so that the header always remains on the screen (as does the columns tool). Thus I no longer need to have a footer for my tables.

The inability to use <colgroup> together with table.columns.js is still a nuisance for me and eventually I might be driven to find a solution for that, in which case I would also do the easier tfoot job at the same time.

Stopping the top (header) row of a table scrolling is quite easy and I'd recommend considering implementing it for some of the core components as it certainly enhances the usability (in my opinion).

So the question then is if this should stay open?

While my gut feeling is that it should stay open because although the core components are not (currently) affected it is a constraint on using a useful facility (table.columns.js) it will stay hanging around until someone else falls into it.

I'm not going to fix it yet awhile, and no-one else has commented. I suspect the more commercial component developers will simply work around it rather than spend time fixing it, and so until some other enthusiast finds it a problem nothing will happen.

I would take advice from the grown-ups as to whether this sort of thing should be left open indefinitely, or closed and quietly forgotten about. I can't yet see anywhere obvious in the manual.joomla.org to document it as an issue. Happy to close it if you wish.

Suggest moving to discussions but can't see how to do that - perhaps a github admin function? @brianteeman

@rdeutz please move this to discussion as requested