[meta] Consensus Banana Phase 2, transition templates to the starterkit theme

In terms of which templates get moved into Classy, I think the first answer is every template that has classes, and the core/Stark version of that template will not. My guess is that this will be nearly all the templates, but maybe not every single one.

Once we have identified all the templates to move, I think we need to look at where that leaves us. Are there two or three templates we wouldn't need to move? Or fifteen? If there are just a couple, might be worth making sure every template is in Classy, as that would be awfully convenient for people. If there are a lot we wouldn't move, that may be more duplication than is worthwhile.

Other thing we need to clarify: with this phase, in addition to putting a copy of a template in Classy, we are also stripping out the classes of the core/Stark version of that template in this phase, right?

Within the templates folder, if there are no sub-folders it's going to be a pretty large number of templates. However I'm not sure that grouping by core module is the best way to simplify that. A slew of templates are in the system module, so I'm not sure that's a logical place for people to look for templates. One way to avoid bikeshedding organizational structure of the templates folder right now is to just focus on moving everything into the templates folder to start. After everything is in, it might be more clear if we need more organization and what a good way to organize that might be.

As for breaking this up, I suppose doing this by module is a good a method as any, with the caveat that system module has a ton of stuff. We may want to break that down further in case there is any debate as to which classes to remove from the core/Stark templates.

As far as which classes should be removed, I don't think that needs to have anything to do with what we did in the preprocess phase. We're having an Everything Must Go sale on classes. The few exceptions should be any classes that make admin tools like the toolbar and contextual links work. I don't think that themes based off of Classy should have to completely reinvent the wheel each time for how Drupal's key administrative functions operate.

Yes, any template that has a class, whether it's hard-coded or in an attribute. Everything must go.

The point is to get us to two versions of markup. One with sensible classes and one with almost no classes (only those required for toolbar, contextual links, etc.).

So since we have moved to doing

{% set classes ... %}

in all (most?) of the converted templates, it seems that it is only that part that is being removed from Stark, in other words, the two versions of a given template in Stark and in Classy will be completely identical except for the fact that one of them (the one in Classy) has the {% set classes ... %}. Is that correct?

If so, would it make sense to simply use Twig blocks to wrap the markup part of each template so that Classy could extend the Stark templates and just add the classes? That would reduce the amount of code duplication between the two. Of course, if the actual markup still should be modified in some cases that would still be possible due to the nature of Twig blocks.

I'm not really a themer, so feel free to tell me to STFU if this does not make any sense. I was just wondering about it and wanted to mention it.

If we remove all the classes from the template, aren't we eliminating any context for some of the sections, and left with just a series of empty wrapper divs?

Yup, this is the biggest potential issue with removing classes wholesale in phase 2. I thought we had discussed that on the parent meta or phase 1 but I think it was all on Twig calls. It's kind of divitis vs. divitis with additional classes.

My general thought is that if we can get phase 2 done as quickly as possible in a straightforward way (whether we just remove the "set classes" and addClass usage or remove all classes wholesale) we can then churn through some "dream markup" (or dream markup lite) issues afterwards to strip down the Stark/core templates even further, now that we won't have to worry about Bartik/Seven for most of them. It's not really phase 3 but it's picking back up on the dreammarkup "initiative".

Edit: In other words, my suggestion is let's not worry about markup structure in phase 2.

As I recall, back in Austin when we came up with this plan, Classy wasn't just about adding classes. Core templates were not supposed to add any classes, or markup, that wasn't absolutely required for their basic function. So all those wrapper divs should also go away in the core templates. They also would be added in Classy. The point was to make core output as minimal as humanly possible.

Heh, "problem child".

FWIW, most of the web tests use core (effectively Stark).

What do we do about id’s?

For example in taxonomy-term.html.twig an id is set for ever term:

<div id="taxonomy-term-{{ term.id }}"{{ attributes.addClass(classes)|without('id') }}>

If it is not neccessary for editing functionality (e.g. contextlinks) it is just a styling hook.
So I would prefer to remove them to.

Yes we should remove id's as well & clean the mess up.

+1 on stripping classes out and leave the markup - then we can go all #dreammarkup on the individual templates later.

About the folder names, lets move em over & then we can later discuss what we wanna call em, module names are fine but i would like to bikesheed the system folder - cause its kinda a nightmare with all its templates, but lets do that as followups later

May I suggest that we split each up into 2 different patches:

The first one where we copy over the template & strip out classes + ID's from core and keep them in classy

After that we then create a follow up where those that care about drupalcore markup can discuss what to put where - in that way we can get the basic of classy done without a bikesheed that have blocked all templates for months.

I think its the only way to get progress on classy - else we will end up in never ending discussions about which class to put where.

Agree with mortendk, lets do straight conversions first, then create more #dreammarkup.

+1 for straight conversions.

+1 for using the module names as folders in the templates folder.
So we match the structure of the template folder in classy to the structure in core.
Maybe later we can deside to split uo the system folder in some subfolders.
But that changes should be reflected in the templates folder in the system folder.

+1 to keeping things the exact same representation as in core currently.

Were stumbling into issues with testing when we clean out stark completely for classes fx block.
So what do we do there ? - test up against classy instead (that would make sense) or whatta do we do ?

I think we should be updating the tests.

I think one single folder with the templates is what we should aim for with this phase. System is such a dumping ground for random templates that grouping things by module is pretty unintuitive.

Ok, I give up on the folder structure for now.
Just shove them all in templates and make a bikeshading followup about the structure.

FTR I agree with @derheap about the folder structure. It helps enforce the association to where the folders would fall back to if they aren't there.

one single folder with 147 templates in is gonna be a cluster for anybody to look at - so how about we just move em over and keeps them in the same name as the module that created the template's (i thought we agreed upon that here in Amsterdam ? ) then any other structure we can bikeshed that in the follow up, where the "what do we call stuff" also will take place?

@cottser - so update the test to use classy as a theme (how do i do that btw - rtfm?) - or do we add in data-attributes instead to keep it completely seperated ?

about the test i created #2350823: Use the Classy theme in the Testing profile so we can use classy as the testing theme

