Part of the CSS Cleanup: http://drupal.org/node/1089868
Overview of Goals
- Make it easy to remove unwanted design assumptions in the theme layer, while maintaining critical functionality (such as functional JavaScript widgets).
- Prevent uneeded administrative styles from loading on the front end.
- Give modules the ability to include a generic design implementation with their module, without burdening themers.
- 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.
- 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 namedmodule_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 namedmodule_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 namedmodule_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 namedmodule_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
- 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.
- 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 {}
overdiv.style {}
where possible. - Use
.module .style {}
overdiv.module div.somenestedelement .style
where possible.
- Use
- 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.
- 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.
- Start with Stark and cross-browser test.
- "Design" markup and CSS for the Stark theme.
- If applicable, adapt the styles to match the core themes afterward.
- Finally, test the changes in all supported browsers and ensure no regressions are introduced.
Comment | File | Size | Author |
---|---|---|---|
#12 | locale-module-css-cleanup-1217008-12.patch | 2.99 KB | rteijeiro |
#10 | 1217008-locale_module-css-clean-up-10.patch | 697 bytes | oresh |
#4 | locale-module-css-cleanup-4.patch | 5.02 KB | aspilicious |
#1 | locale-module-css-cleanup.patch | 6.59 KB | aspilicious |
Comments
Comment #1
aspilicious CreditAttribution: aspilicious commentedFirst patch. Probably need to rename the base.css to admin.css.
This feels like we are duplicating a lot of code in the themes. Is that the goal? Moving stuff out of core into themes.
Comment #2
aspilicious CreditAttribution: aspilicious commentedComment #3
aspilicious CreditAttribution: aspilicious commentedYou cannot change the structual design. AKA leave the admin theming in most cases :)
Comment #4
aspilicious CreditAttribution: aspilicious commentedOk this is a better starting point
Comment #5
aspilicious CreditAttribution: aspilicious commentedComment #7
aspilicious CreditAttribution: aspilicious commented#4: locale-module-css-cleanup-4.patch queued for re-testing.
Comment #8
jyve CreditAttribution: jyve commentedTested the patch in #4. This is my feedback:
- All css in locale.theme.css should be removed imo:
As a good example for this: these colors are being overwritten in Bartik and will be so in most themes.
- At least the line-through on the user interface translation screen should go into the locale.base.css as that is basic behaviour, not stlying:
Comment #9
aspilicious CreditAttribution: aspilicious commentedBase css doesn't exist for admin. As this is admin only, it should be in admin.css
I talked about base.admin before but we don't have it (yet) in core.
i'm not sure we should remove the coloring:
" overwritten in Bartik and will be so in most themes."
Most themes != every theme
We need more opinions on this.
Comment #10
oresh CreditAttribution: oresh commentedVery useful CSS cleanup.
Comment #11
rteijeiro CreditAttribution: rteijeiro commentedWe should reduce the selector specificity, so I guess we should change:
#locale-translation-status-form th.select-all
to.locale-translation-status-form .select-all
The same for the other selectors in the locale.admin.css file. Am I right?
Comment #11.0
rteijeiro CreditAttribution: rteijeiro commentedUpdated issue summary.
Comment #12
rteijeiro CreditAttribution: rteijeiro commentedRe-rolled with the latest changes.
Comment #13
pakmanlhMigrated to the sandbox here #2030459: Clean up the CSS for Locale
Comment #13.0
pakmanlhUpdating summary to the latest CSS organization guidelines.