Problem

Bartik sets a .field__label class only for .field--type-entity-reference and .field--name-field-tags. Instead it should inherit Classy's styling for those selectors as they are. (Currently on the field label of only these two fields, Bartik overrides the font-weight, lateral padding and font-size).

Steps to reproduce the problem

  1. On a Standard install profile content type (e.g. Article), create an entity reference field.
  2. Preserve the existing body field.
  3. Under Manage display of a Content type, set both field labels to display the same way, either Above or Inline.
  4. Create a node and add one word of content to each field.
  5. View the node and note the field labels display different styling.

Expected behavior

All field label(s) use the same styling.

Proposed fix

Remove all calls to the .field__label class from the Bartik css, allowing Bartik to inherit Classy styling on each field label.

Issue fork bartik-2957408

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

kay_v created an issue. See original summary.

leolandotan’s picture

Assigned: Unassigned » leolandotan

I'll look into this work on it.

leolandotan’s picture

Assigned: leolandotan » Unassigned
Status: Active » Needs review
StatusFileSize
new183.56 KB
new450.31 KB
new1.38 KB
new483.64 KB

I have followed the steps to reproduce the issue.

Here are the fields with no CSS changes:
Original Bartik node page

Here are the fields with the CSS changes:
Above label format:
Bartik node page result for above label format
Inline label format:
Bartik node page result for inline label format

Fix

Based on the proposed fix to remove all calls to the .field__label class from the Bartik CSS, I though to retain the other styles like the margin and paddings because I thought that this might be Bartik specific and we just want the labels alone to be "Classy-consistent".

Hope this makes sense and the changes are in order.

Thanks!

kay_v’s picture

Status: Needs review » Needs work

Thanks for your work on this, @leolando.tan. Great to see screenshots showing the issue as well as the outcome of your proposed fix. The images look successful, and the patch looks close!

That said, I believe there is a little more to do, so I'm setting the issue back to 'needs work'. Two reasons come up for me:

  1. it looks like some inconsistency remains in how Bartik treats field labels after applying your patch, and
  2. it looks like your patch may have some unintended effects (e.g. removing attributes from selectors other than .field__label).

For the first item, can you verify your assumption about leaving some field label styling in Bartik? When I first stumbled on this issue, I searched the 8.6.x codebase for .field--type, .field--name and .field__label, thinking that if any field label is overridden in Bartik, all similar field labels should be--and several candidates came up but without any style overrides of any kind. If those search results are accurate, I believe we would not want to leave the overridden margin and padding in place for just a few field labels. We would want to remove those from Bartik, as well, so that Bartik treats all field labels the same way (i.e. as defined by Classy).

For the second item, can you double-check that your patched file has only the intended changes?

Looking forward to getting your reply.

leolandotan’s picture

Assigned: Unassigned » leolandotan

@kay_v, thank you for checking and your feedback!

For #1, it makes sense where you said that we we would not want to leave the overridden margin and padding in place for just a few field labels so that Bartik treats all field labels the same way as the Classy theme. For #2, I'll double check.

Based on #1 also, I think this would mean almost all of these CSS styles for entity reference fields would be removed but I'll confirm this.

kay_v’s picture

Assigned: leolandotan » Unassigned

Hi @leolando.tan -

I hope you won't mind if I unassign this issue! Please feel free to continue/finish work on this issue all the same (I'm cheering you across the finish line in any case!)

DrupalCon is underway. We're pulling together novice issues for this Friday's sprint, and I'll add this issue to the list we're assembling.

benjifisher’s picture

Issue tags: +Nashville2018
woodseowl’s picture

I'm at Nashville sprinting my first time. This looks like something I can pick up and I've reproduced locally, so I'm going to see if I can contribute!

woodseowl’s picture

Issue summary: View changes
StatusFileSize
new86.25 KB
new91.12 KB

I've done some digging into the history of this to see where the entity reference styling first came in.

Per comment #3, it seemed odd that there is styling specific to field labels on entity references. Looking into the commit history on themes/bartik/css/components/field.css lead me to issue where it was introduced: https://www.drupal.org/project/drupal/issues/2214241 (it is very large, see links below to relevant comments).

Comment #338 points out that "the field type for tags and other taxonomy terms is type-entity-reference and not type-taxonomy-term-reference". That may be the root issue and the styling for type-entity-reference obscured it. The styling looks like it was introduced because of the visual regression failure noted in comment #316.

I think this suggests that the visual regression tests should include an entity reference example, because the updates applied in #2214241 would have broken them. It also seems likely that the taxonomy term label needs to be more specific, either just how an inline label is handled or more specifically how the taxonomy term field type is set.

Locally I set up an article that has an entity reference and tags (setting the entity reference to be rendered and showing labels for fields on the rendered entity, as well). I captured images before and after applying the patch in comment #3. I think that the resolution to this issue should not change the visual presentation of the tags label.

