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.

Files: 
CommentFileSizeAuthor
#25 bartik-term-label-smaller-1218640-25.patch980 bytesmgifford
PASSED: [[SimpleTest]]: [MySQL] 59,890 pass(es).
[ View ]
#17 taxonomytextbefore1.png26.22 KBandymartha
#17 taxonomytextafter1.png64.87 KBandymartha
#16 bartik-term-label-smaller-1218640-16.patch869 bytesmgifford
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch bartik-term-label-smaller-1218640-16.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#11 1218640-11-bartik-term-label-smaller.patch1.38 KBjuampy
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1218640-11-bartik-term-label-smaller.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#11 Selection_003.png12.55 KBjuampy
#5 bartik_term_reference_field_D7.21.jpg327.66 KBidcm
JournalField.jpg16.15 KBShengtian

Comments

I have the same issue

Status:Active» Postponed (maintainer needs more info)

Is this still an issue with 7.14?

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.

Version:7.4» 7.21
Status:Closed (fixed)» Active
StatusFileSize
new327.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?

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.

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

Title:Improper style for term reference fieldBartik 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.

Status:Active» Needs review
StatusFileSize
new12.55 KB
new1.38 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1218640-11-bartik-term-label-smaller.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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

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

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).

@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.

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

StatusFileSize
new869 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch bartik-term-label-smaller-1218640-16.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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

Status:Needs review» Reviewed & tested by the community
StatusFileSize
new64.87 KB
new26.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.pngtaxonomytextafter1.png

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?

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.

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.

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.

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.

Status:Needs work» Needs review
StatusFileSize
new980 bytes
PASSED: [[SimpleTest]]: [MySQL] 59,890 pass(es).
[ View ]

re-roll.

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

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

Could this get a screen?

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).