Separate generic html elements' style into html-elements.css
davidtrainer - November 24, 2009 - 19:10
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | Seven theme |
| Category: | task |
| Priority: | normal |
| Assigned: | davidtrainer |
| Status: | needs review |
Description
Separating the css for generic html elements from that of theme-specific id and class selectors makes theme development a lot easier and more efficient.
Attached is a much less ambitious patch than the one attached in #634724: Seven has inconsistent fonts on form elements, which hopefully can now get back on topic. This patch does nothing more than move style definitions out of style.css and into the new html-elements.css, so when reviewing there should be no visual change introduced at all.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| separate-html-elements-css.patch | 5.51 KB | Idle | Unable to apply patch separate-html-elements-css.patch | View details | Re-test |
#1
The last submitted patch failed testing.
#2
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 :-)
It would be great to get this in soon, it gives us a better place to do other Seven cleanups.
#3
Yes, good idea!
It might be something to adjust to this patch: #592018: Re-organize styles across stylesheets from system.module and separate presentational and behavior-supporting styles
By eventually just removing system.css from the stack to get rid of Drupal's default styles for HTML elements, and start with "naked" HTML in html-elements.css. (Or just override system.css, but introducing html-elements.css is probably better in this theme's context as it describes the stylesheet's purpose better.)
#4
Rerolled the patch
#5
The last submitted patch failed testing.
#6
Whoops, it might help to roll that patch from the drupal root directory
#7
Openend about 10 admin pages before applying this patch. Refreshed all pages after applying. No visual changes whatsoever.
Looking at the newly created html-elements.css it looks like you picked all the basics from style.css that should be in here. Me wants!
#8
errrr. "html-elements" ? Isn't all CSS about HTML elements...?
I find this filename quite confusing. Why not generic.css or general.css or base.css or something like that?
#9
I am for this patch, this is the way I am theming by separating visual from the structure, like done here. Well done!
The only problem are the file name, like sun says. Any HTML elements can be styled as visual, structure or even behaviors through selectors.
Here are a few name suggestion for the new CSS file:
presentation.css
general.css
visual.css
#10
From all suggestions, I'd prefer: base.css
presentation/visual is equally flawed, because all CSS is about that. ;) What this split tries to achieve is to move the generic/base styles away from more focused, special styles. That's a very good idea and also a very common practice. Let's just use a proper name for the file, so we can slowly set a standard here (which also means: doing the same for Garland wouldn't hurt).
#11
OK. Let's go with base.css. :-)
#12
Don't name this on personal preference please. It's not a vote. Zen theme is the 34th most used project on d.o. with 22,397 installations. (drupal.org/usage) Zen uses a html-elements.css for this. It would be smart to have core be informed by the most popular contrib theme for this so that we match expectations.
#13
Whether it's coming from Zen or not does not make a difference. If you have a better suggestion than base.css (or generic.css), then let us know, please.
But html-elements.css is really a strange name.
#14
yoroy, personally I always thought that d7's new theme should be an actual zen subtheme. But anyway.
sun, yes, technically all css does html elements but the distinction here is that styles in this file are for all occurrences of generic html elements, as opposed to those for theme-specific classes and ids.
base.css is a less informative name. Also, it seems to imply that other stylesheets contain extra, fancy, optional stuff, and that the theme is meant to be used with base.css only in some scenarios, which it's not.
My preference is to leave the name as is. generic.css would be an acceptable alternative.
#15
#10:
#14:
So we both naturally used the term "generic" to explain what this file contains. Let's go for it. ;)
#16
Indeed! html-elements is not a good name. Let's use generic.css please. :-)
#17
From http://www.w3.org/TR/html/#h-4.2:
They are called html elements, so we should call this file html-elements.css. 'Generic' is meaningless, doesn't give *any* indication of what can be found inside.
#18
You know, I think yoroy has a point here. When I work on drupal themes I always look for the style.css in the theme's folder. This is what a base.css or generic.css would mean to me. It's the root css file that has historically always been in play and the last css file I usually list in my .info file.
If we had another generically named file that has no other meaning in it's name other than it's lack of meaning then that would confuse me. I just keep thinking about how I would teach my non-drupal-enthusiast fellow programmers the purpose of a general.css and handling their needle-ly questions. Ironically, One solution I came up with is naming it something else. If the job that this specific css is responsible for is to modify the default presentation of standard html elements, then it does kind of make sense to call it html-elements.css or elements.css.
#19
Subscribe, I don't have any really strong feelings towards the naming.
"base", "general", "generic" and to some extend "html-elements"(as in - there aren't any classes involved) make the most sense to me.
"presentation" makes the least sense to me as literally all css is for presentation.
#20
I noticed that Zen changed the name from html-elements.css to html-reset.css. Might as well just call it reset.css, as in *duh* it's html. It makes sense to put all styles for generic html elements in reset.css; "smart resetting". Resetting everything to zero in reset.css and then styling everything differently in another stylesheet is not very efficient. What are your opinions on that?
#21
@mverbaar: You seem to be saying that we should shoot a kind of css optimization that is achieved once there are no duplicative rules that apply on the exact same css selectors. I think that kind of optimization is admirable from a purist point of view, but largely useless once CSS aggregators/optimizers are used. Since Drupal 6, standard drupal installations have benefitted from using CSS aggregators to combine multiple css files in to one. It is possible to push the css further by running the combined CSS code through an CSS optimizer like CSSTidy. After seeing the benefit of those steps, I really don't worry about sub-optimimal or duplicative CSS code anymore.
So no, I don't see any harm in have a reset.css for the Meyer Reset, an elements.css for css applied to standard X/HTML elements, a style.css for developers to play with, and other theme css files. The benefit of the multi file approach is to provide developers with a clear segmentation of roles for these individual css files. You can basically tell a set of developers, "Only edit style.css, and if you absolutely need to edit any other css file, ask me first." (from a project manager's POV).
#22
I'm not sure if you need to wait on #676800: Fieldsets break design badly but it probably won't hurt if you did. You may have to reroll the patch in #6 once it it's fully committed.