With Bartik theme in defualt setting, the term reference field of a content node can not be displayed correctly. Its font size is clearly much smaller than other fields. When switching to other themes, e.g., Garland, the term reference field is then displayed correctly. In the attachment is a screenshot of a content node shown with Bartik theme, where the field "Journal" is a term reference field.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

flightrisk’s picture

I have the same issue

dddave’s picture

Status: Active » Postponed (maintainer needs more info)

Is this still an issue with 7.14?

dddave’s picture

Status: Postponed (maintainer needs more info) » Fixed

"Time" seems to have fixed this. Closing old, stale issues. If the issue still persists feel free to re-open.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

idcm’s picture

Version: 7.4 » 7.21
Status: Closed (fixed) » Active
FileSize
327.66 KB

I am not sure what "time" means in comment #3 but the original problem still exists in D7.21 for Bartik. Attached is a image detailing the issue. As you can see, the term reference field renders as h3 where the other fields don't and the css for this field does not match the css for the other fields. At first I thought this issue was in core (the theme code for this field type) but when I loaded another theme, the h3 for the term reference field was not there, it was a div just like the others.

Can this be fixed, please?

drupauler’s picture

I'm a noobie just starting with Drupal on 7.21with the same issue.

Problem goes away switching to Garland (thanks for the tip).

Can somebody who knows what their doing have a look at this please.

dddave’s picture

#5 brings the stuff nobody brought up in my inquiry from #2,3.

David_Rothstein’s picture

Title: Improper style for term reference field » Bartik displays all taxonomy term fields in a smaller font than other fields
Version: 7.21 » 8.x-dev

I'm pretty sure this was an intentional design decision (at least for free-tagging taxonomy fields such as "Tags")? But it does seem to be applied a bit too broadly.

This issue exists in Drupal 8 too, so moving there. I doubt we could backport this kind of fix to Drupal 7. But it can certainly be dealt with on Drupal 7 sites by subtheming Bartik and changing the behavior there.

David_Rothstein’s picture

David_Rothstein’s picture

juampynr’s picture

Status: Active » Needs review
FileSize
12.55 KB
1.38 KB

Here is a patch that makes the Tags label to look like other labels. I have not touched the size of the listed terms though.

Selection_003.png

idcm’s picture

Thanks juampy. It definitely looks better (even with the font difference).

mgifford’s picture

Issue tags: +Accessibility, +#d8ux

This part is a problem:

-    $output .= '<h3 class="field-label">' . $variables['label'] . ': </h3>';
+    $output .= '<div class="field-label">' . $variables['label'] . ': </div>';

Div's contain no semantic information. The Heading is required for accessibility. The term reference is a list (which needs a heading).

David_Rothstein’s picture

@mgifford, are you sure? This seems to contradict the conclusion in #1768732: Wrong document outline because of Term reference label in h3.

I think the problem is that we don't know how any field (term reference or otherwise) is actually being used on the site. A Heading might make sense here for some sites, but for others it might be misleading. So the best Drupal core can do is use divs (which it already does for every other field type, I believe, including list fields)... Then leave it to something like http://drupal.org/project/fences to allow people to make better choices for each field on a site-by-site basis.

mgifford’s picture

I don't claim to be an HTML5 expert. I don't think @no2e's comments or @Everett's response was all that conclusive. I do think that it's something to look into.

It would be interesting to look at the output of actual sites via things like:
http://gsnedders.html5.org/outliner/
http://code.google.com/p/h5o/

But I am confident that the issue can be resolved without any changes to the markup. If we want to adjust the markup let's move that over onto https://drupal.org/node/1768732

mgifford’s picture

Here's the change in #11 without the removal of the H3 tag.

andymartha’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
64.87 KB
26.22 KB

After applying patch bartik-term-label-smaller-1218640-16.patch in #16 by mgifford to a fresh Drupal 8 install, I can confirm that the taxonomy term label is larger, but it is not a major difference. Thanks for the work everyone and please see screenshots below.

taxonomytextbefore1.png

taxonomytextafter1.png

David_Rothstein’s picture

So it still seems to me that making the font smaller for the "Tags" field was a Bartik design decision. Are we sure we don't want to preserve special theming for that particular field, at least? (Since Bartik is the default core theme, I don't think it's wrong for it to contain special theming targeted at the default core profile.)