Here is a snapshot of the issue reproduced with tags as well as a rendered entity reference:

Here is the same page with the patch applied, where we can see that tags get broken styling:

I am going to discuss the nature of this issue with others in Nashville today before I decide if I can take this further.

woodseowl’s picture

Looking closer, the field.css file has two sections of virtually identical CSS, one being applied against .field--type-entity-reference and another against .field--name-field-tags. If we remove the type-entity-reference styling code in field.css, this appears closer to the intended style.

Adding a patch and a new screenshot with the patch applied which shows both the entity reference labels and the tags showing properly.

@kay_v and @leolando.tan, I'd love to have you take a look and see what you think. Based on the original issue description, I think there needs to be a bit of clarity for what the desired style is for labels for taxonomy terms compared to other entity references, both inline and above.

benjifisher’s picture

Status: Needs work » Needs review

@woodseowl: when you attach a new patch, you normally set the issue to "Needs Review" (NR) in order to invite others to look at what you have done. The first to accept the invitation is almost always the testbot, which often makes helpful suggestions.

I will set this issue to NR on your behalf.

woodseowl’s picture

@benjifisher, thank you for the guidance!

leolandotan’s picture

Hi @kay_v, my apologies for the trouble in this delay. I had to attend to something on my end. Thank you very much for looking into the progress of this issue. I'll try to help if I still can. :)

mukeysh’s picture

StatusFileSize
new23.32 KB

@woodseowl I have applied the patch. Patch is applied successfully and working as mentioned #10 but I have found one more issue. The default reference field "tags" label in not same as other labels. Please see screenshot for reference.
drupal-bartik-label

mukeysh’s picture

Status: Needs review » Needs work
mukeysh’s picture

.field--name-field-tags .field__label also has different styling which makes label styling inconsistent.

mukeysh’s picture

Added patch in which i have removed bold property from .field--name-field-tags .field__label .

mukeysh’s picture

Status: Needs work » Needs review

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

nancydru’s picture

Yes, let's get this in.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

joachim’s picture

Status: Needs review » Reviewed & tested by the community

Patch looks good to me.

Anonymous’s picture

Ditto. Hope this makes the next release!

joachim’s picture

Reroll for 8.8.x.

(Can confirm it applies to 8.7.1 too!)

Status: Reviewed & tested by the community » Needs work
yogeshmpawar’s picture

Status: Needs work » Reviewed & tested by the community

All looks good so setting back to RTBC! Tests failure is not related (see #3055648: Frequent random fail in \Drupal\Tests\media_library\FunctionalJavascript\MediaLibraryTest).

lauriii’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +Needs subsystem maintainer review

This could use a review from Bartik maintainer.

guypaddock’s picture

Status: Needs review » Needs work
StatusFileSize
new14.13 KB
new12.54 KB

Although the patch in #24 does significantly improve the label styling, there's still something very strange about inline label fields in Bartik. Fields -- especially taxonomy fields -- to flow into one another (floating left) instead of each field being on its own line. When using the "inline" style of label display, I would still expect each field to be on its own line, with the label inline to the left.

Before patch:
Before the patch

After patch:
Issues after the patch

These are just vanilla core taxonomy fields with vanilla Bartik. No custom CSS at all is applied to our site.

shimpy’s picture

Status: Needs work » Needs review
StatusFileSize
new4.04 KB
new124.86 KB
new118.61 KB

Hii I have created one patch for drupal 8.8.x for inheriting the styles from classy. Please review. Also attaching before patch and after patch screenshots as well.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Neeraj Dhamiwal’s picture

StatusFileSize
new4.46 KB
new296 bytes
new60.96 KB
new57.79 KB

Checked and apply patch #29 working fine but need spacing so i have added margin and create new patch for this issue.
Please review

Status: Needs review » Needs work

The last submitted patch, 36: 2957408-36-bartik_field_styles.patch, failed testing. View results

kitserve’s picture

This issue is causing me trouble in a new site I'm building in Drupal 9.4.5. This issue has been open since 2018. What's the next step for moving this along? Is Bartik still being maintained or should I change to a different theme?

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

pameeela’s picture

Project: Drupal core » Bartik
Version: 10.1.x-dev » 1.0.2
Component: Bartik theme » Look and Feel
Issue tags: -Needs subsystem maintainer review +Bug Smash Initiative

Moving to contrib since Bartik was removed from core in D10.

rayand’s picture

Hi, for my first contribution I can take this ticket and see what I can do to fix this problem. :)

djsagar made their first commit to this issue’s fork.

djsagar’s picture

Status: Needs work » Needs review

Hi All,

Created MR request kindly review.

Thanks!

liam morland made their first commit to this issue’s fork.

liam morland’s picture

Version: 1.0.2 » 1.1.x-dev
Status: Needs review » Needs work
Issue tags: +Needs reroll