@david ok everything into classy/templates/ no subfolders no nothing

1 - 2 - 3 patch harder!

What about other attributes than classes? I can see patches around child issues where all attributes are being removed and for me that seems wrong since I thought classy is only about moving classes from modules to classy.

@lauriii, don't let the name fool you. When we're done, any markup that isn't absolutely required for a module's basic functionality is supposed to be moved out of core and into Classy. It isn't just about classes.

Question, not sure if it's appropriate for this meta or should be moved somewhere else, but...

The issue summary lays out a plan for basically taking the existing templates that modules provide, copy/paste them into the Classy theme, then return back to the module-provided template and strip it down to bare tacks.

My question is: what are contrib modules supposed to do? Contrib obviously can't copy/paste its own templates into Classy, because that's hacking core. And core's Classy theme is not going to ship with e.g. themes/classy/flag.html.twig and themes/classy/og.html.twig and 15,000 other modules' twig files, because that would be insane. :) So presumably contrib modules would provide only the stripped-down version of their templates. But then how do you surface to themers that there are (for example: http://cgit.drupalcode.org/flag/tree/theme/flag.tpl.php) wrapper classes, convenience classes, etc?

So then it seems like we need a change record to explain to e.g. the Flag module maintainer how to port a "classy" template such as http://cgit.drupalcode.org/flag/tree/theme/flag.tpl.php to Drupal 8, in respect of this markup change. Otherwise, all of this effort will only hit about 10% of the problem, since most sites use 50+ contrib modules in addition to core. And since beta is when module developers who've been sitting on the fence start porting, the sooner that documentation exists, the more likely there won't need to be a massive clean-up effort after the fact in D8 contrib.

@webchick Very good observation. We discussed this briefly in bof at Amsterdam and my stake was that core should support union folders:

E.g. Component=classy

Would search for templates/classy/x.html.twig first and then for templates/x.html.twig

That would solve a lot and would allow contrib to ship with both - if wanted, but would allow themers to make patches to contrib, while right now we would obviously split the crowd...

We also discussed a themers guide for module developers :-).

To address webchick's concerns, my understanding was that we would still have the same attribute objects in the core templates, and that's how modules would pass in any necessary wrapper classes.

I think one point we maybe missed is that if there is CSS in core that is targeting the classes or (hopefully not but you never know) IDs, then that CSS should probably be moved to Classy as well, right? It doesn't make sense for core to output a bunch of CSS that never gets used.

I can't speak for Bartik, but Seven is still going through a process of moving common administrative CSS out of modules, and turning them into reusable classes that can be used by core and contrib. I'm not really happy with the idea of inheriting all the junk CSS from every module in core. I still don't understand how this scale to contrib.

There is also styling that is functional. To move it into a theme would mean that functionality would break when using another theme. That's the definition of styling that lives in base.module.css

@LewisNyman I think the idea is that the styling that is necessary for function remains in modules.

I think we have to recognise the difference between color and simpletest's templates which are backend UI and things like node, block and comment. If there is a use case for something being presented to not an administrative user (or developer) then yep let's put the template in classy and remove all the classes from the core implementation. But OTOH for super obvious cases like color and simpletest let's not. I would also argue that the views_ui sits with color and simpletest. But view templates should be copied to classy. Also note that not copying to classy does not prevent a theme that uses classy as base theme from overriding.

I think this strategy will allow us to focus on what is important for front-end developers and keep the maintenance burden low.

Right, #51 is more along my lines of thinking. I understand the desire for core developers not to have to arbitrarily decide on a template-by-template basis on whether to copy or not, and making the rule "So just copy all of them" addresses this concern. OTOH, I feel the absence of core developers making a decision here pushes the mental burden instead to themers themselves, who now need to be able to sift through 50+ templates in Classy to find the ~10 that matter in most themes. This is particularly difficult for those brand new to Drupal who, for example, don't know what a "node" is yet and how central it is to everything.

In #2349759-43: Copy system templates to Classy Alex said:

There are templates for the front- and back- end here. I think all the front-end templates should be copied and we should leave the back-end templates where they are. If we can't decide whether something is front or back then we should err on the side of copying.

That seems like a simple enough rule to satisfy the "not wanting to make arbitrary decisions" while at the same time getting a lot closer to "what 90%+ of themers will want."

I see a couple of different perspectives and arguments being drawn here. I think these are worthy of a discussion.

#51 alexpott says:

I think we have to recognise the difference between color and simpletest's templates which are backend UI and things like node, block and comment.

I think we do recognise the difference, however is this (Classy theme) where we need mark this distinction? I think what you are saying here is that since most of the time a themer won't need simpletest template therefor we should not include this in Classy, and that since templates like node and comment are commonly required, those are OK to move to Classy.

I think that sounds like a reasonable argument, however it does draw a distinction between front end and back end with regards to theming, which is arbitrary and assumptive. Meaning that we can never know what a themer actually requires, we only make assumptions about such things. We don't know if the only job this particular themer will ever have in Drupal is to build their client an Admin theme.

There is a theme that wholesale copies every core template - Omega. I can take a pretty good guess why they did this - because not doing this makes dangerous assumptions and introduces an inconsistency in the theme system. What themers really want is a systematic approach that makes sense all the time, i.e. consistent. It is not surprising to me that the vastly experienced front end developers who built Omega made this decision, because that is precisely what we want.

So I have to disagree with you - I don't believe we can assume what is important to themers, the group is far too diverse, and when you make the arbitrary distinction between front and back end templates you can only do this by making assumptions about what is important for one this or that particular task.

I am not convinced Classy should be making this distinction, at least not along the lines of "front end" and "back end".

keep the maintenance burden low

Here you mean for Drupal maintainers. I think we know this is not a DRY approach already, we've worn that burden as a group and will continue to do so - because we recognise the benefits outweigh the costs. Its plausible that not moving a particular template is not a free lunch either, simply because we now must maintain two lists of templates - those that reside in Classy and the sub-set that do not. I would argue this is an additional burden for Drupal core template maintainers in itself, who must remember that such and such a template is hidden away in a core module somewhere.

#52 webchick says:

