hi,

i'm using a table view, where two fields share the same column.
on both "embedded" fields i use "Customize field HTML" with "Create a CSS class" to identify those two fields within the column.

i would expect the two fields to be identified by the specified css classes. what happens is, that the css class of the "master" field will be applied to the table cell. the "embedded" field's assigned css class doesn't appear in the output.

maybe this is the expected behavior? from an end-user-perspective this is a bit irritating.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dawehner’s picture

That's not really the intended behavior, but the table style doesn't have the idea that there might be css classes from all fields grouped together. I was sure that there is another issue in the queue but i can't find one.

It's indeed a good question what it should do but i guess it should get the classes from both fields.

dasjo’s picture

so the configuration is
field 1 ("Customize field HTML": div, "Create a CSS class": field1)
field 2 (in field 1 column, "Customize field HTML": div, "Create a CSS class": field2)

the output looks something like this

<td class="views-field views-field-title field1">
  <div>field 1</div>
  <div>field 2</div>          
</td>

what i would expect is

<td class="views-field views-field-title">
  <div class="field1">field 1</div>
  <div class="field2">field 2</div>          
</td>

so that the "Create a CSS class" setting applies directly for the "Customize field HTML" div as the configuration interface suggests

dawehner’s picture

An issue about the merged column css i mentioned in #1 #1290698: Table format: merged columns lose field wrappers

About the behavior, this was intended by earl, ... sadly this is also documented in another issue but i can't find it as well, maybe i will be able to find it as well :)

Thanks btw. for such bug reports, easy to understand but maybe hard to fix.

markabur’s picture

Just noticed this. Weird, if the intended behavior is to discard the css classes I've taken the time to enter in the UI. For now I what I'm doing is using different wrapper tags in order to style the fields within the cell. E.g. h3 for field 1, div for field 2, p for field 3, etc.

bredi’s picture

Workarounds?

Ronino’s picture

Component: Code » table style
Status: Active » Needs review
FileSize
1.44 KB

so the configuration is
field 1 ("Customize field HTML": div, "Create a CSS class": field1)
field 2 (in field 1 column, "Customize field HTML": div, "Create a CSS class": field2)

the output looks something like this

<td class="views-field views-field-title field1">
  <div>field 1</div>
  <div>field 2</div>          
</td>

what i would expect is

<td class="views-field views-field-title">
  <div class="field1">field 1</div>
  <div class="field2">field 2</div>          
</td>

so that the "Create a CSS class" setting applies directly for the "Customize field HTML" div as the configuration interface suggests

This is exactly the output I expect. The attached patch fixes this.

dawehner’s picture

Changing css classes NOW is somehow a no-go because a lot of possible CSS might break.
At least the behavior has to be configurable.

Merlinofchaos explained something on http://drupal.org/node/1122130#comment-4334402

Ronino’s picture

Changing css classes NOW is somehow a no-go because a lot of possible CSS might break.
At least the behavior has to be configurable.

Well, the problem is that the current behavior is not what the configuration implies and there is no other way to achieve the expected result. The only thing that changes for existing CSS is the misplaced class that gets moved to the correct position. As the views-field-title class in the above example is already unique for that td, I cannot imagine that too many CSS masters rely on that field1 class. The number of people wondering why it doesn't work as described should be far higher ;-).

Merlinofchaos explained something on http://drupal.org/node/1122130#comment-4334402

As I see it, merlinofchaos refers to the 3rd style setting, now called "Customize field and label wrapper HTML" whereas this issue deals with the 1st which is "Customize field HTML" and should be the only one of the first three settings which applies for the table style.

pascalduez’s picture

Hi,

I'm right in the middle of the same situation. Four fields needs to be in the same `td`, and it's not possible to output classes on each of them. The class will be applied on the `td` itself.

From views-view-table template:

<td <?php if ($field_classes[$field][$row_count]) { print 'class="'. $field_classes[$field][$row_count] . '" '; } ?><?php print drupal_attributes($field_attributes[$field][$row_count]); ?>>
    <?php print $content; ?>
</td>



I guess #1122130: Field + Wrapper class/element meaningless with table style is also related.

markabur’s picture

