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

_Cedric_’s picture

Assigned: Unassigned » _Cedric_
chrispomeroy’s picture

i was researching this issue and noticed that in overlay-child-rtl.css, this is in the css:

#overlay-tabs li {
  margin: 0 -3px 0 O;
}

I think that is the letter O?

Is that some weird css hack or is it a mistake?

David_Rothstein’s picture

Ha! Nice catch. Yeah, definitely looks like a bug.

Probably better to file it as a separate issue, though, because that's a simple fix (whereas this issue is about more far-ranging changes to the CSS).

chrispomeroy’s picture

ok cool, i filed it under #1326950: typo in overlay-child-rtl.css

cosmicdreams’s picture

Assigned: _Cedric_ » cosmicdreams

I'll take a shot at this. Patch forthcoming

cosmicdreams’s picture

Got started, There are a lot of IDs here:


<?php print render($disable_overlay); ?>
<div id="overlay" <?php print $attributes; ?>>
  <div id="overlay-titlebar" class="clearfix">
    <div id="overlay-title-wrapper" class="clearfix">
      <h1 id="overlay-title"<?php print $title_attributes; ?>><?php print $title; ?></h1>
    </div>
    <div id="overlay-close-wrapper">
      <a id="overlay-close" href="#" class="overlay-close"><span class="element-invisible"><?php print t('Close overlay'); ?></span></a>
    </div>
    <?php if ($tabs): ?><h2 class="element-invisible"><?php print t('Primary tabs'); ?></h2><ul id="overlay-tabs"><?php print render($tabs); ?></ul><?php endif; ?>
  </div>
  <div id="overlay-content"<?php print $content_attributes; ?>>
    <?php print $page; ?>
  </div>
</div>

I started going through the process of reducing the number of ids. Here's what I'm considering after the refactor:


<?php print render($disable_overlay); ?>
<div id="overlay" <?php print $attributes; ?>>
  <div class="titlebar clearfix">
    <div class="title-wrapper clearfix">
      <h1 class="title"<?php print $title_attributes; ?>><?php print $title; ?></h1>
    </div>
    <div class="close">
      <a href="#" class="overlay-close"><span class="element-invisible"><?php print t('Close overlay'); ?></span></a>
    </div>
    <?php if ($tabs): ?><h2 class="element-invisible"><?php print t('Primary tabs'); ?></h2><ul class="overlay-tabs"><?php print render($tabs); ?></ul><?php endif; ?>
  </div>
  <div class="content"<?php print $content_attributes; ?>>
    <?php print $page; ?>
  </div>
</div>

In my view, there should be only one id, "overlay" for the element that begins and encapsulates the other things that makeup the overlay.

Then I need to adjust the styles accordingly. Sound like a good plan?

Also, should we be concerned about css namespacing issues? Like I totally see another module make an overlay and what to use the css id "overlay" for it. Should we name css ids in core like this: drupal-overlay?

cosmicdreams’s picture

My focus has been elsewhere in regard to HTML5 patches. But I'm bumping this so I can work on this issue tonight. I hope to produce a patch based on the plan I out lined above.

cosmicdreams’s picture

My focus has been elsewhere in regard to HTML5 patches. But I'm bumping this so I can work on this issue tonight. I hope to produce a patch based on the plan I out lined above.

cosmicdreams’s picture

FileSize
19.4 KB

OK, so.... here's a patch that may probably will get conversation started. Here's a rundown of what I did:

  1. sorted overlay-child.css into two css files (base and admin)
  2. modified the markup for overlay to only have one div
  3. modified the javascript to respect the one div
  4. modified all other parts of the module to also respect the one div
  5. Help: couldn't find the tests for overlay
cosmicdreams’s picture

Status: Active » Needs review
aspilicious’s picture

Status: Needs review » Needs work
+++ b/core/modules/overlay/overlay.tpl.phpundefined
@@ -22,16 +22,16 @@
-  <div id="overlay-titlebar" class="clearfix">
-    <div id="overlay-title-wrapper" class="clearfix">
-      <h1 id="overlay-title"<?php print $title_attributes; ?>><?php print $title; ?></h1>
+  <div class="titlebar clearfix">
+    <div class="title-wrapper clearfix">
+      <h1 class="title"<?php print $title_attributes; ?>><?php print $title; ?></h1>

You're not rly removing any div's. So the markup is not rly changed.
And we need a way to test "function overlay_disable_message()".
I'll functional test this some more today or tomorow.

23 days to next Drupal core point release.

aspilicious’s picture

Status: Needs work » Needs review

Whoops, needs review

oresh’s picture

Issue tags: -html5, -Front end

#9: 1217030-9-overlay.patch queued for re-testing.

@aspilicious ,
if you can, please write a test for function overlay_disable_message() in fat module

Status: Needs review » Needs work
Issue tags: +html5, +Front end

The last submitted patch, 1217030-9-overlay.patch, failed testing.

Anonymous’s picture

Issue summary: View changes

Updated issue summary.

helenasue’s picture

Assigned: cosmicdreams » Unassigned
Status: Needs work » Needs review
FileSize
23.79 KB

Didn't change the css filenames to the new convention - just went through and swapped out the ids for classes.

This patch was created as a part of the code sprint at #dcATL.

The last submitted patch, overlay-change-ids-to-classes-1217030-15.patch, failed testing.

alexdmccabe’s picture

Status: Needs work » Needs review
alexdmccabe’s picture

Issue summary: View changes

Updated summary to the latest CSS organization guidelines.

nod_’s picture

Version: 8.x-dev » 7.x-dev
Issue summary: View changes
Status: Needs review » Needs work

Overlay is dead to D8 #2088121: Remove Overlay.

longwave’s picture

Status: Needs work » Closed (won't fix)

We cannot change this in 7.x now.