Posted by davidtrainer on November 17, 2009 at 3:24am
7 followers
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | Seven theme |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | CSS, Needs design review |
Issue Summary
Text input and select form elements in Seven consistently appear with this font stack:
"Helvetica Neue",Helvetica,Arial,sans-serif
Except where they don't. The filter dropdowns on admin/content, and on admin/people, the filter dropdowns and *some* of the update options.
Firefox 3.5.5 on OS X. Same behavior in Safari.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| forms-fonts.png | 154.36 KB | Ignored: Check issue status. | None | None |
Comments
#1
Considering this issue in the context of all these recent, related ones:
#634498: Filters layout is broken on admin/content and admin/people
#563390: Seven theme lacks formatting on common html elements such as lists, paragraphs & <code>
#634224: Seven theme needs vertical space between paragraphs
#634218: Seven theme: CODE elements are too small
What do we think about a separate stylesheet that does the equivalent job of zen's html-elements.css?
#2
Font-stacks should certainly cover all applicable uses.
Maybe have a look at how much of this is covered by #575294: Add reset.css through drupal_add_css() instead of through the .info file and check if #592018: Re-organize styles across stylesheets from system.module and separate presentational and behavior-supporting styles has any bearing on this.
#3
This patch adds html-elements.css, for styling of generic elements. It pulls some of that styling over from style.css. It resolves the fonts problem on the form elements in this issue and also resolves #634498: Filters layout is broken on admin/content and admin/people
#4
+1 for font consistency. This patch has a few visual side effects to work out though. I've illustrated these in attached screenshots.
#5
This patch addresses all of the issues raised in #4.
#6
I'm very much in favor of adding an html-elements.css file to style generic elements, it adds clarity and structure by seperating the typographic basics from the per-case specifics. It'll make a better impression on themers inspecting these files, too, it's just something you do :-)
Will apply this, review and report back.
#7
Strange. Applying this patch makes text go smaller than before.
I see that a font-size: 0.8em gets redefined to a font-size: 0.875em. This should keep focus on fixing the form elements and the addition of html-elements.css without any other design changes (which I'm sure is the intent).
http://skitch.com/yoroy/nea3n/before
vs.
http://skitch.com/yoroy/nea38/after
(FF 3.5.5 on OS X)
#8
I may have derailed this issue a little bit with the html-elements.css change. So I've added #641734: Separate generic html elements' style into html-elements.css which will just split those stylesheets up as we've been discussing here. Once that gets in, we can get back to the fonts on these form elements.
#9
bumping this for review.
#10
Still an issue!
Markup component?
#11
Nope. Markup component is not for theme-specific issues.
#12
Is this the right place to question whether the form elements ought to be in a different font in the first place? I think if the form labels, help text, and so forth are Lucida Grande, then the form elements should be too. Adding a slightly different sans-serif to the page does not improve the design, regardless of how consistently it's applied.
#13
#5: 634724-html-elements-css1.patch queued for re-testing.
#14
The last submitted patch, 634724-html-elements-css1.patch, failed testing.
#15
Related, more focused: #858748: Some seven font sizes are too small to read