Improve the CSS layout framework for Drupal's admin interface

For rapid prototyping of our idea I created a Codepen which demonstrates the possibilities of the grid. It covers the whole specification and we can use this for cross-browser testing and as a markup demonstration.

The jade and sass code is just a quick implementation of the spec above, the final solution will use mixins for cleaner and more flexible code.

http://codepen.io/axe312/details/pvMKaE/ (edit)

I would strongly strongly strongly recommend against including this in core. A class-based grid system is highly inflexible in responsive design. When one of the primary initiatives for a Drupal 8 is to be friendly for mobile, this is not the way to do that. If somebody wants a contrib theme for this, fine, but not core.

So how to fix the problem of inflexible styling/layouting especially the Drupal backend without grid @mdrummond?

We are already implementing some classes for general layouting. But these are limited and after just one ticket it turned out we need some "hacks" and add some more modifier classes to achieve the layout. At the moment we can not even stack layout-containers into each other without doing some magic/extra classes.
See #2017257: Create generic layout classes, #2335525: Replace appearance page layout CSS with reusable layout classes, #2335523: Remove node.module.css from node/drupal.node library and deprecate node/form library and #2335531: Replace block placement page layout CSS with reusable layout classes

The proposed solution covers all (~4) different kind of layouts we currently have, supports way more, is nestable and IMHO thats a very sane implementation which won't break other grid systems. Also you don't have to use it in your (frontend) theme, you can just not use the library.

If we do not rely on classes, we could restore all the code from #2017257: Create generic layout classes and get back to the beginning with custom media queries and layouts for every page.

What I also want to mention, we are trying to add here approx. 50 lines of easy to read and understand css code. This is not a special grid system with hundreds lines of code and non-cross-browser compatible css magic.

- sorry double post -

Please Dont do this to Drupal Core.
Heres the thing we know that whatever we put into core today that will bethere in 5 years: 2020, lets say that something changes like the way we build a layout (kinda what happend when that responsive came) then were stuck deep into col2 row3 class names that defines layouts in a certain way.
We DONT want that!!! and by DONT i mean not ever ever ever ever into core - its gonnna be a very cold day in hell we do the same mistakes that have been done a ton of times before in drupal.

You basically solve a problem right now that we then in about to years will be very frustrated about - as an example there was a huge push for putting 960grid into Drupal8 as the Default way of doing layouts ... which make sense in 2012 when it was proposed. Imaging that build deep into core today, so first thing you had to do was to battle with 960 (which btw is a great system)

Lets Not go for "everybody do this right now" solutions - when DrupalCore have to stand tall in a frontend world where we have no idea whats gonna come in the future.

I can follow Mortendk on this one.

Is there a possibility that we can use the grid system to style backend-pages-only where needed, so the themes become perhaps a bit more maintainable?
I can see myself trying to overwrite these classes when theming... and then the chaos begins.

>>Please Dont do this to Drupal Core.
Agree with this. Let's leave the choice for the developers. What if I love susy / etc semantic-based layout development? What if I don't want unset core grid css every time?

It should be in contrib, there is the right place for grid systems. Let there be a lot of options and freedom of choice.

@MathieuSpil that was one of the intentions when implementing that grid as a core library. It will be used for basic backend styling, but you do not need to use it at all on your theme. No matter which layout structure we may implement, themers will always overwrite and/or replace it. That might even be the best way to go, let Drupal use the basic grid and "on the frontend", implement the fancy sass solution.

@Mortendk, @adubovskoy: I get your point, but what we are currently doing with the .layout-container and .layout-column class introduced in this commit is IMHO nothing else than just a slim (and worser) grid. We are adding classes which stuck us to a specific naming scheme to layout the page.

I also want to mention that at lunch some people working on #searchapi really liked the idea to have generic classes to layout the output of the search api in the backend (I have no clue which specific page they were talking about, but really liked the idea)

Basic grid system as a library used by backend would be great and when you need that really in your own theme then just add the library and you can start using the grid.

I think there are so many custom CSS rules in core so a generic approach should be absolutely okay :/