OTOH, I feel the absence of core developers making a decision here pushes the mental burden instead to themers themselves who now need to be able to sift through 50+ templates in Classy to find the ~10 that matter in most themes. This is particularly difficult for those brand new to Drupal who, for example, don't know what a "node" is yet and how central it is to everything.

Thats a lot of arguments in a few sentences but I think I can distill them down to one - discoverability.

I think what you are really driving at here is that by having all the templates in Classy we make it harder to discover what we need to find. Again I think that sounds like a reasonable argument, but I don't think that leaving templates out of Classy to reduce the list size is the necessary answer to that issue.

I agree that discoverability is an issue in itself, and we should discuss ways of making it better, such as using sub-directories in the templates folder, group template by module or other logical categorisations.

Simply leaving templates out (not moving them to Classy) does not solve the root problem of discoverability, for any group no matter what their experience level. In fact it could make it worse, by hiding required templates in core under the assumption they are seldom or not required. So for one group you actually make this harder (those that need that particular template). I already alluded to the idea that maintainers will need to know about those templates, as will anyone building an Admin theme that needs that template. Please note this is not an outrageous claim, its not every day work but in a way it is, because its about processes and consistent approaches.

The "new to Drupal" argument I think we need to particularly careful about. Many new themers are vastly experience front end developers, this stuff is a normal day at work. Also the system is the system, if you are going to theme Drupal you need to learn the system, and you want a systematic system. The English language is so hard to learn because at every step it has an exception to the rule. I would say Drupal is hard to learn because so often it has exceptions, or as I like to call them - inconsistencies.

So to sum up, sure discoverability is an issue, lets solve it, but do it in a way that does not add an inconsistency to the system.

Honestly I found this hard to write, because in many ways I do agree with both alexpott and webchick, however I am also deeply aware that we need to banish this idea that its OK to build in inconsistencies because of arbitrary arguments, such as making it easier for this or that group, or making assumptions about what is important. I would vastly prefer a system that is 100% consistent with itself, because no matter what task I have at my desk that day, I know how to solve it, even if it takes me a few seconds longer to scan a list of files.

Rant on:
Themers are sick, tired & frustrated of having markup and or templates hidden from them cause somebody (who probably dont work with the themes) X amount of years ago (in d7 cause now somewhere between 5-8 years) thought it would be a good idea to shield the themer from the evilness of complicated code.
The end result is then that the themer now have to both battle Drupal and the frontend hell of markup,css & 200 different devices
/Rant
Sorry had to get it off my chest, but its what makes Drupal hard to work with, lets not repeat histories false assumptions of what a themer want.

BUT yes we can "accept" that a template like the simpeltest is not moved into classy, but unless theres an extremely good reason and that reason would be "No themer or frontend ever in the world of drupal would ever ever ever work with this template, or wanting to modify whatever we put into it now" if thats not the case it MUST go into classy.
We cant end up with yet again a system where its not clear where the stuff is. Yes there will be a ton of templates (that we will organize into little folders, to make it less scary the first time).

Just cause a template is used for the backend does not make it a template we dont wanna work with (we do want backend themes now dont we)

So Dear Developers give us all the templates - dont worry we will be allright, we wont break it - were grownups, and we have a fire extinguisher ;)

As omega in D7 shows you can have all the templates already. But we have to remember that with contrib and custom front-end developers will have to look in the module directories anyway. So what makes core special? And is not inconsistent with contrib and custom to say look in the modules for their templates and in core everything will be in classy. The reality is this situation exists because of complexity. With custom, contrib and core and themes, modules and profiles we have an extremely complex system of deciding where to find stuff.

First of all thats directly against what classy is about - and 2nd were talking about how core works outta the box for the themer, Im not saying stuff is not gonna be complicated, what i don't wanna see is that we now begin to hide away templates, cause we might think thats not gonna be a template that the themer wants to use. The idea with Classy was that it would be easy for the themer to find everything that he needs to build a theme.

If we begin to separate backend vs. frontend were also gonna say that the backend should not have new themes.
Lets not make that mistake, when you open up classy the first time you should have everything outta core that you need to make a kickass theme no matter if its frontend or backend.

I would like to see a list of the files that is an issue, besides of simpletest & maybe the ckeditor templates (which im still on the fence on, cause we wanna build kickass frontend architecture also for the backend) else its just the arbitrary discussion, which i do belive is a discussion we have had.

I think the use case for administrative templates is much smaller than other templates, but it is still a use case. We have maintainers of contrib admin themes and we also have situations where you would need a custom admin theme on a project. What's the threshold for including a template in Classy? It feels a little inconsistent.

Classy is a core theme, so I don't think it's illogical to have all core templates in Classy, even if contrib templates are not.

I'm not against the idea of having a different rule for admin templates, especially because we are already encouraging module developers to add classes to their templates to take advantages of Seven's reuseable CSS components. I'm just skeptical that excluding a handful of templates really benefits all themers more than it hurts the minority that are looking for these files. If it ends up being half of the templates, then maybe that would be helpful for the majority of themers.

I think we can also improve findability of templates in Classy without removing them in #2349559: [meta] Discuss the organization of subfolders in Classy

on the concern of classy theme that haves a ton of tempaltes in The template folder will get subfolders #2349559: [meta] Discuss the organization of subfolders in Classy

from a talk on irc with mr. alex pott i understand that issues are with these templates ?

• views_ui
• color
• locale
• language
• simpletest
• update
• admin-*,
• system-*,
• status-*,
• install-page
• maintenance-task-list

did we miss anything - could we get all the bodies on the table :)

just to re-iterate @mortendk's comment and my opinion. From a quick glance I would not copy views_ui, color, locale, language, simpletest, update, and the admin templates in system. The admin templates in system are (i think) admin-*, system-*, status-*, install-page and maintenance-task-list

Toolbar's template is the one where I sit on a fence - but considering that this is just one template and it does appear whilst using the front end I would err on the side of copying.

We've talked about whether to copy identical templates or not at least a couple times on the Twig hangouts. At this time I'm not one of the main drivers behind the consensus banana so this is just from my perspective as one of the theme system component maintainers. I'll say up front that the main motivation behind my concerns is not around having to patch things twice in the core queues, it's actually theming experience (TX).

