Table display style places custom field class on table cell rather than field element

I can confirm that this is an issue just with the table display format. Works well with Grid, HTML List and Unformatted list.

From what I could gather, lines 620-622 in views.theme.inc are causing trouble.

      if ($classes = $fields[$field]->elementClasses($num)) {
        $column_reference['attributes']['class'][] = $classes;
      }

These lines seem to explicitly add the class of that element but are adding class to 'td' instead because they are adding the desired class to $column_reference['attributes']['class'] instead. IMO we need to add the class to the specified element instead here.

I'm a newbie so any suggestions are welcome.

Here is a fix for that. Spoke to cs_shadow about this on IRC. They are going to do the some test coverage for this.

This has always been the case by design of earl back in the days.

I still think we should discuss whether we really have to change this feature, ... this certainly was intended in the first place.

Would be nice if we can fix it in Drupal 7 as well. I think the current behaviour is contrary to expectation and not what the UI says it does. It has been kept like it to avoid breaking older sites, but it should be possible to add a class to a field inside a table cell, even if it's in addition to the current ability to add it to the header cell.

Moving this to the right queue.

Looking for a solution to the same problem. In response to #9, this is what I would say:

I have a view setup where I have an "edit" and "view" link grouped into one table column called "actions." Because currently views won't apply the classes to each field, I can't target those individual links for styling. I want the edit link to use a certain background image, and the view link to use a different background. But because the classes are applied to the container, it's not possible to specify which element I'm trying to target.

That's just one basic case. I'm sure others have different uses.

Hrms... Ok, if this goes in, what would be the proper way, through the Views UI, to add a class to the table cell? I've been using the approach described within because I /want/ the class on the cell. If this patch gets in, what's the alternative?

I just ran into the same issue - it makes it very cumbersome to do styling of different information coming from the different fields.

The work-around solution I discovered was to let just one field be shown in the table, but rewrite the output of that field with HTML using replacement patterns referring to the other fields and which assigns the CSS classes I want, e.g.:

<span class="field_title">[title]</span><br/> 
<span class="field_description">[field_cv_description]</span><br/>
<span class="field_extra">[field_extra_note]</span>

(This was the workaround I used on ulriklyngs.com/cv to give different styling for elements in a table listing curriculum vitae items)

Quick fix

The patch allows to set preferences for the html wrapper and the html element. The label wrapper class setting does not work, because label classes add to "th" by default.

I just ran into this with a colleague. The 'solution' from comment 20 sounds like the way to go for site builders, whilst the bug exists.

For us, we found that the classes from the previous column were re-used again for a column, because column.default_classes was set to false (no idea why though, as the 'Add default classes' setting was definitely ticked for the field), which meant that column_classes in the template got carried over from the previous iteration of the loop, rather than being re-initialised/cleared (see the template code here). So not quite the same problem, but the same solution was necessary.

Even if a coded solution was made (whether to adjust where the classes go, or just to avoid that daft re-use of classes from a previous column), I guess it would by definition make for markup changes which might not be wanted for backwards-compatibility?

[Mentoring] + adding GiftofOpenSource tag

Rerolled patch from #27 against Version 9.5x as suggested in #34

The fail at #27 (or #37 as they have the same code) was related to an extra trailing space being added after the elements.
Here you can see the comparison between the outcomes of the second call $this->drupalGet('test-table'); (line 112) inside StyleTableTest::testFieldInColumns() before and after the patch.

You can see that there are extra trailing spaces after the patch was applied, which triggered the error on the test. I hope this new patch solves the issue.

Please ignore. comment added due to network issue. Apologies.

Hello!

I tried to apply patch #40 in Drupal 9.5.x-dev. Patch failed to apply. Attaching the screenshot for error reference.

Moving back to NW. Looks like the test cases weren't added.

This isn't ready for review yet

The last patch nor MR contain a test case. And are failing the existing tests.

Rerolled

We have to use addClass method