Part of the CSS Cleanup: http://drupal.org/node/1089868

Overview of Goals

  1. Make it easy to remove unwanted design assumptions in the theme layer, while maintaining critical functionality (such as functional JavaScript widgets).
  2. Prevent uneeded administrative styles from loading on the front end.
  3. Give modules the ability to include a generic design implementation with their module, without burdening themers.
  4. Make CSS and related markup more efficient and less intrusive to improve the themer experience.

The CSS Clean-up Process

Use the following guidelines when writing patches for the core issues listed below.

  1. Put CSS is in the appropriate file: CSS should be moved to separate files, using the following
    name spacing conventions based on their purpose:
    module.base.css
    Should hold structural and behavior related styling. CSS should be coded against the Stark theme. The absolute bare minimum CSS required for the module to function should go here. If there is no CSS required, this file should be omitted.
    module.theme.css
    Should hold generic design-related styles that could be used with Stark and other themes. It's where all design assumptions like backgrounds, borders, colors, fonts, margins, padding, etc, would go.
    module.admin.css
    Should hold styles that are only applicable to administrative pages.

    To see an example of this in practice, look at Drupal's system module.

  2. Remove Assumptions: Styles that make too many assumptions, introduce superflous margins, padding and add things like font settings are not necessary and don't belong in core module CSS files. In cases where core themes depend on these properties, they should be moved to the CSS stylesheet of the respective theme.
  3. Reduce Selector Specificity: CSS code that resides in modules should be written in a way that's easily overridable in the theme layer. To improve the Themer Experience and make core CSS more efficient, CSS selectors should be made as general and short as possible. For example:
    • Use .style {} over div.style {} where possible.
    • Use .module .style {} over div.module div.somenestedelement .style where possible.
  4. Don't use IDs in selectors: Use of ID's in core CSS selectors requires more specificity in the theme layer, making it harder and more annoying to deal with. It makes achieveing consistency in complex design implementations much harder than it needs to be. We need to stop making life hard for theme developers.
  5. Don't be afraid to change markup: There's lots of overlap between using proper and semantic markup and doing CSS right. If you come across a case where CSS is being applied where using a more semantic elements would solve the problem, then change the markup in your patch to make it right. For more information, see the Drupal 8 Markup Gate rules.
  6. Start with Stark and cross-browser test.
    1. "Design" markup and CSS for the Stark theme.
    2. If applicable, adapt the styles to match the core themes afterward.
    3. Finally, test the changes in all supported browsers and ensure no regressions are introduced.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

franz’s picture

How should -rtl.css files be handled? I think they should be either equally split into categories proposed or be all included into base.css.

In this patch I left them in base.css

franz’s picture

Status: Active » Needs review
droplet’s picture

I always want to help to do some cleanup but [#1089868] is not clear. no good example and further explanation.

I only see this issue needs review now. I try to share some of my thought and get some idea so I can work on other clean up issues.

+++ b/modules/search/search.base.css
@@ -0,0 +1,20 @@
+.search-form {
+  margin-bottom: 1em;
+}
+.search-form input {
+  margin-top: 0;
+  margin-bottom: 0;
...
+.search-results p {
+  margin-top: 0;
+}
...
+.search-results li {
+  margin-bottom: 1em;
+}

I feel that no a require for search module. without it, still worked well with Stark theme.

+++ b/modules/search/search.base.css
@@ -0,0 +1,20 @@
+.search-results .title {
+  font-size: 1.2em;
+}
...
+.search-results .search-info {
+  font-size: 0.85em;
+}

I think font-size should be in theme.css

+++ b/modules/search/search.theme.css
@@ -0,0 +1,15 @@
+.search-results {
+  list-style: none;
+}

If I look at system.module example, it may move to base.css. It provides base behavior style ?

jyve’s picture

FileSize
2.48 KB

I agree with most of the feedback from droplet, but have taken it a little further. Most of the css can be removed imo, since it makes useless assumptions about margins, paddings and font-size. Removing that css did not change anything in Stark, and almost nothing in Bartik (only font-size on the search result header).

Attached is a new patch.

Jacine’s picture

Status: Needs review » Needs work
FileSize
212.77 KB
214.16 KB
231.38 KB
232.93 KB
176.84 KB
177.34 KB

This is an awesome cleanup @jyve.

+++ b/modules/search/search.base.cssundefined
@@ -0,0 +1,4 @@
+
+.search-results {
+  list-style: none;

I'd actually expect to see a numbered list here when I remove .theme.css files. It's not exactly a structural or behavioral requirement, so I think this should go in the search.theme.css.

+++ b/modules/search/search.theme.cssundefined
@@ -0,0 +1,9 @@
+.search-advanced .action {
+  clear: left;

This should have a LTR comment.

After that stuff is fixed, this is RTBC in my book. I've also attached before and after screenshots. It's pretty amazing how much garbage code we have. The differences are teeny tiny. Nice work! :D

jyve’s picture

Status: Needs work » Needs review
FileSize
2.27 KB

Thanks for testing @Jacine :) It does feel good to get out a pile of useless css.

New patch attached with your feedback!

Jacine’s picture

Status: Needs review » Needs work

@jyve Sure no problem. Sorry I didn't end up having time for more. Per the other issue, we're gonna have to add the appropriate comments. Basically we need a @file block at the top, and I think the rest is self-explanatory. Hopefully @sun will agree.

jyve’s picture

Status: Needs work » Needs review
FileSize
2.5 KB

A @file block was added at the top, together with block group headers, just to be on the safe side :)

jyve’s picture

FileSize
2.49 KB

updated the wording just a tiny bit.

xjm’s picture

Status: Needs review » Needs work
Issue tags: +Novice

Thanks for your work on this patch! Note that the Drupal 8.x patch will need to be rerolled, because the core directory structure for Drupal 8 has now changed. (For more information, see #22336: Move all core Drupal files under a /core folder to improve usability and upgrades). When the patch has been rerolled, please set the issue back to "Needs Review."

Tagging as novice for the task of rerolling the Drupal 8.x patch.

If you need help rerolling this patch, you can come to core office hours or ask in #drupal-gitsupport on IRC.

BBommarito’s picture

Assigned: Unassigned » BBommarito
BBommarito’s picture

Assigned: BBommarito » Unassigned
jyve’s picture

Assigned: Unassigned » jyve
Status: Needs work » Needs review
FileSize
2.57 KB

Rerolled the patch to match the new folder structure.

aspilicious’s picture

Status: Needs review » Reviewed & tested by the community

Tested, and reviewed, jacine already approved this.

NCE!

catch’s picture

Status: Reviewed & tested by the community » Fixed

Lovely, lovely minuses.

Committed/pushed to 8.x, thanks!

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Updated issue summary.