This is long, so I'm splitting this up into three main points, hopefully that's not too obnoxious :)

1. Why are we only striving to improve classy's TX?

I can definitely see the appeal of having all or most of the templates in one spot to start with. But what about core itself? The part that is a bit weird to me is that (I think) many of the people fighting for the idea of duplicating templates into classy are actually not in the "classy" camp at all, and would rather use the stripped down templates in core itself, which won't come all packaged up in a neat little folder. So that's a bit sad, why do the classy people get things so easy?

Related to this, I think it would be helpful to try and examine an idea that I'm (maybe mistakenly) picking up in the motivations behind this: "new people will use classy" - I'm not convinced of that at this time.

2. We have discovery tools to help find templates

If we're concerned about template discovery I'm of the opinion that currently twig_debug trumps any attempt at a consistent "copying" scheme, which as we've talked about on the calls and more recently on d.o, becomes inconsistent as soon as 1 contrib module with a template is installed or as soon as you extend from a contrib base theme that doesn't include every single core template within its templates folder. From my perspective just copying everything is less consistent than overriding templates only when needed - it breaks down quickly and gives us yet another exception to explain to newcomers.

3. Embrace the cascade

With our current theme system the overriding/cascade of templates needs to be learned sooner or later and to me it's not radically different than that other "cascade" themers need to know about: CSS.

If we start duplicating templates unnecessarily in the name of consistency or discoverability, to me it feels like we're just trying to delay the inevitable and deny how the template system actually works. And I can't help but think we'd be creating more inconsistencies in the process.

Well, to illustrate the point that we can't easily differentiate based on arbitrary distinctions like admin/non-admin, front/back-end, I am using status-messages.twig.php in my D8 theme. So we have an exception to #58/#59. Its in contrib right now, so I will reiterate, you can't just demarcate along a blurred line what does and what does not meet a set of criteria.

My vote stays as "copy them all" and if we have an exception it must be exceptional, i.e. what morten suggests in #54, however we know this case doesn't exist :)

I would point out is that we have 3 very experienced Drupal front enders actually agreeing with each other. How rare is that!

#61 my bad, status-messages.twig.php should be copied - I thought it was part of the status-report - it is not.

The part that is a bit weird to me is that (I think) many of the people fighting for the idea of duplicating templates into classy are actually not in the "classy" camp at all

For me at least this is not true, I am using it. I have a specific set of reasons for doing this at this time, mainly because I see potential risk in not using Classy as I am generally distrustful of module contrib and how they often tend to rely very heavily on core markup and classes, particularly in JS, and this will create a deluge of issues in my queue if I do not use Classy.

With regards to #3, what inconsistencies do you think we'd be creating here, I'd like to hear what your thoughts are on that.

The theming Experience will be truly magical with having all templates in one place (yes we have the debugging tools - one good dont remove another good thing), so now from core its extremely easy to "just copy the folder" and start my new theme - Its Theming <3 to the max. That will satisfy every themer that just wanna rely on "what core does" and change a little bit as they go along, without being caught up in the mess of finding templates.

Remember were trying to satisfy the "just gimme what core does" vs. the "i like to write 150 templates so i know exactly what goes on group" its 2 very different groups of people, that think & work with the themes in 2 very different ways.

Core needs to be clean clean (clean) - totally stripped for any assumption of markup or classes.
We cant again (as in all previous versions on drupal) build on a frontend architecture that is turning ancient within a year & then lock us self down into that.

The reason we wanna strip core complete out, is to make sure that nothing rely on core - So when i go and create "theme2020" then i can build it up on a markup & css that does exactly what I need, and not having to work around drupal.

Duplicate templates, if we happen to be so lucky that a template in core & classy dont have any markup or css (is there two or something that dont have that) is it worth not being consistent, just cause of 3 files (admitted i dont know the exact numbers)

We might not burn down the castle (...) if not add views-ui templates to classy, but only because its probably gonna take loads of time to completely clean it out, classy should have everything that core needs for any theming.

May i suggest that we get a list of templates that can be an issue - discuss them this week so we dont block all the patches ?

Ladies, gentlemen, developers & themer's I created a google doc with a listing of all templates i could find today in my latest version of 8.

I have listed em all by modules & added comments where it could be argued that its a "admin" theme element.
TBH i only see simpletest to be a template that we dont wanna copy to classy

1. We wanna make it 100% clear that a template should be functional without markup (we use data-- for js selections right ... right ?) - thats why its in classy, our default markup system for all things drupal. A theme that wanna break out of whatever we wanted todo today in 2015 wont be bugged down by that in 2018.

2. There can be edge cases where we say "ok lets not use 400 hours on fixing views ui - its our UI for drupal & we are acknowlidging that it will be locked into our 2015 markup"

plase jump in and put colors & comments in - but please first read up on the concensus banana principles.

https://docs.google.com/spreadsheets/d/1EVpPXXOem1fId00YH62-nH0mqlp6Rutk...

cheers!

I'm with @mortendk on this. An admin theme is still a theme. It may provide access to the back-end of Drupal, but it's still a front-end interface for the people using it and the same design principles still apply. Bartik and Seven are both sub-themes of Classy, so Classy should contain all the templates.

Looking at the spreadsheet I only see two templates I would consider leaving out of Classy: simpletest-result-summary.html.twig, and install-page.html.twig. Simpletest feels like a special case and a developer thing, and there seems to be a good case that the instal page template belongs in an installation profile.

When it comes to Views UI and any other edge cases, my inclination is to include the templates in Classy—even if they are identical to templates that are also in the module—just for the completeness of Classy as a reference tool. That approach seems most consistent with the consensus banana principles. Of course if time and resources allow, it might be good to go back and refactor the module templates to remove as much markup as is humanly possible.

When we established the consensus banana the goal was to remove all the markup and CSS from core modules that wasn't absolutely required for the module to work. We didn't say "just markup that impacts published content." We were targeting ALL markup. Our ideal was to have no display markup in the modules at all, if we could help it. Classy is the place for all the generally applicable defaults (a.k.a. the Zen theme approach), while special needs can go into the individual sub-themes.