@axe312: You have my vote if we can be sure we can shield this off for backend-pages only. And where the exception is including it as yannickoo mentioned.

In personal talk with some devs over here in Montpellier that this feature will be a huge helper for the backend. Frontend integration is a no-go for almost everybody.

So the original introduction of the classes in #2017257: Create generic layout classes was for the Seven theme, and the movement from Seven to system.admin.css took place in #2298821: Move generic layout styling into system.admin.css.

I think that we should keep the scope of this issue to providing layout classes for the admin interface, so module developers don't have to write CSS. I think that introducing a grid framework for everything built with Drupal, that we have to maintain for many years, is a tough suggestion. Especially considering the rate of evolution of preprocessor grid systems.

I'm happy to expand and improve on the current grid system to make it more useful, but I don't think we should expand the scope.

@pivica:
You are missing "box-sizing: border-box;" on the .drupal-col-* classes. Also "position: relative" on .drupal-col-pull-* and .drupal-col-push-*
Also i don't see any .drupal-*-hidden classes. The rest of the generated css looks good so far. (Did not look at the sass yet)

I'm not a designer so I don't understand the deeper reasoning behind having that or not, but I can confirm that having any kind of generic solution for this in Drupal would be a help for us in the Search API. We're currently also trying to implement a three-column layout there, for processing stages, but haven't been able to implement this correctly yet (see screenshots).

This isn't just couple hundred lines of CSS, it also requires all of these HTML classes to be added to templates as well. The issue summary says that templates in Classy are being targeted, not just Seven templates.

Just because Bootstrap does this does not mean it's a good approach. Bootstrap is a prototyping tool that is unfortunately being used to build production sites. Adding some presentational layout classes to HTML to quickly mock up a design, fine. But doing so on a production site results in a brittle design. Now if you want to change your design you have to not only change your CSS, you have to change your HTML a as well.

What makes classes like col-3 (or col-half which is apparently already in core) is that it's taking the layout for a particular viewport and putting that in HTML. Will you have 12 col at a 320px viewport? Assuredly not.

Good responsive designs shift at far more than one breakpoint, they shift where the content no longer works. That could be two times, four times, ten times. One HTML class cannot capture that nuance.

Layout classes like these exist so that people can change the layout without writing CSS. But layout SHOULD be changed in CSS.

That is much more straightforward to do with a preprocessor grid system for Sass like Susy, but we aren't using Sass in core. I'm sympathetic to the fact that this is challenging without Sass, but I don't think this is the right solution.

I would even get rid of the col-half classes and work to control those layout decisions in CSS. Is it more work? Yes. But it makes the site more flexible.

It's very frustrating for front-end folks to have override and remove so many classes from core, and this would explode the amount of work like that which would need to be done. That makes building a site more expensive.

Can somebody explain why there is this huge desire to control layout via HTML rather than just writing some CSS?

@mdrummond Because there are many module developers who want to build a usable interface for their modules but don't have frontend support to write it themselves in CSS. This is more than just layout, this is built into the architecture of the Seven theme and inline with our CSS standards. For more information, see: Changes to Drupal 8 that affect admin theme maintainers

...this is built into the architecture of the Seven theme...

This is what I don't understand, not having seen the issues that got here, are people trying to solve a core problem or a Seven problem? Seven can do what it wants in the role of the default admin theme, but why does this need to move to core? If a module loses layout support because a site uses a different admin theme, so what? Let the other theme worry about handling it.

The issue summary says that templates in Classy are being targeted..

Please no. Has there been thought put into what that would be like to maintain, not to mention work with - for people that copy the templates.

I had a long talk with @fubhy about this and he partly convinced me that a semantic based layout system is a better way to go. For example .layout-admin-backend might trigger the 2 column layout we have on admin/configure

I'll try to create a list of pages affected by this with a name convention proposal for the semantic layouts now. So both ways are easier to compare.

Feature requests are not going into 8.0.0

I think this is CSS code refactoring and improvements. A basic grid system already exists, we would just be improving it.

