Closed (outdated)
Project:
Drupal core
Version:
7.x-dev
Component:
Seven theme
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
17 Nov 2009 at 03:24 UTC
Updated:
22 Oct 2015 at 23:59 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
davidtrainer commentedConsidering 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?
Comment #2
yoroy commentedFont-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.
Comment #3
davidtrainer commentedThis 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
Comment #4
bowersox commented+1 for font consistency. This patch has a few visual side effects to work out though. I've illustrated these in attached screenshots.
Comment #5
davidtrainer commentedThis patch addresses all of the issues raised in #4.
Comment #6
yoroy commentedI'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.
Comment #7
yoroy commentedStrange. 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)
Comment #8
davidtrainer commentedI 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 seven.base.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.
Comment #9
yoroy commentedbumping this for review.
Comment #10
aspilicious commentedStill an issue!
Markup component?
Comment #11
jacineNope. Markup component is not for theme-specific issues.
Comment #12
markabur commentedIs 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.
Comment #13
markabur commented#5: 634724-html-elements-css1.patch queued for re-testing.
Comment #15
sunRelated, more focused: #858748: Some seven font sizes are too small to read
Comment #16
lewisnymanPer David's comments in #8 let's postpone this issue until #641734: Separate generic html elements' style into seven.base.css get's committed
Comment #17
lewisnymanI think this is still a problem. I forgot to unpostpone it.
Comment #18
Bojhan commentedWe don't really seem to have this anymore. I just checked a whole bunch of elements?