Thanks for the very thorough write-up, David. I can't speak for Alex or catch or Dries, but my personal opinion is:

- The amount of work left to do achieve the penultimate vision does indeed seem rather daunting. Agreed that "X weeks/months prior to RC" is the real deadline, if we're serious about making sure it's shippable.
- So figuring out a way to make a more modest and achievable "minimum viable version" seems like a decent strategy. +1.
- I don't hear anyone arguing against putting in front-end templates so that subset of templates feels like a good place to focus first, especially if themers are roughly in agreement that they're far more vexed by not being able to easily find html.tpl.php and field.tpl.php than simpletest-whatever-stupid-thing.tpl.php.
- I'm open to the idea of doing another check-in later on when all of the front-end templates are moved and "de-classified", and "dreamed," assuming we still have ample runway to RC, and assuming people outside of the consensus banana movement have tried it and given some user feedback indicating this is what they want. DrupalCon LA might be a great time to gather this sort of discussion, if you're looking for an interim goal deadline to help move things along.
- I'm a lot less sure about making these sorts of changes post-8.0.0, though. AFAIK the intent of Classy was to effectively be the base theme for everyone out there who is not Morten ;) and wants to write some CSS to do most of the work. What was discussed at #2135189: Proposal to manage the Drupal core release cycle was we need to preserve backwards-compatibility in later point releases. So if we're into a situation where developer X sub-themes classy for a custom theme for client Y on 8.0.0 (and then subsequently moves onto other projects so is no longer available to client Y), and client Y updates to 8.1.0 six months later and suddenly their theme breaks horribly because templates moved around, that's not really going to fly. We'd have to discuss the impact on end-users of doing this in later point releases, basically, and possibly look at other strategies that could retain BC while still making further improvements.

1. "Copy all templates" - yes we shold do that. This is the right way :)

2. "frontend templates" I have made a spreadsheet for all the templates afaik theres about 20 templates that we "only" use for a theme from the editors perspective.
its not "backend" its adminstrators. This could be a RC-1 goal, im (almost) ok with doing this.
Still this will bite us hard later admin themes will end up depending on both classy & stark, would get messy :(

3. + 4 would make it worse & illogical simply to many wtf's

5. Copy all the templates, only clean out the ones that "in the real world for 80%" needs it for RC-1.
Im all for this as a compromise, its 1+2 - its effective the same as #1. We can then clean out core templates, and seven & bartik can then begin to work the way the should.
I cant see there should not be an issue with us cleaning up markup out of core templates in "stark" post RC-1, at that point is should be the same as cleaning up documentation, and those that would go apeshit about it, is the morten's of the world, and they can fix that stuff emself + they know that they are on thinner ice.

Theres a HUGE blocker that haunts us atm: #2409811: Kernel tests should explicitly install themes and we can't move the templates to classsy, before thats fixed :(

Drupal 2020 - Later release
Heres one of the (many) beauty's of classy: When we release Drupal 8.5 (in 2020), and considerable parts of core have changed (cause of "something"), we could then create "classy-eightdotfive", make it live along side of Classy.
Then we don't burn down 8.0-8.4.9999, they will still work with pure upgrading, but the new stuff in 8.5 would be new & fresh, making it possible for the frontend to move forward. Classy is not only about theme-moaning-over-drupal-core its true seperating markup from evil php.

"but then I've seen discussions that said there will be breaking of BC. "

Hm. Not that I'm aware of. There is a lot, LOT more details in #2135189: Proposal to manage the Drupal core release cycle but basically, in order to get the security team's buy-in on semver, we need to drop support for 8.0.x as soon as 8.1.0 is released. That means we need to provide the same level of compatibility between minor releases of D8 as we currently do in bug fix releases for D7. So while there might be some one-off reason to break BC to fix a nasty critical or something (we broke menu API between ~6.2 and ~6.3 for example to adjust for a security hole iirc), it'd be incredibly rare circumstances in which we'd do that, unless I missed something somewhere.

And yes, agreed that the "morten" markup in particular gets finalized at RC (and honestly, some variation of this "dream markup" initiative has been going on for at least three years, so I don't feel this is unreasonable at all). The end-user scenario I laid out in #68 is the same regardless if Classy or Stark were chosen as the base theme... you can't break a site in a stable release in a way that requires an end user to go digging around in code (unless absolutely necessary, such as the menu API security hole example). Agreed though that we can continue to improve markup with additional optional, turned-off-by-default themes or some other workaround to maintain BC.

OK, can I clarify things for myself here. I see two emergent ideas with regards to BC, for me BC is a critical aspect of the whole Classy initiative.

1. Copy all templates to Classy, we do what we can dream markup wise until RC. Thereafter its locked in stone until?

2. Copy only what is changed dream markup wise, then if a template changes in core (post RC) we first move the template to Classy and core gets the change, not Classy.

Both these preserve BC for Classy - correct?
Mortens crowd absorbs the maintenance of chasing core - correct?

No. All markup freezes at RC. Any markup changes after RC, whether in core or in Classy, would be limited to critical issues only. Once 8.0.0 ships, themes built using either Stark or Classy as a base theme are expected not to break in later minor releases.

Post-8.0.0, we could explore some ways to introduce further markup improvements in a non-BC breaking way. The most straight-forward way would be additional, optional base themes.

Dreammarkup clearification.
Just to make it clear, #dreammarkup is not just about "the markup" do use a <h2 class="foo"> vs. <h1 class="bar"> its the themer experience from templates debughin default markup etc. It was a way to make less php-geeky-developer-types-people (aka frontenders) gateway into the issueques & discuss what we needed in d8 (

The idea of having one (dream)markup that we write once and we then use for the next 5 years is fundamentally wrong - its life or death for frontenders to change markup. if we cant easy manipulate markup / css / js were basically stuck with dirty css tricks & both fighting Drupal & 10 browsers & 200 divices isnt fun.
So to state that we had "3 years to figure it out" makes little to no sense from a frontend persective - the markup changes constantly and in 3 days there will be a better way to write a form label so it works with X browser on Y.

Forward!
Again I would love to see and it would be really helpfull to see what templates it is that "we should not move to classy".
Im ok with making a (small) compromise on the simple-test & install templates - theres solid arguments for not moving them, anything else should be move moved to classy & so we can burn the core template to the ground with only the {{ vars }} inside of them ;)

we need to get em all moved over, so classy can get organized in folder structures etc & stark + bartik, can see whats up, and we dont end up having another test not using classy :)