I would really appreciate if developers and "I'm not a frontender" people would read up on the agreements that we've come through over the last 3 years in getting twig into core @ cleaning up the basic concept of Drupal7 & why Drupal8 is such a huge step forward for frontenders.

look at the consensus banana & the points to guide us.
this is not a thing we discussed over lunch at an event this is 500+ frontenders all over the world for years that have worked hard to make the theme layer good for frontenders

if you don't understand why a grid system as we know ala grid960, bootstrap, Suzy & it's many copy's is not the future then please read up on flexbox, in a very short time the way we think & build layouts will completely change . by feeding any kind of CSS layout system into drupalcore were destroying it for our self in the future - this is essential to understand!
everything will change - we must be able to move with the Frontend & not lock ourself down in whatever Frontend solution somebody loves right now.

This is a feature request that is directly against everything we have agreed upon the last many years & tbh I'm shocked over this :(

if you want to improve whatever seven does - go ahead and do that & add in whatever templates & classes you want it will be a great showcase for noobs to see howto customize themes.

nothing that's not really needed goes into classy - the madness of adding in already dead concepts is over !
sorry but this is complete misunderstanding of the theming system to put any kind of layouts into core.

don't polute what we are trying to clean up - pretty please

So when we are going for an semantic approach instead of using a grid system to clean up the layouts, we would need to create layouts for the following pages and make them reusable:

