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.
Comment | File | Size | Author |
---|---|---|---|
#11 | views-style.png | 11.98 KB | Rob230 |
#6 | views-table_fields-1368436-6.patch | 1.44 KB | Ronino |
Comments
Comment #1
dawehnerThat'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.
Comment #2
dasjoso 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
what i would expect is
so that the "Create a CSS class" setting applies directly for the "Customize field HTML" div as the configuration interface suggests
Comment #3
dawehnerAn 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.
Comment #4
markabur CreditAttribution: markabur commentedJust 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.
Comment #5
bredi CreditAttribution: bredi commentedWorkarounds?
Comment #6
Ronino CreditAttribution: Ronino commentedThis is exactly the output I expect. The attached patch fixes this.
Comment #7
dawehnerChanging 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
Comment #8
Ronino CreditAttribution: Ronino commentedWell, 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 ;-).
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.
Comment #9
pascalduez CreditAttribution: pascalduez commentedHi,
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:
I guess #1122130: Field + Wrapper class/element meaningless with table style is also related.
Comment #10
markabur CreditAttribution: markabur commentedI 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.:
That way if you're depending on the old broken behavior you could target
.field1{ }
ortd.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.
Comment #11
Rob230 CreditAttribution: Rob230 commentedJust ran into this problem myself. I certainly would expect that when I specify a class that it gets added. For 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.
Comment #12
Renee S CreditAttribution: Renee S commentedMy vote is for the fix suggested by @markabur - breaks nothing old, but also introduces the expected behaviour.
Comment #13
Ronino CreditAttribution: Ronino commentedmarkabur wrote:
Renee S wrote:
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?
Comment #14
markabur CreditAttribution: markabur commentedThere 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.
Comment #15
gihalu CreditAttribution: gihalu commentedAny resolutions to this issue yet?
Comment #16
radziaziz CreditAttribution: radziaziz commentedSubscribe
Comment #17
hilrap CreditAttribution: hilrap commentedsubscribe
Comment #18
chillwalker CreditAttribution: chillwalker commented6: views-table_fields-1368436-6.patch queued for re-testing.
Comment #19
Maks CreditAttribution: Maks commented#6 worked on 7.x-3.8
Comment #20
sdsheridan+1 for getting this change in to views. This is the way the UI implies it should work.
Shawn
Comment #21
nithinkolekar CreditAttribution: nithinkolekar commentedalso added related
Comment #22
le72Patch #6 works for me. Please add to the module.
Comment #23
DamienMcKennaCould someone please write a change notice for this?
Comment #24
andres.torres CreditAttribution: andres.torres commentedis this going to be ported to D8? i find the same issue on a Drupal 8 basic calendar view.
Comment #25
joelpittetYou’re welcome to port the changes to d8. Have a search to see if it’s not already in the queue.
@andrestorres
Comment #27
djg_tram CreditAttribution: djg_tram as a volunteer commented@andres.torres: use the next fieldset, Rewrite output to specify your own HTML tag and class. It works.