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 guidelines extracted from CSS file organization (for Drupal 8):

    CSS files for Drupal modules

    All of a module's styles should be placed in a css/ sub-directory and broken into one or more of the following files:

    module_name.module.css: This file should hold the minimal styles needed to get the module's functionality working. This includes layout, component and state styles. Any needed RTL styling would go in a file named module_name.module-rtl.css.

    module_name.skin.css: This file should hold extra styles to make the module's functionality aesthetically pleasing. This usually just consists of skin styles. Any needed RTL styling would go in a file named module_name.skin-rtl.css.

    module_name.admin.css: This file should hold the minimal styles needed to get the module's admin screens working. This includes layout, component and state styles. On admin screens, the module may choose to load the *.module.css in addition to the *.admin.css file. Any needed RTL styling would go in a file named module_name.admin-rtl.css.

    module_name.admin.skin.css: This file should hold extra styles to make the module's admin screens aesthetically pleasing. This usually just consists of skin styles. Any needed RTL styling would go in a file named module_name.admin.skin-rtl.css.

    Note: Modules should never have any base styles. Drupal core's modules do not have any base styles. Instead Drupal core uses the Normalize.css library augmented with a drupal.base.css library.

    If a module attaches a CSS file to a template file, the CSS file should be named the same as the template file, e.g. the system-plugin-ui-form.html.twig CSS file should be named system-plugin-ui-form.css

  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

tars16’s picture

Status: Active » Needs review
FileSize
1.53 KB

It seems pretty straight forward to move both of these styles to help.admin.css, and help.admin-rtl.css.

Do we want/need to keep this in a 4 column layout? I think it should stay since the module list for most sites gets pretty long.

Status: Needs review » Needs work

The last submitted patch, 1217004-help-css-clean-up-1.patch, failed testing.

tars16’s picture

Status: Needs work » Needs review
FileSize
2.94 KB

Added changes to help.test and updated the drupal_add_css in help.admin.inc

Patch should fail again because it's still looking for help.css right?

Status: Needs review » Needs work

The last submitted patch, 1217004-help-css-clean-up-2.patch, failed testing.

tars16’s picture

After the html5 meeting this afternoon and thinking about the css on the help page, we could eliminate the css for this module all together if we simply modified the help list to match the 2 column list on the configuration page.

I don't know if it goes beyond the scope of this issue but I think it helps to add some consistency!

I've attached a screenshot of what I was thinking along with the patch that would get it to that point.

We would need to add a 'first' class to the first li of each row in order to get rid of the border top or we could think of something to place at the head of each column.

In lieu of getting the description from the about page for each individual help topic (not sure if there is a way to grab that with the way it's constructed) I used the module description to fill out the list a bit.

Thoughts?

jyve’s picture

Getting the layout of the help page in line with the configuration page seems like a great idea to me!

I don't think the 'first' class is a good idea, since the border is added in the admin theme (Seven in this case) so we cannot have a fix for this in the help module. Simply adding a title would be clutter for the page so maybe removing the 'admin-panel' div is a better solution. This would give the same layout as the /admin page.

Minor issue in your patch: there is trailing whitespace in line 59 of help.admin.inc.

aspilicious’s picture

I don't think it's a good idea to put everything in one long list as jyve suggests in his latest comment.

Hmmm, we should discuss this in the next HTML5 meeting.

rteijeiro’s picture

Any news about this issue from the HTML5 meeting?

rteijeiro’s picture

Issue summary: View changes

Updated issue summary.

pakmanlh’s picture

Status: Needs work » Fixed

Obviating the new changes proposed, it seems that all changes that this issue mentioned have been implemented.

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

Anonymous’s picture

Issue summary: View changes

Updating the summary to the latest CSS organization guidelines.