There are two conflicting uses of the "label" CSS:

  • Drupal assigns the "label" CSS class to various UI elements, for example the "Member for" field of a user.
  • Bootstrap framework has the concept of a label which is white text on rounded-corner dark background. It uses the "label" CSS class in combination with another such as "label-default".

For example, visit "Your Account" (/user) and the "Member for" label is by default invisible. That's because $label-color: #fff and the background color is not defined as none of the label-XXX classes are set.

None of the rules in the framework file _labels.scss are really useful. Instead .label should probably look more like .field--label, or could base on rules from core classy theme.

Comments

AdamPS created an issue. See original summary.

AdamPS’s picture

Ah I have found a related issue #2638250: The label "Member for" on user profiles is hardcoded markup that is different from other user fields.

However I think this issue is still valid as it has a wider scope - the "Member for" field is only one example of where Drupal core uses the label class.

AdamPS’s picture

markcarver’s picture

Status: Active » Closed (duplicate)

This is a core issue. Nothing can be done about this in this project since we don't control the upstream Bootstrap framework.

AdamPS’s picture

@markcarver Thanks for reply. Honestly I do understand the distinction with the upstream framework (I appreciate you are likely fed up with getting framework bugs reported here). I had imagined there could be some CSS Overrides to undo some of the worst effects - something like (untested). Anyway no problem.

.label {
  display: inherit;
  padding: inherit;
  font-size: inherit;
  color: inherit;
}
markcarver’s picture

I had imagined there could be some CSS Overrides to undo some of the worst effects

Unfortunately, no. This is actually a very deep rabbit hole I would like to avoid entirely. The above CSS example would actually force us to instead copy the original styles to every single other label type (e.g. .label-danger, etc.) because they wouldn't have the base .label styles to inherit. This just creates more technical debt in this project.

Core has done a great job of migrating a lot of manual markup into proper templates/suggestions in D8. They've also done a great job at standardizing classes (Classy). However, there are still some outlying artifacts from D7 and even D6. This is just one of them. I would much rather this be fixed upstream in core, so all can benefit from whatever "fix" is implemented, than trying to hotfix this in a contrib project.

Personally, I don't even bother with this output because I know it's broke and I always end up removing it anyway or replacing it with a real/custom field if it's actually needed.

AdamPS’s picture

Thanks for explaining