Improve the CSS layout framework for Drupal's admin interface

Created on 15 April 2015, about 10 years ago
Updated 13 May 2025, 4 days ago

Problem/Motivation

The admin interface in Drupal is moved to become more component based, influenced by our CSS coding standards β†’ and The Seven style guide. This is beneficial for multiple audiences:
Module developers who have to write and maintain less CSS across browsers and devices.
Admin theme maintainers need less effort to support the large number of contrib modules.
Frontend developers need to maintain less CSS in core and contrib.
End users also has a more consistent a higher quality experience.

Based on discussion within this ticket and from πŸ“Œ Replace content creation page layout CSS with reusable layout classes Postponed: needs info and #2017257: Create generic layout classes β†’ with @axe312 and @LewisNyman we have an idea to improve the reusable layout framework for Drupal's admin interface.

On couple of places we already use simple grid layout classes which were added in #2298821: Move generic layout styling into system.admin.css β†’ and moved to system.admin.css in #2298821: Move generic layout styling into system.admin.css β†’ . The implementation is simple but it has limited support for complex use cases (no nesting support, gutter inconsistency, only 3 and 4 columns support, no pull/push and offset features, etc). Improving the flexibility of the layout classes would make this framework more useful in core and contrib.

Proposed resolution

  • Create a library called system/admin.layout. Admin themes, including Seven, can require the library if they want it. Core and contrib modules can also require and use the library.
  • Maintain the current complex layouts introduced in core but rename them to be more generic and reusable.
  • Audit contrib for complex layouts we could add to the framework
  • There is only one breakpoint for now for small screens - for now it will be on 38em what current Drupal layout css is using. We can add more over one with more testing.
  • Inline with our CSS standards, all layout classes should be prefixed with .layout-
  • Add a flexible and highly reusable utility classes that allow modules to easily layout columns of equal width.
    We need this to maintain a consistent layout in the backend which works in every supported browser. Most modules are developed by pure backend developers which do not want and can stuggle with css layout issues.
  • Other utility classes that can also be used to adjust the layout for different use cases are: .layout--gutters - Adds simple gutter to the layout (e.g. /admin/config) , .layout--big-gutters - adds a bigger gutter to the layout (e.g. /node/XYZ/edit) , .layout--equal-heights - make the container equal height, e.g. for the new search api filters
  • HTML + CSS Demonstration: http://codepen.io/axe312/pen/BNBBgN?editors=110
  • For core modules, the classes should should added in Classy admin templates, so admin themes that require Classy will have these classes. Admin themes can choose to rely on Stark if they want a clean slate.

Remaining tasks

  • Discuss and refine this proposal and find a solution everybody is happy with.
  • Create the library which contains the layout CSS
  • Update the markup so the framework classes are in use in the admin template

User interface changes

The layout of the user-interface should mostly stay the same, with maybe a slight change in gutters or breakpoints.

API changes

None

πŸ“Œ Task
Status

Postponed: needs info

Version

11.0 πŸ”₯

Component

CSS

Created by

πŸ‡·πŸ‡ΈSerbia pivica

Live updates comments and jobs are added and updated live.
  • CSS

    It involves the content or handling of Cascading Style Sheets.

  • stale-issue-cleanup

    To track issues in the developing policy for closing stale issues, [Policy, no patch] closing older issues

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Thank you for creating this issue to improve Drupal.

    We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

    Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

    Thanks!

Production build 0.71.5 2024