/admin/configure
/node/add/*
/admin/structure/block
/core/install.php

Here is a codepen which covers all the layouts including the inconsistent styling Drupal core has at the moment. It also tries to show how the semantic code/markup could look like.

Personally I'd skip the Installer layout from making it semantic, because its a very specific design case. The others have way higher potential to be used again.

Basically we "just" need to agree on the naming for these layouts to make them reusable, remove the .layout-container code from #2298821: Move generic layout styling into system.admin.css and change some classes in the twig templates.

This would mean:

• No (probably soon outdated) grid class based layouts. We could even switch to flexbox later on without changing any markup.
• We no more need to hack the .layout-container implementation to produce the layouts we need, since we have custom ones for every layout
• We still can clean up the layout to make it more consistent. (One big point in my opinion is to use two sided gutters since these do not disturb the column width ratio)
• We are still missing a solution which can be used by core/contrib module developers without frontend experience to layout their modules. For this we can use a flexbox based solution which allows you to align containers just next to each other. But if we go for a semantic solution, this is another follow up ticket.

@axe312 At first glance, the way layout is being handled in the pen looks very nice.

I appreciate the problems you and @pivica are trying to solve. It looks like there may be some good ways to make this work that can improve things both for front-enders and for module developers.

It's all about making things flexible and understandable. I can definitely appreciate the desire for module developers to have an easily understandable way to put things in different areas in a layout. Clear understandable class names like those in the Code Pen can hopefully be useful for that. Having labels like primary and secondary and footer, coupled with clear documentation, is useful, because it is more flexible to switch out the underlying CSS as necessary down the road. If we want to use flexbox or the native CSS grid tools that are being specced/implemented, then that might be possible.

This would all be easier if we had Sass to work with in core, but we don't alas.

Thanks for everybody's work on this.

If we want to use flexbox or the native CSS grid tools that are being specced/implemented, then that might be possible.

Indeed! Down the line we could swap out the technology for more modern solutions without anyone being any the wiser.

This would all be easier if we had Sass to work with in core, but we don't alas.

Yes, if we could use Sass in core, or even CSS variables, we could do a lot more. It feels little bit antiquated but using applying classes is the next best thing if we don't have a framework of Sass mixins to easily recreate the UI.

This is a feature request that is directly against everything we have agreed upon the last many years & tbh I'm shocked over this :(

No, this isn't about frontend themes, this is about admin themes. This is exactly what the maintainers of admin themes want. This is also what Drupal's UI needs in order to be more consistent and predictable.

The proposal in #34 is less useful for what we have now. It's too specific to one usecase, which means it's not very reusable. It also doesn't solve the Search API contrib need stated in #23

The proposal in #34 is less useful for what we have now. It's too specific to one usecase, which means it's not very reusable. It also doesn't solve the Search API contrib need stated in #23

That codepen in #34 is just a list of the styles we currently have. I am working on a new one, covering the layouts from #34 and proposing a solution for the multi column layouts module maintainers need like in #23. Just give me some more time, ill post it today.

@axe312 too bad i was not able to be with you guys on that talk... you want maybe to update me tomorrow about semantic idea approach and also to figure it out how to procede with this issue what ever come on the end of it grid or semantic aproach? We can talk over irc or skype/ hangout talk - what ever is better.

Yes, we can. Just lets connect via IRC and I give you the details :) - But this should also be documented and written down for other people, maybe we can create a documentation post later on why we decided to do Drupal layouting the way we discuss here in the issue.

tl;dr -> codepen.io/axe312/pen/BNBBgN

Here we go, this is my new proposal for layouts named the semantic way.

Also it does not cover only the layouts we currently have, it also gives module developers the possibility to place elements on their forms and admin pages next to each other. This was one of the biggest reasons we came up with the grid.

At the moment it uses a mixture of flexbox and floating, but I will add fallbacks for non-flexbox browsers and do cross browser testing including screenshots later on.

Almost any browser in our support list does support flexbox, for the few which doesn't it will be easy to implement css fallbacks.

The resulting css code is very slim (With empty lines below 100 lines) and a improvement of the classes which are already implemented in core now.

Short overview:

Basic classes

• .layout-container - Basic class for the wrapper to tell the website, the childs will be next to each other. This is required for every layout since it does the clearfix. (Similar to the .row class in many grid systems)
• .layout-column - Use this class to mark a element as part of the layout. Basically just applies „box-sizing: border-box;“ to avoid troubles with gutters/padding.

The layouts

• .layout-small-secondary & .layout-slim-secondary - These are specific layouts. These two represent the layouts we currently have for content edit and the block overview page.
• .layout-equal - The columns of this layout will have an equal width. Use modifiers to tell the css how many items you want to align next to each other on the maximum viewport. Modifiers: .layout-equal—two, .layout-equal—three and .layout-equal—four (Of course we may add more)
• .layout-flexible - Like the .layout-equal, just it does not need any modifiers. It currently only works with flex box, but we may find fallbacks for this. (Using a fake table or „display: inline-block; text-align: justify“ + a forced line break)

The layout modifiers

• .layout—gutters - adds 1em gutters for the admin/config etc.
• .layout—big-gutters - adds 2em gutters for the content edit form
• .layout—equal-height - super simple and easy feature, only works on browsers with flex box, but I think we can ignore this regression for IE 9. (Well, adding a JS to cover this should be no problem, but I am not a fan of these „useless“ polyfills.)

Code examples

Content edit form

<div class="layout-container layout--small-secondary layout--big-gutters">
  <div class="layout-column layout-column__primary">
    <p>The actual edit form</p>
  </div>
  <div class="layout-column layout-column__secondary">
    <p>The form sidebar</p>
  </div>
  <div class="layout-column layout-column__footer">
    <button>save and publish</button>
    <button>preview</button>
  </div>
</div>

Block overview

<div class="layout-container layout--slim-secondary layout--big-gutters">
  <div class="layout-column layout-column__primary">
    Table of active blocks
  </div>
  <div class="layout-column layout-column__secondary">
    List of available blocks
  </div>
</div>

Equal width layout for the contrib module devs

<div class="layout-container layout-equal layout-equal--three layout--gutters">
  <div class="layout-column">
    First column
  </div>
  <div class="layout-column">
    Second column
  </div>
  <div class="layout-column">
    Third column
  </div>
</div>

Here is the link to the pen: codepen.io/axe312/pen/BNBBgN

I have actually had the need exactly for this on a real Drupal project: I created a custom entity type and I wanted to have exactly the same layout with a sidebar as node forms. It would be nice to be able to do that without referencing the node module.

I am so sorry, I posted the link to the wrong Codepen.

This one includes the actual semantic layout proposal, the one from #41 was just the layout overview from above. (I fixed the links now in #41)

codepen.io/axe312/pen/BNBBgN

I've been chatting to the Rules team and they can foresee a need for these layout, but they are not yet at the point where they are designing wireframes.

The issue summary still lists system templates as being affected: page.html.twig and install.page.html.twig. The Twig team has been working to remove classes from system templates, so hoping the listing of those templates is just an oversight. If this is strictly for admin pages, then the templates that are changed should be restricted to the Seven theme.

I'm still not a fan of presentational class names like "equal", "big-gutters", "small-secondary", "slim-secondary", "equal-two", "equal-three", "equal-four" and "equal-height". To me, these are code smells: they are putting presentational information into markup. Something that has four equal columns may make sense on large screens, but maybe on medium screens, three is better; smaller yet, two; and the smallest, just one. So using class names that only make sense at one viewport seems not great to me.

I know it can seem that something like this makes CSS more DRY, because similar CSS rules are being written only once. However, it's really only shifting the non-DRY code to the HTML, which then has the same class names used in numerous templates, bloating the HTML. Then, when you want to change the appearance, you often need to change both the HTML and the CSS, which is counterproductive. With Sass you can define the CSS rules in only one place with a mixin (or extends, although those have to be used very carefully). But that's not an option here.

Ultimately the front-end code is being worsened in order to make things simpler for back-end developers. That's the main complaint a lot of front-end developers have had about Drupal in general. We've been working to make things better in Drupal 8, and this feels like a step backwards.

If this goes ahead, it should at least be restricted to the Seven theme. Otherwise that's one more layer of class names and CSS that front-end developers and themers will be stripping out of Drupal's front-end markup.

Even if this is restricted to Seven, though, this still has an impact. It makes it more difficult to develop contributed admin themes. Rather than giving admin themes the ability to make layout decisions, those abilities are restricted by the presentational class names module developers will be told to use in order to affect the layout of configuration pages.

I recognize that there's already some half-baked layout grid classes in core. I missed that discussion when it was happening. I recognize that there are legitimate desires and hard work being put into this; personally I think the costs outweigh the benefits, but others may come to different conclusions.

If this is strictly for admin pages, then the templates that are changed should be restricted to the Seven theme.

This is not the case, because this method does not extend to contrib modules. Seven can't override the panels UI mark up for example.

Even if this is restricted to Seven, though, this still has an impact. It makes it more difficult to develop contributed admin themes. Rather than giving admin themes the ability to make layout decisions, those abilities are restricted by the presentational class names module developers will be told to use in order to affect the layout of configuration pages.

This is already very difficult, because module developers have to write and maintain their own layout CSS, which means contrib admin themes need to overwrite the CSS of every contrib theme that defines layout. No admin theme I've seen wants to do this at all. The biggest problem is supporting every contrib module without them breaking. On the chance they do, they still have a theming system to overwrite the markup they want.

If this goes ahead, it should at least be restricted to the Seven theme. Otherwise that's one more layer of class names and CSS that front-end developers and themers will be stripping out of Drupal's front-end markup.

This is for admin templates only. The audience here are the maintainers of contrib admin themes, not every themer who works with Drupal. I guess it makes sense to move markup and CSS to Classy, and other admin themes can rely on Classy to load this markup and CSS.

*sigh* so you guys n girls are trying to spon feed layout classes into drupalcore instead of keeping it in seven where it belongs ?
This is a huge issue and one of the reasons that Drupal have always turned into such a cluster for frontenders to work with :( Earlier when trying to move all admin files to classy that was refused by the powers that be - So this will result in more "frontend-crap-that-some-developer-might-need-now-so-lets-polute-the-frontend-the-next-five-years" into core , Which is in no way is acceptable - unless we really want to do the exact same mistakes that have been done the last 10 years in drupal.

This is not the case, because this method does not extend to contrib modules. Seven can't override the panels UI mark up for example.

huh so panels-ui in drupal8 is somekinda magic that a theme can't overwrite ?

how about going for the win that make sense here - keep whatever layout classes thats needed for an admin theme inside of seven as thats what everybody will be using anyways - Lets face it 97% of All admin theme's will be Seven or seven based - so why not keep it there - seriously?!

We had a 80% goal not a lets fix this for everybody all the time & even on sundays.

I talked about this with @axe312 during dev days. I think we eventually agreed that the attempt to include any sort of grid (and frankly, any type of grid framework or any other type of representational, non-semantic classe) into Drupal "Core Core" or Core Themes. To be honest, I wouldn't even want those in my custom themes these days. It's just not worth it and rather a burden instead of being helpful. That being said, I do agree with the overall goal of this issue which I interpret as "Establish a style guide and utility around Seven to ease implementation of uniform Core and Contrib administration UIs". I think that this is a very noble cause and should be done. I am not yet sure what form it should take though. And while I do agree with the idea behind this issue, I am also not convinced that it can be solved nicely with re-usable classes and HTML snippets. Generally, I try to limit those a very dense set of e.g. typographical "mixins" (not necessarily in terms of Sass) in my custom themes as well.

I think what we really need instead is some sort of interactive style prototype and demo for Seven including a thoughtfully architected boilerplate for using it in contrib modules throughout. This should be outside of Drupal and simply in the form of documentation + interactive style guide + boilerplate.

We can't force a set of pre-defined layouts onto each and every contrib module UI and we can't do that without screwing up the HTML either. So let's just start an effort to provide the right tools and documentation for module maintainers to build these user interfaces in a common way with optimization for Seven and the Seven style guide in mind.

Ok to stop beeing the defender of everything thats clean n pure in drupal - well for a second...

Add layout framework to core, CSS and SASS generation files - probably this will go to system module as a separate library.

Nope nope nope nope nope nope - please dont :) Dont even think in sass its not a part of core and will never be, thats just the reality of dependency hell, that we dont want (its a long discussion thats been taken over the last x years)

All core markup should not use this layout framework without really good reason - we should keep core markup clean and minimal.

Check we agree - why all this should be dumped over in seven & be a really kickass solution for how to customize & build admin themes

Implement layout framework in Seven.

yes where all this should live

Do not touch Classy - it should stay clean and without any layout classes.

I KISS YOU! :)

Ok what i think would be a really really good idea instead, was to do all of this in contrib instead multiple reasons for this:

* Getting anything "new" into core is a goddamn pita - This is at the end of the day a feature request, that can easy wai for 8.2 or something if it proves to become an epic solution, then we could do the push for this
* we dont put something into core right now, that down the road turns into be a pita, even that it maybe makes sense now.
* just the bikeshed of a classname can take forever - by doing it in contrip it can be proven first as a solution that's awesome

...also what fubhy says

I have no problem moving the CSS into Seven, but the markup is different, how exactly does Seven override the markup in contrib themes? How can contrib or core modules rely on these styles if the user has to install a custom module?

I think what we really need instead is some sort of interactive style prototype and demo for Seven including a thoughtfully architected boilerplate for using it in contrib modules throughout. This should be outside of Drupal and simply in the form of documentation + interactive style guide + boilerplate.

There is an issue for that: #2404111: [Meta] Create a visual style guide for the Seven theme.

how about going for the win that make sense here - keep whatever layout classes thats needed for an admin theme inside of seven as thats what everybody will be using anyways - Lets face it 97% of All admin theme's will be Seven or seven based - so why not keep it there - seriously?!

But they aren't right now. Seven is actually very unpopular in Drupal Seven, most custom projects use a contrib admin theme. Examples: The current state of Drupal admin themes. Admininal is very popular.

This is a huge issue and one of the reasons that Drupal have always turned into such a cluster for frontenders to work with :( Earlier when trying to move all admin files to classy that was refused by the powers that be - So this will result in more "frontend-crap-that-some-developer-might-need-now-so-lets-polute-the-frontend-the-next-five-years" into core , Which is in no way is acceptable - unless we really want to do the exact same mistakes that have been done the last 10 years in drupal.

You're not really listening to what admin theme maintainers want, you're steamrolling over them with your own objectives even though these changes are proposed for you, they are for admin theme maintainers. You have never maintained a custom or a contrib admin theme, or the admin UI for a complex module, so maybe you should listen to their problems and needs.

But they aren't right now. Seven is actually very unpopular in Drupal Seven, most custom projects use a contrib admin theme. Examples: The current state of Drupal admin themes. Admininal is very popular.

Do we have any numbers backing this up ? I have to far the last 8 years worked on 2 project that didnt used seven/whatever else was default - im not gonna claim eater/or.

You're not really listening to what admin theme maintainers want, you're steamrolling over them with your own objectives even though these changes are proposed for you, they are for admin theme maintainers. You have never maintained a custom or a contrib admin theme, or the admin UI for a complex module, so maybe you should listen to their problems and needs.

Lewis you can push this as much into my ego as you want to, at the end of the day this comes down to:
Do we want to add more css/markup that makes assumptions for how we do layouts, designs or not ?
If this is for admin themes -well then we do have a default admin theme seven, so why not use that?

And im listening : push that into seven where it belongs, dont put it into core (as you mentioned earlier its a modification of what seven already does)

Correct me if im wrong this seems to be a feature request from developers, i dont see or hear a theming world standing up shouting for layout classes - its developers having a dream that bootstrap was hammered into core "to make it easy" - this is at the end of the day a lighter version of it but the same concept.

Admin themes for D8 ( dont care one second for D7) We have no idea what will happen in the future.
Lets make sure we dont assume all kinds of things, that ends up biting us later, as we know it will (hello .clear-block / .clearfix )

Let's take a step back, as I'm not sure I have a clear understanding of what is being proposed. Can somebody clearly define the following?

• Which specific templates would have these default layout classes in the markup within the core? We need to understand both the template name, and whether the template is in core/system, Classy, Seven and/or Bartik.
• Where will the CSS for these layout classes live? Again, in core/system, Classy, Seven and/or Bartik.

Is that something you can clarify, @LewisNyman?

@mdrummond Yeah, thank you. I'll get back to this when I have some spare time, today I hope.

Good point, we really should update the summary. The discussion moved a lot since the first proposal.

I will help lewis with that. @pivica and everybody else, let me know if you want to join us.

Hi,

as lewis stated, from the #d8rules initiative, we have high interest in re-usable admin UI patterns being available for core and contrib developers.

1) So core already does some layouting, but does it badly. The purpose would be to improve the existing grid-logic to something more consistent and reusable. +1 for that
-> For those like me who don't know all of the internals of the current 8.0.x development status, are we talking primarily about core or seven templates and stylesheets? It would be great if the issue summary could link to examples which are currently bad and we want to have improved.

2) Some might argue this is a Seven-only problem. So if we have admin UI layouts implemented in Seven only, what happens when you switch to another admin theme? Any other admin theme would implement their own layout solution. Sounds like great flexibility, but if core doesn't provide consistent layout patterns, it seems like every admin theme would need to invent their own.

3) That already sounds challenging for admin themes that want to style Drupal core. Now for contrib, I think without guidelines we are likely to run into the problem that admin themes have no clue about what they should style. So some form of layout convention would make sense from my point of view.

4) Semantic vs. grid-classes. This probably has been discussed over the years a lot. I personally would opt for semantic layout classes, because then I can just swap out the CSS for my own grid framework and don't have to fiddle around with a layout being hard-coded as CSS classes.

5) Will kittens die because we put our own, custom grid framework into core? This might need some explanation. So we can't use Sass in core, but use Sass to generate the CSS and commit both to core? Almost sound like we could use Susy to do that. Or is it that we can commit Sass but it cannot depend on external libraries?

Greetings, dasjo

@dasjo
2. yes this should only be in the theme not "inside core" the reason for that is simply we dont want to have baggage of what we think is a good idea right now, and then have to carry that around for the next 5 years - I would prefer it to live inside of seven, as this is a admin theme seven issue & would be good for documentating what exactly goes on, but could also go into classy, if its needed for bartik
What other admin themes wanna do in contrib is not a problem - its a feature -, if they want to copy classnames or want to invent their own thats how it should be, that gives the flexibility.
Classnames / markup should as well be inside templates in your module as well, so it would be easy for a theme to support rules module.

5. YES not only kittens will not only die but be slaughtered by the truckloads - i know module developers dont care about this, but please dont kill any kittens in our beautiful frontend, what devs do behind close doors are fine... we dont wanna know about it anyways ;)
or read above what ive now tried to explain 4 times along with mdrummon

...btw sass dont solve the basic problems sass is just a tool to help create css

Ok, so I've gone through the issue summary and updated the motivation/requirements to be limited to just the admin interface, inline with that I've removed mentions of Bartik and I've removed all mentions of Sass as well.

I still need to talk to Pivica and axe312 to update the proposed resolution inline with the latest JSfiddle

@lewis thanks for the update
This still dont explain why you all want to put this in core - and not in classy/seven where it belongs (banana n all that) ?
by addding it into core we have to cary around this weight for the next 5+ years, by adding all this to classy, any themer that wants to move away from this can do it (and yes they will then have to work around whatever rules or other modules from contrib might want to, but thats how its always been)

The classnames are less than ideal for future changing in how we think layouts ex rows will be completely dead when we get to the holy land of flexbox - but thats a bikeshed on the class names.

i have read again the comments about where to put those classes.

let's recap what classy is about:

Its purpose is to provide many classes throughout the markup that help annotate and describe markup elements that render on the page

https://www.drupal.org/theme-guide/8/classy

so classy was introduced to be able to remove classes from core templates so that

• purist developers can use only minimal default markup and add their own classes if needed
• lazy developers can use markup with lots of classes and target whatever they need

so if this issue is about figuring out where to put additional layout grid classes

• a) i don't think they should go into core templates because we want them to be minimal without much assumption
• b) i think they can go into classy when we think they should be reusable for other themes / set a visible standard
• c) i think they can go into seven when seven is the-only admin theme which will ever consume those classes

putting them into classy would make most sense from my point of view

This is the part of the issue summary I still find confusing:

Next twig templates need conversion (seven and maybe bartik?):
- system/templates: install.page.html.twig, page.html.twig
- seven/templates: install.page.html.twig, page.html.twig, maintenance-page.html.twig

Is this just an oversight? Why are install.page.html.twig and page.html.twig for system being mentioned here?

My understanding is the goal of this is to make it easier for module maintainers (in both core and contrib) to make layout decisions for their config pages. Those config pages are rendered with the seven theme by default. So I'm failing to understand why these presentational layout classes are needed anywhere outside of the seven theme.

If it's just Seven where these classes are needed, then they go in the Seven theme's files, not Classy, and not Bartik.

OK so Benedikt and I spent a lot of time going through the issue summary and updating it to match the current suggestions and incorporating the feedback in the discussion so far. The specific implementation details are now all kept in the codepen, so it's easier to maintain in one place.

We've also fleshed out the motivation a lot more so it's clear what the benefits are and who this affects.

There is still some discussion to be had an a consensus to be reached, but at least the issue summary is clearer and less confusing :)

@LewisNyman: Thanks for the big update on the issue summary. That's very helpful.

I think if these layout classes are restricted to admin templates, rather than user-facing templates, that's positive. As long as it's just admin templates, having those in Classy is an improvement over having them in system. And having the CSS that supports this in a library that is assumedly only pulled on admin pages is also positive.

That should give additional flexibility to module developers to do layout on their admin pages without front-end folks needing to be concerned about those classes showing up in user-facing templates.

Very much appreciate that we've been able to have a good discussion about this. Look forward to seeing the patch or patches that implement this, but so far this sounds workable.

FYI Morten and I yelled at each other/discussed this in a bar at Drupalcon and Morten said he's ok with the updated proposal.

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!

Wanted to bump 1 more time, with Gin being added to core soon is this still needed?