I also still think that (at least for Drupal 8) the HTML markup for taxonomy term fields should be consistent with other fields (not just the visual appearance), but this patch leaves them inconsistent.

Not moving this back to "needs work" but perhaps it could still use some discussion?

mgifford’s picture

1) Bartik design decision - would be great to have a document or something for future Core themes we could refer to so that we could know if it was a design decision & why. If the font is too small it is a problem whether or not it is a design decision, I think. However, does it need to be the same size as the default font... probably not. The initial bug described it as "clearly much smaller than other fields". Maybe we can adjust it so that it's just somewhat smaller than other fields.

2) I'm all for consistency, but think we should raise the bar so that it is more semantic rather than lower the bar. Can we just get rid of the div tags so that the fields are consistent? Can they all be h3 or h4 tags? If so let's open a new issue for the tags that are still using div's.

Thanks for not pushing this back to needs work.

alexpott’s picture

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

I'm pushing to needs review as the discussion that #18 and #19 suggest is needed has never occurred.

yoroy’s picture

From design perspective slightly smaller is worse than clearly smaller, because it will look even less deliberate then. I think it makes sense to make the label consistent with others, both in html as in appearance. I can understand why the actual tags are in a different font, the sans-serif makes them a bit more techy looking, which could support the meta data (instead of content) aspect of these. But that's just my guess. Because of the different font it would be ok to up the font size just enough to be better readable.

juampynr’s picture

mgifford’s picture

Status: Needs review » Needs work
Issue tags: +Needs usability review, +Accessibility, +#d8ux

The last submitted patch, bartik-term-label-smaller-1218640-16.patch, failed testing.

mgifford’s picture

Status: Needs work » Needs review
FileSize
980 bytes

re-roll.

mgifford’s picture

mgifford’s picture

Bojhan’s picture

Issue tags: -Needs usability review

Yhea, this is a design tweak that actually looks weird.

mgifford’s picture

@Bojhan so does the patch need work still, if so what?

Bojhan’s picture

Could this get a screen?

mgifford’s picture

It is the same as #17 above. The latest patch was just a reroll to deal with an injected RTL issue. Wouldn't affect the display though (when comparing patches).

mgifford’s picture

mgifford’s picture

Issue summary: View changes
FileSize
313.31 KB
22.43 KB

@Bojhan here's the screen comparison. Patch still applies.

closeup of patch

before/after comparison

emma.maria’s picture

freelylw’s picture

Its almost 3 years since the beginning of this post, the problem still exist in my latest drupal7.28

Can anybody suggest any solutions to solve this ? I can't believe there are nobody noticed this huge bug in the theme for so many years ?

mgifford’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll
mgifford’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
821 bytes
LewisNyman’s picture

Category: Bug report » Feature request

This isn't a bug, it's a deliberate design decision. Information heirachy etc etc. Let's try pinging Jen Simmons and see if she has a historical opinion here.

Maybe this decision could be reversed, there is at least one user of the Bartik theme here that is passionate enough to increase the font size right?

jensimmons’s picture

Lewis is right. This is a deliberate design decision to create a visual hierarchy in what's most important vs not as important. If you'd like to override this for your particular website, I suggest making a child theme of Bartik and adding a bit of CSS to change it to look how you want.

Otherwise, this is fine. It is supposed to be smaller.

LewisNyman’s picture

Status: Needs review » Closed (won't fix)

Thanks Jen! Sounds pretty decisive. If someone feels strongly about this they can reopen it with some more reasoning.

joachim’s picture

> This isn't a bug, it's a deliberate design decision. Information heirachy etc etc

> This is a deliberate design decision to create a visual hierarchy in what's most important vs not as important.

Do you mean that it's the 'Tags' field that was decided was less important, or all taxonomy fields?

If the latter, then that's a pretty big assumption about a user's site build. And at any rate, the CSS for this is being applied to ALL entity reference fields: see #965162: Wrong font for entity reference field widget labels and descriptions..

andrewmacpherson’s picture

Do you mean that it's the 'Tags' field that was decided was less important, or all taxonomy fields?

If the latter, then that's a pretty big assumption about a user's site build

+1

Thanks Joachim, that would certainly justify revisiting this I think.