Posted by jessebeach on May 4, 2010 at 3:54pm
As I get more familiar with the coding habits of Drupalists, I'm noticing that there's a preponderance of classed elements in the stylesheets in core. Example:
ul.primary { ... }This code is in system.css on line 183 (D7).
Is this the preferred style of module developers? I would prefer to see something like
.tab .primary { ... }instead. It provides more semantic scope. Any other opinions on this? Is there a reason the styles are declared this way that I perhaps just don't know about yet?
Actually, I'd much rather prefer no CSS in core at all, but I'm sure there are well-beaten threads about that topic already.
Comments
I'm with you
I would love to just have no core CSS at all as I find myself overriding things defined by modules all the time (Try styling the calendar module). However, I'm sure no core CSS would make for some pretty ugly elements. So I guess finding the right balance is probably the way to go.
WordPress pumps out zero CSS
WordPress pumps out zero CSS from the core. It's all defined in the themes. The default WordPress theme (the one that ships with the install), contains styling for everything that WordPress outputs. I'm not saying that contrib modules shouldn't define their own style. But once a module goes into Core, its styles should be transferred to Garland (and any other Core themes).
Easier said than done...
This is much easier said than done when it comes to Drupal. Core has multiple modules and themes. If we made each theme responsible for core CSS it would be completely crazy. For starters:
However, I do think that core CSS files are in need of a MAJOR overhaul. We have been discussing separating the structural/behavioral CSS from actual presentational/theme related CSS that modules create (both core and contrib) into separate CSS files here in this issue: http://drupal.org/node/777814
I bring this up because it would help tremendously with the end goal here. Wouldn't it be nice to wipe out all design-related CSS that was created by every module in one shot without breaking Javascript functionality and basic structural stuff? I think so :D
This is something that is definitely possible with Drupal, but we'll need a good team of front-end developers to help, as it's no easy task. If this is something you are interested in, please help us out!
core base theme
I'm thinking that Drupal 8 should have a base theme which contains the non-essential core styles, then core themes should be based on that.
StyleStripper
StyleStripper lets you disable core CSS files, but no D7 version yet. Applying core CSS to wider semantic scope seems like it would make it necessary to override even more core CSS. I'd rather it become more specific, making it easier to work around when necessary.
Thanks Jacine! I was looking
Thanks Jacine! I was looking for a nice succinct set of bullet points to sum up why the world is the way it is.
This is where the foundational concepts of Skinr make the most sense. For instance let's image a module developer creates a mega-menu module. Underneath is an unordered list of some nested complexity and some javascript to enable the behaviors. But the question arises, should it present horizontally or vertically by default? Choosing one makes the other harder to achieve for a themer. Simply building the style for both into the module and offering a toggle in some configuration overlay ignores the fact that a third option might exist, like a top level menu with some kind of carousel for the groups of second level links...let the imagination run wild. In any case, once the module developer makes a move into style, even an innocent padding-top: 0.2em, this creates code that will most certainly need to be overridden, and that's just bloat.
What about skinr sets available for each module? Vertical tabs, horizontal tabs, diagonal tabs, a timeline with the tabs? Download the module and along side it are 5 skins or 10 or hundreds for popular modules for download.
I sense the desire is to have something that works out the box for a new install or a new theme. I definitely want that, too. Surely there's a way to abstract this layer of the stack into our themeing world where we can run wild with it.
optional reset.css for each module
Could you encourage module maintainers to provide an additional file -- reset.css, if you wanted to just override elements in your theme you can continue. The module will work for people who don't want to theme and if you have some major work to do you just upload the reset.css for that module (renamed correctly -- modulename.css) and everything for that module is zeroed?
That way if you update the module all your overrides are in your theme and you just need to re-upload and rename the latest reset.css (maintainers could then keep the reset up to date with any changes to the module that have been made.)
reset.css
Would the reset.css be loaded in addition to the stylesheets for the module?
No a replacement file
I think that the easiest for module devs would be to just have an alternate file so we as a designer/themer would have the choice to start from scratch with the elements which that module is effecting.
The module developer provides their default css in the module -- mymodule.css and a reset.css which doesn't get used at all unless the designer/themer deletes or overwrites mymodule.css and renames reset.css to mymodule.css. You would have to then make the call as to what module/s you are themeing a lot of output from to want everything reset to 0. Any css is then applied in your theme without having to override everything.
It would mean that you would need to redo this change to the module each time you updated the module but you would be prompted to do this when you looked at the site and all of a sudden after an update you tabs (or whatever) all looked default drupalish.
Just a thought which might not place too much extra work on the module developer.
Thinking as I write this, it probably doesn't work with some of the workflows to keep things up to date but I'm just commenting from the way I get by so…
What was discussed at
What was discussed at DrupalCon DC last year was ripping all css out of core modules and putting it into a core base theme. That way designers could use it as a base theme or skip it and work from scratch. There seemed to be consensus in the room at the time, but things were already going in a different direction by the for D7. So maybe we can achieve something in D8?
PINGV | Strategy • Design • Drupal Development
totally on board
I am totally on board for that approach. It's going to take heaps of advocating to get there!
Umm..
s/advocating/volunteering/
:-)
Theme can exclude core CSS files
I thought one of the changes in D6 was that your theme could exclude the core CSS files into the .info file. Wouldn't that allow for those that want none of the core CSS to achieve it?
Correct
That is correct, the starter theme I use for project overwrites all the system css files leaving a reset.css that includes Meyers reset along with sticky footer, clearfix and some admin stuff.
I also have a generic style.css that creates a baseline grid and some standard layout styling for items.
The only real problems occur when modules start adding their own .css, but you can exclude them the same was the the .info file.
Re:
One possible way of solving this.
Pseudocode in the theme header
if module a enabled load stylesheet a.or maybe some file within the theme directory where one could say, load the stylesheet for this module.
Same could go for Javascript as well.
Pseudocode
load.php in theme folder
module_a.cssmodule_b.css
javascript_file1.js
javascript_file2.js
Modules might even add and remove this automatically in this file on install/ uninstall. Or for example comment (#) and uncomment on the enabling/ disabling of a module.
Not sure what you mean by this. For example stylesheets for a theme are generally put into a folder if there is more than one. Want to use it in another theme just copy the stylesheet.
Aren't we just moving resources? All the styling would be within the theme folder. Which could certainly make my life easier. It would be more the normal way of working. Now all this predefined code is being loaded bloating a theme's output, and also slowing down a site. And making design sometimes a jigsaw puzzle, making it more complicated than needed.
Possible solutions
So how would one then account for (custom) HTML output from modules? A possible solution could be to work with a 'module template' system. Separating content from styling. And then place the module template in the theme folder. This way all the HTML and CSS styling is contained within a specific theme.
So something like this possibly:
Folder structure and files in the theme directory
Theme name
- Module_templates (possibly with sub-directories if you use a lot of modules)
- CSS (all CSS files including those of modules)
- Javascript (all Javascript files including those of modules)
- index.php
- load.php (see my previous post)
- page.php
- node.php
- etc
So what if you have different stylings for the same module in a website?
You could define in the theme which module template to use, using conditional statements for example. Say if for example you only want to use a modules template for a certain taxonomy term.
'load.php'
Concerning load.php I mentioned in the previous example you should be able to manually override whether or not a module uses the css/ javascript* that came with the module.
*Some javascript might be needed to use the functionality of the module, but there should be no HTML/ CSS styling within the javascript in such a case.
CCK and Contemplate modules
Something that has also caught my eye are custom content types and the modules CCK en Contemplate. It certainly makes life easier styling nodes in my opinion.
So a similar approach for styling modules might be handy, hence the suggestion for module_templates and something like load.php.
This appears to have strayed
This appears to have strayed off topic from the point of classing elements.
That said in D7, shouldn't removing any stylesheets you don't want be as easy as removing them from the #attached arrays? Rather than a module having to provide a reset.css that sets its markup to a standard base, the file could be completely excluded. Theme CSS only bloats if we let it.
Please no way
Well, as someone who's created custom themes for at least 50 WordPress websites, I would not recommend doing things the WordPress way. Many many times I've added a new plugin (their word for module) to the site, only to realize there's no support in the theme, and I have to go write custom PHP/HTML to make the output show up, and custom CSS to style it — from scratch.
Please no.
Plus, Drupal modules are way more powerful than WordPress plugins. I can't imagine having to write custom CSS from scratch for every single module. Overriding is a pain, yes, but starting over is worse. You can always do that if you want by knocking out all the CSS files from core and contrib. I'd suggest anyone who thinks removing all CSS from everywhere should go try this. Make a list of all the core css files, and all the contrib css files in your modules — and put that list in your .info file, basically disabling everything. Then start a theme. The pain will make you change your mind about removing all CSS from the modules.
Jen Simmons
http://jensimmons.com
lesson learned :)
"Make a list of all the core css files, and all the contrib css files in your modules — and put that list in your .info file, basically disabling everything. Then start a theme. The pain will make you change your mind about removing all CSS from the modules." - @jensimmons
I removed the core files in this way on a new project recently and watched as my admin screens exploded into madness. So then I copied all of the core CSS code into files in my theme, overriding them from core, and stripped out all of the styles that were driving me nuts. It was a sobering few hours :)
The pristine HTML page is for me the unattainable ideal. I know that the outcome of this discussion will be a set of actions that take into account the constraints of Drupal, and I use constraints without malice. Any complex system has constraints.
I'm going through @Jacine's latest post now. She's done a commendable job synthesizing these discussions. I'm convinced some (slight?) variation on this proposal is the way forward.
Whole as greater as sum of its parts
First of all, thank you jacine for the mega post referenced above.
And a second thank you to jensimmons for jumping in the deep end of the pool.
Last year at DC/DC, I was in the D4D BoF listening to the discussion of where we should take the front end. Time and again I have wanted to collaborate with our project - but I find myself too much of a lone wolf. Vocalizing new ideas ain't my strong point - things need to gestate for a while. That some times takes a year or so. During that time, I try to work out a solution - as a proof of concept - a test for ideas.
The most recent proof of concept has been http://drupal.org/project/runvsc that I just committed last week. This is really an attempt to correct alot of what I find "wrong" with the Drupal theme layer -> to think of a theme more as a module than a theme. rather than go into here, I would like you to down load it (and http://drupal.org/project/startvsc) and test run it - let me know what you think. Hopefully this will create some discussion.
Here are some thoughts:
Core CSS - the problem for me is not that core modules use/ add css -> the problem for me is that the protocol is unreliable. Even the generation of markup is un-reliable (in runvsc, all markup is pretty much generate by a single function) -> so looking for things to override is a nightmare. The inconsistency of core out put drives me bonkers (yes, bonkers) If we could formalize a simple way to add markup and css -> with hooks to override, then we would be onto something.
why have "Themes" after all? this has bothered me that the themes seem to play with a different rule set than modules. Why not treat themes more like modules -> but this is coming from someone who does his best to not use tpls .... so that way of working is more natural to me.
with respect to the above -> i would love to "SASS" drupal themes. If we made themes more like modules -> then we could add logic like a SASS environment. If this was the case -> maybe module CSS could be registered in a hook (it kinda is -> but not standard) and then "unset" at a "theme" layer with logic-> that logic could be a simple boolean value called from a hook in the theme layer.
that would give the front end an opportunity to NOT load a particular module css at all.
To extend that even further -> do the same thing to functions that generate html. Alot of time, I would rather not hunt down a "theme function" Most of the time, i don't see developers needing to hunt down a function -> they know that a structure exists -> so, they just get on with setting/ overriding a value.
If markup and css were able to be unset -> we would never need theme functions. they would be obsolete. The default setting would be TRUE for everything - and the front end layer would select which css or markup would be FALSE.
I think that developers might embrace that structure a little more. To know that they don't really have to write output -> but just pass a variable to a function with an array of parameters.
some of these concepts I have put into action in runvsc. about six months ago, jacine and I sat down for about three hours and went through it - and after which, i decided to abandon it because it seems incongruent. three months later, in a dream, I figured out what I was doing wrong and reworked the whole thing into a different structure. I really think that more can be done with it -> but now, it is a real set of solutions for items that have plagued me in the theme layer from install 1
that is my two cents.
RunVSC sounds masterful!
Can't wait to load it up and take a test drive.
Lessons learned :-)
@johnvsc
Looks interesting. And I can definitely see the benefits of that way of thinking.
Et al
Also take a look at the Skinr module.
What I'm finding lately is that in some modules such as Views for example it is possible to add a class or id to a view for example. This means I can add a div class in a module for example. And allow me to fine-tune the styling, or completely change it up. The caveat being that another CSS style and class/ id is added to the code. Which in turn leads to larger CSS files and code bloat. However using the CSS Gzip module in combination with the 'Optimize CSS' function in the core cache the download size becomes quite a bit smaller. And using a custom.css in your theme allows you to just add the css you need on top of what exists. It makes theming life easier.
And using things such as position: absolute. Well you can override a lot. :-)
@Jacine
Great write-up
Over-riding core
I have just spent ages overriding some of core's css (table identation and comment link indentation).
For some reason it has been necessary for me to add !important to my rules within my custom css sheets.
If the theme layer was able to truly override the core css then why would this be the case?
Adding !important rules is
Adding
!importantrules is not necessary (I don't think I've ever used one to theme Drupal), so I can only assume your implementation is missing something. You should be able to override the CSS without any trouble using normal CSS specificity (though note that the last example in that page is incorrect, most browsers ignore the later parts (e.g. ".class-name") of chained CSS rules likep.class-name).Lazy Programming
OK I admit. I think I was being lazy. I've now used Firebug to go through and individually identify each element that was not behaving as expected.
The reality is that they were using more specific CSS selectors than I was using in my reset.css file. I've now simply added those selectors to the file and it has had the desired effect.
It's a bit of a faff though! Thanks for the reply.
!important in core
Just found one in core!
in system.base.css
.element-invisible {
clip: rect(1px, 1px, 1px, 1px);
position: absolute !important;
}