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.

Files: 
CommentFileSizeAuthor
#11 views-style.png11.98 KBRob230
#6 views-table_fields-1368436-6.patch1.44 KBRonino
PASSED: [[SimpleTest]]: [MySQL] 1,472 pass(es).
[ View ]

Comments

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.

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

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.

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.

Workarounds?

Component:Code» table style
Status:Active» Needs review
StatusFileSize
new1.44 KB
PASSED: [[SimpleTest]]: [MySQL] 1,472 pass(es).
[ View ]

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.

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

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.

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.

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.

StatusFileSize
new11.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.

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

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?

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.

Any resolutions to this issue yet?

Subscribe

subscribe