@jeff i proudly take on chasing the dragons inside core

@webchick: so in a 8.1 release we would be able to fix markup right but not in 8.0.1

I'm really not sure how I keep being unclear here, but let me try once again. 8.1.0 is the same as 8.0.1. We can't break people's stuff in a stable release of Drupal 8. So, no. We do not touch markup that 8.0.0 ships with after RC (we can add new markup that won't affect existing themes, however). Again, unless we made some weird provision for markup code in some conversation at some sprint that I was not privvy to (in which case, please point me at documentation of this decision).

But if we did decide this, I worry about how to handle the scenario I laid out in #68, because it means some hapless end-user with no theming skills gets stuck trying to fix their theme in a minor version update of Drupal 8 when the markup changes out from under them and their CSS no longer works, as punishment for hiring a front-end developer who knows what they're doing.

I'm definitely sympathetic to the desire to not be dealing with 2015 markup in 2019. I talked this over some with catch in IRC because I was genuinely confused why this BC policy was somehow new information to so many people. He said it ultimately depends on how we define an "API."

It sounds like you guys are defining Classy as the API (meaning, the thing that won't break in later point releases, and the "safe" option to sub-theme from if you are building a theme for a client that you don't anticipate working for in a year) but core markup as not the API (meaning you could continue to make changes to this in perpetuity). However, that feels a bit backwards. If anything, one would expect core's default markup to be the API that doesn't change much (just as core's public developer APIs don't break after release), and sub-themes themselves to continue to get updates throughout the life of Drupal 8. Like, I would expect us to add a disclaimer to Seven / Bartik that people shouldn't sub-theme from them because we want to continue to make improvements to them in later point releases.

That might mean core ships with an "Edgy" theme or something, that starts as nothing, but gradually gets more template overrides as markup evolves. But I'm struggling a bit to understand the use case here. I guess "you are building a theme for a company that employs front-end developers and has no problem with those people taking time away from solving business problems to chase core's markup every 6 months."

I think the likely BC breaking scenario is people not wanting to scream at the same DIV they hate for four years, knowing it can't be changed. As opposed to wanting to re-envision all the core templates every six months.

Hm. Not sure I agree with that. At the end of the day, we're all building Drupal sites for users, and their needs should trump the needs of front-end developers, who are able to take care of themselves and have ample workarounds (custom base themes, etc.) if Drupal isn't doing what they need by default.

Also, I wasn't suggesting that all templates would change every 6 months; I meant that we only do a "minor" (feature) release of Drupal 8 every six months, so that's the increment at which core's markup could change and themes "in the wild" may need to be re-adjusted if we allowed further changes to markup post-RC.

So I think for now it's safe to assume core's default markup is an API, and it therefore follows the rules of all other APIs in core, in that it doesn't make BC-breaking changes post-RC, barring a critical issue. Which means you need to make all of core's markup the way you want it for 4+ years by RC1. Sorry if this is new information, but that's been my understanding at least since forever, and I remember particularly emphasizing it at the original "Consensus banana" talk in Austin.

Based on what I’m hearing here, I would strongly recommend taking the following approach:

1. Move ALL markup and CSS to Classy. Completely remove it from core modules. This can be done in one mega patch.
2. Refactor Classy as much as is possible in the time allowed, with the goal of making it a nice clean base theme that has the sane defaults most people would expect/appreciate.
3. If there is time and IF it is deemed generally important to all, add tiny bits of markup and/or CSS back to select core modules, just to support minimum viable functionality.

This recommendation is based on the following:

1. The default Core themes (“front-end” and admin) are already based on Classy, so this change would have no impact on them.
2. Most people creating custom themes who would want the kind of basic markup that now comes out of Core (or Zen) should likewise make their theme a sub-theme of Classy. There’s little reason not to. Core does it.
3. The Mortens of the world will get exactly what they’re asking for: a completely blank slate. If you want to build a custom base theme from the ground up, then you’ll need to provide ALL the markup. And that’s OK! Some would even say it’s ideal! Especially since we’re making it drop-dead easy to copy over any templates from Classy that you don’t really want to deal with yourself, like Views UI. Or you can just duplicate Classy and hack away at it to get yourself started.
4. We never have to worry about breaking backwards compatibility if we want to remove some long outdated markup from a core module, since there is no more markup in Core to remove. :-)
5. We now have complete freedom to make sweeping theme changes in 8.x releases. With all display logic in its own little box, this now becomes an additive process. Classy will stay forever the same—a snapshot of front-end's past—while Drupal 8.1.0 brings us Classy 2, with everything we wished we could have done in the original Classy, and Drupal 8.5.0 brings us Classy 3, with the latest in HTML6 technology! All of this without ever breaking backwards compatibility. Down the road we could even release a Low-Class base theme for people who need some bare minimum markup, but not as much as what Classy is providing. The possibilities are endless!

In my mind, this seems to offer the best compromise between different use cases, with the least downside, and by far the best opportunities for future growth, all while maintaining BC. And it's the closest to what we agreed to with the Consensus Banana in Austin, which should not be taken lightly. There were a lot of people with a lot of different perspectives in that room and they all agreed.

OK, long hard think about #67.

Have to agree with morten here, its #5 and probably method #2, and then we get on with this now, and use megapatches for things like blanket removal of set/addClass().

Quick question, is it feasible to remove everything from core templates other than the docblock?

I just don't get why it has to be all the templates - the list of templates not to copy is:

