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.
Comment | File | Size | Author |
---|---|---|---|
#37 | bartik-term-label-smaller-1218640-37.patch | 821 bytes | mgifford |
#33 | Closeup-tags.png | 22.43 KB | mgifford |
#33 | Comparison-tags.png | 313.31 KB | mgifford |
#25 | bartik-term-label-smaller-1218640-25.patch | 980 bytes | mgifford |
#17 | taxonomytextbefore1.png | 26.22 KB | andymartha |
Comments
Comment #1
flightrisk CreditAttribution: flightrisk commentedI have the same issue
Comment #2
dddave CreditAttribution: dddave commentedIs this still an issue with 7.14?
Comment #3
dddave CreditAttribution: dddave commented"Time" seems to have fixed this. Closing old, stale issues. If the issue still persists feel free to re-open.
Comment #5
idcm CreditAttribution: idcm commentedI 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?
Comment #6
drupauler CreditAttribution: drupauler commentedI'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.
Comment #7
dddave CreditAttribution: dddave commented#5 brings the stuff nobody brought up in my inquiry from #2,3.
Comment #8
David_Rothstein CreditAttribution: David_Rothstein commentedI'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.
Comment #9
David_Rothstein CreditAttribution: David_Rothstein commentedMarked #1510618: View a node with term reference fields: font size smaller than for other fields as duplicate.
Comment #10
David_Rothstein CreditAttribution: David_Rothstein commentedAnd a related issue (not quite a duplicate): #1768732: Wrong document outline because of Term reference label in h3
Comment #11
juampynr CreditAttribution: juampynr commentedHere is a patch that makes the Tags label to look like other labels. I have not touched the size of the listed terms though.
Comment #12
idcm CreditAttribution: idcm commentedThanks juampy. It definitely looks better (even with the font difference).
Comment #13
mgiffordThis part is a problem:
Div's contain no semantic information. The Heading is required for accessibility. The term reference is a list (which needs a heading).
Comment #14
David_Rothstein CreditAttribution: David_Rothstein commented@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.
Comment #15
mgiffordI 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
Comment #16
mgiffordHere's the change in #11 without the removal of the H3 tag.
Comment #17
andymartha CreditAttribution: andymartha commentedAfter 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.
Comment #18
David_Rothstein CreditAttribution: David_Rothstein commentedSo 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?
Comment #19
mgifford1) 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.
Comment #20
alexpottI'm pushing to needs review as the discussion that #18 and #19 suggest is needed has never occurred.
Comment #21
yoroy CreditAttribution: yoroy commentedFrom 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.
Comment #22
juampynr CreditAttribution: juampynr commented#11: 1218640-11-bartik-term-label-smaller.patch queued for re-testing.
Comment #23
mgifford#16: bartik-term-label-smaller-1218640-16.patch queued for re-testing.
Comment #25
mgiffordre-roll.
Comment #26
mgifford#25: bartik-term-label-smaller-1218640-25.patch queued for re-testing.
Comment #27
mgifford#25: bartik-term-label-smaller-1218640-25.patch queued for re-testing.
Comment #28
Bojhan CreditAttribution: Bojhan commentedYhea, this is a design tweak that actually looks weird.
Comment #29
mgifford@Bojhan so does the patch need work still, if so what?
Comment #30
Bojhan CreditAttribution: Bojhan commentedCould this get a screen?
Comment #31
mgiffordIt 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).
Comment #32
mgifford25: bartik-term-label-smaller-1218640-25.patch queued for re-testing.
Comment #33
mgifford@Bojhan here's the screen comparison. Patch still applies.
Comment #34
emma.mariaComment #35
freelylw CreditAttribution: freelylw commentedIts 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 ?
Comment #36
mgiffordComment #37
mgiffordComment #38
LewisNyman CreditAttribution: LewisNyman commentedThis 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?
Comment #39
jensimmons CreditAttribution: jensimmons commentedLewis 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.
Comment #40
LewisNyman CreditAttribution: LewisNyman commentedThanks Jen! Sounds pretty decisive. If someone feels strongly about this they can reopen it with some more reasoning.
Comment #41
joachim CreditAttribution: joachim as a volunteer commented> 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..
Comment #42
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commented+1
Thanks Joachim, that would certainly justify revisiting this I think.