Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
In #2017257: Create generic layout classes we added some generic layout classes to Seven. The intention is to allow modules to layout complex admin pages without needing to write their own CSS. We replaced some custom layout CSS in core with these reuseable classes.
As a side effect, the admin/config page in Stark no longer has a layout.
Proposed resolution
We should decide whether admin pages in Stark should have layout, which means these layout classes should be universal across all admin themes, or if they should stay in Seven.
This issue is not about adding a grid framework to Drupal core's default output, this is a DX improvement for the admin interface only.
Remaining tasks
Decide whether these layout classes should stand across admin themes.
If so, add the layout rules to system.admin.css or an equivalent.
User interface changes
Admin layout in Stark
API changes
None, unless you count reusable CSS classes as an API
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | Screen Shot 2014-10-04 at 15.09.53.jpg | 579.47 KB | LewisNyman |
| #9 | Screen Shot 2014-10-04 at 15.09.15.jpg | 511.61 KB | LewisNyman |
| #9 | 2298821-move-layout-classes-9.patch | 1.96 KB | LewisNyman |
Comments
Comment #1
LewisNymanI'm a little torn here, it makes sense for developers to assume their layout is permanent across admin themes. I really don't want to start conflicting with grid systems that other themes use though.
Comment #2
joelpittetI'm kind of on torn as well. The intent is to be able to have just enough structure to be able to style this in a future theme and in the past there has been quite a bit of extra styles added to system.*.css files that I've always had to remove forcefully to get to a base. (especially menu item leaf styles and spinner styles being my number one things to remove so it doesn't "look" like a drupal site)
Could I propose (if possible) to have some minimalistic layout styles just for stark that we can lightly maintain without adding them to all themes? not sure how maintainable that would be but if we kept them as succinct as what *was* in core everywhere, maybe that would be reasonable for stark? Would that fit the bill?
Comment #3
LewisNymanI think we need to be careful about adding anything to Stark. We talked a lot about Starks purpose in Austin. It should really be a true window into core. If we added it to system.admin.css that limits it to the admin interface only? So that would be less intrusive then adding it to the whole of Stark.
Or we could decide that Stark should never have layout. It would be a UI change from how it works in D7, because as modules write their own layout CSS they do apply across all themes.
Comment #4
chx CreditAttribution: chx commentedI am fine with the new layout if it's decided and clearly communicated that minimal is, well, minimal. As long as it's usable and you never need to waste your time with install standard while developing core (which was the pact when minimal was created), we are good.
Comment #5
LewisNymanIf we take this decision to it's conclusion, then the content creation screen, block UI, and Views UI shouldn't have layout in Stark either. It would be nice to get a VDC team perspective on that.
Comment #6
chx CreditAttribution: chx commentedHold your horses :) the admin screen two columns is a sort of fluid layout -- if something is on the left or the right it doesn't matter because you can't train yourself on the position anyways because as you add more contrib modules the position changes anyways. Nothing much is lost if it becomes a single column: you mostly navigate that page by search anyways. There's too much information there usually to do anything else. (500 modules clients. Yes. We have one.)
But the Views UI is a very fixed layout which people do train themselves on, it's visually navigated and it doesn't really yield to searching too well either.
Comment #7
LewisNymanI don't think this is a usability issue for two reasons, all UI has to be usable on mobile so it all has to work on one column. I don't think people who care a lot about usability should use Stark, because I don't think Stark should be that opinionated around affordances. This is inline with our plan in #2289511: [meta] Results of Drupalcon Austin's Consensus Banana.
The intention of adding these generic grid classes is so core and contrib developers don't have to write and maintain their own layout CSS over and over.
Bearing that in mind, if a module developer decides to set layout then it should stand irrespective of the theme and maintain that intent in the same way it does if they were writing their own layout CSS. We should keep this consistent across the whole UI, so if the Views UI maintains layout across themes so should everything else in the admin interface.
Also, from what I can tell from the D8 layout stuff, layouts can be independent of themes. So this makes sense. I think if we load this CSS for the admin side only we won't anger the Mortens of this world.
TLDR: Let's move the layout classes to an admin only CSS file. Objections?
Comment #8
LewisNymanTurning this in an actionable issue based on Alex's comment in #2337317: Replace help page layout CSS with reuseable layout classes
Comment #9
LewisNymanPatch! Here are some screenshots of the config page layout applying in both Stark and Seven.
Comment #10
LoMo CreditAttribution: LoMo commentedLooks the same on my installation, too. This patch applies. After clearing all caches and setting Stark as the admin theme, I can see the layout is the same as the screenshot. Looking good for RTBC. :-)
Comment #11
rteijeiro CreditAttribution: rteijeiro commented+1 RTBC
Comment #12
webchickJust a question. Since the source CSS file is "layout.css", should we move this stuff into a system/layout.css or similar which makes it easy to override them if you want something different?
Comment #13
LewisNymanI would rather keep it in admin, because I want to avoid any assumptions that we are providing a CSS layout framework for the frontend. This is just a helper to build admin interfaces for module developers.
I think it would be great to break up all of the system CSS files into components like we have done for Seven, but let's leave that conversation for another issue.
Comment #14
webchickOk that works.
Committed and pushed to 8.x. Thanks!
Comment #17
Gábor HojtsyThanks, removing from UX sprint now.