./core/modules/color/templates/color-scheme-form.html.twig
./core/modules/views_ui/templates/views-ui-container.html.twig
./core/modules/views_ui/templates/views-ui-display-tab-bucket.html.twig
./core/modules/views_ui/templates/views-ui-display-tab-setting.html.twig
./core/modules/views_ui/templates/views-ui-expose-filter-form.html.twig
./core/modules/views_ui/templates/views-ui-rearrange-filter-form.html.twig
./core/modules/views_ui/templates/views-ui-style-plugin-table.html.twig
./core/modules/views_ui/templates/views-ui-view-info.html.twig
./core/modules/views_ui/templates/views-ui-view-preview-section.html.twig
./core/modules/locale/templates/locale-translation-last-check.html.twig
./core/modules/locale/templates/locale-translation-update-info.html.twig
./core/modules/language/templates/language-negotiation-configure-form.html.twig
./core/modules/simpletest/templates/simpletest-result-summary.html.twig
./core/modules/update/templates/update-last-check.html.twig
./core/modules/update/templates/update-project-status.html.twig
./core/modules/update/templates/update-report.html.twig
./core/modules/update/templates/update-version.html.twig
./core/modules/system/templates/admin-block-content.html.twig
./core/modules/system/templates/admin-block.html.twig
./core/modules/system/templates/admin-page.html.twig
./core/modules/system/templates/system-admin-index.html.twig
./core/modules/system/templates/system-config-form.html.twig
./core/modules/system/templates/system-themes-page.html.twig
./core/modules/system/templates/status-report.html.twig
./core/modules/system/templates/install-page.html.twig
./core/modules/system/templates/maintenance-task-list.html.twig

Apart from an admin theme does anyone have any reason to copy these templates? We can not make admin theming easy in Drupal 8 - it is an immensely complex subject and copying these templates to classy makes it harder rather than easier. There is not one comment on the issue that offers evidence to the contrary - most comments seem to be saying here is a rule "core should not have markup" and then based on that a deduction that, therefore, we have to copy all the templates to classy. Nothing acknowledges the reality that modules provide administration screens with javascript that depends on the markup. This is not going to change before release. Therefore the rule "core should not have markup" is false. And applying it will lead to problems.

We can achieve a more subtle version of the rule, "core should not have markup using classes that appears on the frontend".

And honestly, if anyone looks at that list of templates what is a front-end developer itching to override the first time they meet Drupal? Remember just because they are not in classy does not mean that a sub theme cannot override them - in fact seven does override a couple of them.

#83

I can't speak for how others view this entire issue but this is my take on the underlying concepts driving the arguments.

The point is no markup in core is a pattern that many of us want to adopt, a best practice, a total separation from "core" - which amounts to variables available to templates, and "design" - the usage of and wrapping of those variables in markup.

The very moment a "core template" engages in the practice of manipulating a variable or adding markup and classes it becomes highly opinionated about what that should be, how it might work and what the output might look like. This is a violation of the best practice.

This is what allows me to ask outrageous questions like "is it feasible to remove everything but a docblock"? It is likley possible to do that in the scenario where all templates are in Classy, bar a few very minor exceptions, respectively. Note my question is driven in part by advocating for a DRY approach, least maintenance etc. Again, not crazy questions to be asked.

How hard an admin theme to build is not really relevant, nor about JS hooks, since Classy is Sevens base them and Classy provides those hooks, or Seven overrides a Classy template and provides more of its own, just like any other theme.

I think webchick said it quite well along the lines of Classy would become THE base theme for all themes, which is actually quite right, but still lets not loose sight of the fact that that is still not a highly relevant point. The pattern/best practice is what is at question here, a least that is how I see it.

just to cleary the ranting concensus:

- We agreed upon move alle the other templates first & clean that up, and then if we had the time, to come back and clean the last bits up. Where views-ui & simpletest would be the very last templates, that should be cleaned up.
- seperating "admin templates" away from drupal cause of some obscure idea that they dont matter the same is planly wrong. The only reason we were not moving everything is simple cause of the fear of not having time, so classy & the css dont gets into good shape.

- Mega patch would be a bad idea & create another cluster, so as i recall it. We will continue to move one module at a time, starting with block & node and get them moved over.

My concern with continuing to go template-by-template is it's leading to arguments like this, which is just further stalling the initiative and making people really frustrated. It also leaves us open to the risk of getting to RC with templates half moved, half not, half converted to classless, half not, and basically a totally inconsistent experience for themers because whatever templates get done are the ones someone bothered to work on; not that they followed any specific logic or order to them.

