tableheader.js is always applied in theme_table()

I have needed this in the past. I like the implementation.

+1 for getting this implemented.

Personally, I'm not a big fan of using the $attributes array for this: IMHO, the $attributes array is just a bunch of attributes that need to be passed through to the tag being rendered, and the theme function(s) should not use elements of the array in any kind of logic. I couldn't find a similar use of the $attributes array in theme.inc. I also find it counter-intuitive to have to add a class in order to remove functionality.

Is it an option to change the function signature to something like:

function theme_table($header, $rows, $attributes = array(), $caption = NULL, $colgroups = array(), $sticky = TRUE) {

...or would that make the signature overly long?

also this brings up the point that there's no simpletest for checking misc/tableheader.js - is that something we want to do?

I'd say yes. If this functionality is added, we should also add a test for it.

Also, I'm not sure that this is a bug, it feels more like a feature request to me.

+1 to a parameter and not using the attributes hack. We can at least make a basic test that if $sticky = FALSE, there is no instance of 'tableheader.js' in the page request source code with a table.

And I'd like to point out that the norm is to have sticky headers, and the *rare* abnormality would be to turn them off for a table that's being generated by a custom module or something. I certainly don't like the presence of a sixth param for theme_table, but it seems to me that having it default to true would mean that 98+ percent of the population would go happily along their merry way, never needing or calling the function with that last parameter.

The remaining 1+ percent of us who need to turn off sticky headers would then have the option to do so, and if you did need to for some reason, how many times would you have to write a sticky-less theme_table() function in a single site or module? Once?

Karl, let's go with the additional param on this one. I've looked into the simpletests for this, and having to test for the presence of and absence of a 'sticky-enabled', 'sticky-disabled', and so on is far uglier that checking for the presence of $sticky_header = TRUE or $sticky_header = FALSE.

AND THEN! There's the current Designer Themer push (#D4D) that is trying to remove all un-necessary CSS classes from core, and this patch as it stands would require developers to pass a "useless" CSS class all the way through to the browser just to remove a usability feature for one HTML table. Ungood?

cleaning up issue tags

Hi,

I'm running 6.13 with the fix mentioned in this thread, however it seems that the sticky-header (or some side-effect of it) is still being applied, even if I disable it via:

theme_table(blah, blah, array('class' => 'sticky-disabled'));

Should the code in "theme.inc" be something like this:

    $attributes['class'] = empty($attributes['class']) ? 'sticky-enabled' : ($attributes['class']);

instead of this:

    $attributes['class'] = empty($attributes['class']) ? 'sticky-enabled' : ($attributes['class'] .' sticky-enabled');

I need to do more investigation, but I have more details at the following location in case anyone has any insight: http://drupal.org/node/577596

Regards

#5: drupal-415024_2.patch queued for re-testing.