I agree with #8 -- fixing this is unlikely to actually break any real-world css. If you have explicitly added ".field1" via the UI for a particular field, then you discover like the rest of us that the class gets applied to the wrapping td rather than the field itself, you probably will not subsequently use that class to affect everything in the div (otherwise you wouldn't have created the special class in the first place).

But at the very least the ".field1" field-specific class could be repeated inside of the td, e.g.:

<td class="views-field views-field-title field1 field2">
  <div class="field1">field 1</div>
  <div class="field2">field 2</div>          
</td>

That way if you're depending on the old broken behavior you could target

.field1{ } or td.field1{ }

to affect everything in the td, and if you need to style the fields independently you can use

td .field1{ }

to target a particular field inside the td.

Rob230’s picture

FileSize
11.98 KB

Just ran into this problem myself. I certainly would expect that when I specify a class that it gets added. For example:

example

I would expect to get <span class="myclass">field value</span>.

Instead I get <span>field value</span>.

For the class you specify to be completely ignored seems like a bug. It does not appear on the table cell or the label (table header cell), it's just completely ignored unless it is the first field of that column, in which case the class is applied to the table cell.

If you are worried about breaking CSS in existing sites I would certainly consider making this change for the next major version, or have an option for both (apply the class to the table cell and/or to the field element). Applying the class to the field element is what the UI says it will do, but it does not.

Renee S’s picture

My vote is for the fix suggested by @markabur - breaks nothing old, but also introduces the expected behaviour.

Ronino’s picture

markabur wrote:

But at the very least the ".field1" field-specific class could be repeated inside of the td, e.g.:

<td class="views-field views-field-title field1 field2">
  <div class="field1">field 1</div>
  <div class="field2">field 2</div>          
</td>

That way if you're depending on the old broken behavior you could target

.field1{ } or td.field1{ }

to affect everything in the td, and if you need to style the fields independently you can use

td .field1{ }

to target a particular field inside the td.

Renee S wrote:

My vote is for the fix suggested by @markabur - breaks nothing old, but also introduces the expected behaviour.

I think repeating the classes will break certain pages. Those for which the CSS selectors simply use the classes: .field1 {...} and .field2 {...} will be applied to both the td and the div and thus likely break the layout. And if you need to adapt the CSS in those cases, why not do it right and fix it to do it like the UI says, i.e. set the classes for the divs only?

markabur’s picture

I think repeating the classes will break certain pages. Those for which the CSS selectors simply use the classes: .field1 {...} and .field2 {...} will be applied to both the td and the div and thus likely break the layout.

There is a possibility that the layout could change, but *only* if your design use the field-specific custom class to affect the entire td. I just think it's really unlikely that anyone would use those classes that way. If you created the class with the intention of using it for one field only, you would not use it at all when you learned it wouldn't work that way.

When I ran into this problem, I needed to stylize the fields within the td differently from one another. I created special classes for each field, but then I discovered that those classes were applied to the wrapping td instead of the spans inside of it, so the classes were useless and I switched to using different tags for each field instead.

So in my case, fixing the problem would not break anything since I didn't use the custom classes at all after discovering the bug. I am guessing that most, if not all, themers are in the same boat: the custom class setting is non-helpful in table displays, so they don't use it. Therefore any fix now is unlikely to hurt them.

gihalu’s picture

Any resolutions to this issue yet?

radziaziz’s picture

Subscribe

hilrap’s picture

subscribe

chillwalker’s picture

Maks’s picture

Issue summary: View changes

#6 worked on 7.x-3.8

sdsheridan’s picture

+1 for getting this change in to views. This is the way the UI implies it should work.

Shawn

nithinkolekar’s picture

also added related

le72’s picture

Patch #6 works for me. Please add to the module.

DamienMcKenna’s picture

Issue tags: +Needs change record

Could someone please write a change notice for this?

andres.torres’s picture

is this going to be ported to D8? i find the same issue on a Drupal 8 basic calendar view.

joelpittet’s picture

You’re welcome to port the changes to d8. Have a search to see if it’s not already in the queue.

@andrestorres

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 6: views-table_fields-1368436-6.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

djg_tram’s picture

@andres.torres: use the next fieldset, Rewrite output to specify your own HTML tag and class. It works.