The advantage of copying all/some discrete subset of the templates in one fell swoop is we're instantly in a "shippable" situation. Classy's now no worse off than HEAD. You lay out your vision at once, not piecemeal. Everyone understands that from Day X onward they need to make markup bug fixes in two places (and the benefits of why they're doing that). Module templates can continue to get classes removed on an as-we-get-to-it basis, and if we don't get to them all, oh well. It's still better than Drupal 7.

The disadvantage is it's a really nasty patch that's big and hard to reroll. It also requires re-rolling those patches that took special care to both copy the template and modify the original. I don't see these outweighing the advantages, personally.

So my recommendation (and we should get confirmation from alex and/or catch to see what they think) is to take the path that gets us to a shippable state now, which then affords you to time to spend on the dream markup you want to do. The "path of least resistance" in terms of a shippable state at this point is moving all front-end templates (which no one disagrees with) to Classy in whatever directory structure you think is best in patch #1, then getting those "upstream" templates done and dusted de-classifying-wise in per-template patches #2 - N, and then seeing where you're at respective to the critical queue countdown when that's done and see if you have time to make the case for admin templates as well.

I agree with the bulk moving over of key templates to get the theme acting like a usable theme asap. And then we can clean up core like we are doing now.

Two people have messaged me in the last few weeks on how they should theme real d8 projects right now and I have to say you can't use Classy as it is, it hardly contains anything, just copy all the templates you need to a custom theme or to Classy yourself and amend them yourselves.

It would be terrible to do all this discussion, arguing and feeling like we are achieving things when in reality at the end of it as we run out of time we achieve nothing.

Edit: Apologies for disagreeing with some frontenders. I just feel at this point we need to do what is most efficient with the time and team effort we have available to us right now.

Dont get me wrong im perfectly ok with doing a mega patch, but we have seen that everything in the frontend is moving extremely slowly :(
So why would a mega patch do that faster, do we simply ignore the cleanup fase in core modules? and then fix that later, cause thats the core concept.

About not using classsy now... then people still dont understand what classy is (which maybe require me to write a loooong blogpost)
Classy is the default markup that drupal puts out - nothing more nothing less & at this moment

#88 You can use Classy now, sort of, there is a critical bug that gets well in your hair though: #2414255: Subtheme template inheritance working in reverse order

I use classy, from my point of view, in terms of timing, "some time before RC" is good enough for me. This is compatible with how everything else works pretty much, to be honest this is rather trivial by comparison to many other changes over the past 6 months to 1 year its not a big deal for madcap themers going at this now and chasing head.

Does that mean spending a week getting a megapatch right, and then waiting another week for a countdown when it can be committed because we need to notify everyone?

No, it means that as soon as the megapatch made it in, we'd publish the change record + probably post to g.d.o/core to notify people more broadly. No need for scheduling anything.

I've said my piece, you've said yours, assigning to alexpott to provide some feedback.

Although... I have to say I'm curious about this discrepancy:

@emma.maria in #88:

Two people have messaged me in the last few weeks on how they should theme real d8 projects right now and I have to say you can't use Classy as it is, it hardly contains anything, just copy all the templates you need to a custom theme or to Classy yourself and amend them yourselves.

@davidhernandez in #91:

Adding on the what Morten and Jeff said. There is no reason not to use Classy now, if you want the sensible defaults. It inherits all the templates it needs. People are not going to see any difference in the future as templates are added.

Obviously, we need to fix #2414255: Subtheme template inheritance working in reverse order so leaving that aside... I don't understand how you actually can instruct a themer to use Classy right now because of the very problem we're discussing.

What you want is the ability to write documentation like this:

"To start a new theme in Drupal 8, simply add the line base theme: classy to your theme's .info.yml file. Choose any templates you wish to override from the core/themes/classy/templates folder and copy/paste them into your theme, then modify them there directly."

But right now, said documentation would read like this:

"To start a new theme in Drupal 8, add the line base theme: classy to your theme's .info.yml file. If you want to override a given piece of markup, grep carefully for the location of that template file. Some are in core/themes/classy, but they could also be in core/modules/foo. (There's no way of knowing, really; it all depends if someone got it it yet or not). Once you found the location of the proper template, copy/paste it into your theme, then modify it there directly."

I think we need to get out of that situation ASAP, because until we do, we're hampering the ability for this initiative to move forward by making getting started in theming in D8 much harder than it needs to be, and onboarding new front-enders is essential to completing the markup cleanup you want to do.

I've also been telling people that they should use Classy to not break their themes. Beside #2414255: Subtheme template inheritance working in reverse order it should be all right to use Classy. If you override template it will stay as overridden even after we've copied new templates into Classy. When working on a theme template is not located in Classy you would just have to know to copy the template from modules (located in core or contrib) but this is very similar to the way it worked in Drupal 7 when you had a base theme. So people should be aware of that all templates might not exist in your base theme. Especially because of contribs.

I don't have a very strong personal opinion whether we should fix it by creating a mega patch or work on smaller issues. On that I want to trust on Webchick and other more experienced people than me. What I saw in Classy pt 1. was that it was easy to get the things done when the flow is good and you have people working on it.

But what we've been experiencing during Classy pt. 2 isn't unique to this case. The bottle neck in our project is people doing reviews. In Classy pt. 2 reviewing a patch is way larger task than actually writing the patch and that's definitely one of the reasons why it's so hard to keep it going. I don't know whether this problem would be fixed by merging issues to one or not.

I'd just like to say that I'm really happy to see the momentum here lately, RTBC's and commits :)

i can still go in with an axe & flamethrower and clean out core templates after mega patch right ;)
- cause thats on my bucket list. Lets get this first system hell over with, then we can set in an attack on views later on, when we have the css structure clean out & its clear to everybody why views also needs a solid amount of frontend love.
So when is megapatch coming ;)

i have restarted the discussion about how the templates should be organized in #2349559: [meta] Discuss the organization of subfolders in Classy first patch is up.

:)

#2349775: Remove classes from Views templates has been committed now =)

so we can officially close down banana part 2 ?

which three?

tagged for morten;)

Adding to Davids and Mortens queue

Thanks for tagging this for rc target triage! To have committers consider it for inclusion in RC, we should add a statement to the issue summary of why we need to make this change during RC, including what happens if we do not make the change and what any disruptions from it are. We can add a section <h3>Why this should be an RC target</h3> to the summary.

Sorry, I am coming into this a little late and trying to understand something.

I've also been telling people that they should use Classy to not break their themes.

So, what should contributed themes do that do not want to extend from Classy? Do we have to be redundant and set all classes and provide all templates that it does just to maintain expected behavior (block/field classes, etc)? If so, how many templates have to be provided in a contributed theme? Everything in Classy?

Okay, so its extending stable unless explicitly told not to.

In my case, I have my own base theme, with subthemes generating from it. We were trying to figure out what happened to the classes.

Can a base theme extend Classy that still has subthemes extending the original base theme (not Classy)?

So, Classy > contrib theme base > contrib theme subtheme?

Well then, that seems to work. I never knew you could chain them down like that. Thanks.

@kevinquillen I copied all the Classy templates to my base theme. It was either that or unset all of Classy's CSS (I don't want it). Those templates won't change in D8 so it's safe to do this + I was overriding about half a dozen of them anyway.

I bet it could be closed, there starter kit in core for that

As per #110 this looks like it's now a core (system.module) issue rather than a Classy issue.

Guess proper title

Given that it's been ~8 years and two major versions since any momentum of note, there's a strong possibility the there's been changes in the technical aspects or overall interest in this issue happening. This should be postponed until the requirements are made current, and we've confirmed the value of implementing those warrants the effort it would require.

In other words, this can un-postpone

• If it is confirmed this issue still worth doing 7+ years after the last notable activity
• Confirm this is still worth doing given that this was proposed at a very early stage in Drupal 8+, and making these changes in current versions is potentially more disruptive.
• The issue summary is updated to describe the steps with the current version of drupal.