[policy] Consider not supporting core module markup and CSS between minor releases

This is such an exception to BC policy that it will have to be well-written to apply to this specific thing only.

+100 for this exception.
Markup & css should not live in core it should be in the classy theme (the reason were moving it over) It won't change anything for those that are relying on drupals default markup, if a themer choose to rely on core (aka not having a "basetheme") then they are 99% of the time "elite" themer's and they know what they are doing.
What core is spitting out is a few <div> no classes no nothing.

This can cause issues for basethemes that wanna rewrite everything (we know who you people are ;)) - So with those in mind, they would have to pay attention to when we move a css file or move markup / classes to classy, but again if you not relying at all on drupals markup or css from the getgo, you have allready ignored what goes on in core so ... you asked for it you got it.

Yes, good points in #2. Classy is BC and will remain so.

This would mean anybody who wasn't extending from classy (custom theme or base theme) would either have to chase HEAD or copy and override every core template.

I'm a bit weary of this. Could be wrong...there may be workarounds.

Yeah, so we know the current policy is that everything markup- and CSS-wise is normally frozen after release. We want to see how much wiggle room there might be to change that policy.

I think it is very unlikely we'd get any budging on markup, as changing that would be the biggest breaking change for a theme. If a div randomly appeared or disappeared that could be hard to adjust to. However, it might be worth discussing whether we could still change things in the template that don't affect the outputted markup, like adding or removing CSS classes, which just modifies the attributes.

The main discussion is about changing CSS. Where we stand now, we are all concerned about the not getting all the CSS changes done we'd like, and having many of the CSS initiatives/plans/metas/whatever not being complete. We are working on moving all the *.theme.css from core modules to Classy. Is there wiggle room to do any of that after release? Is it possible to finish refactoring Seven or Bartik CSS after release? Is it possible to continue refactoring into components after release?

One thought is to formally declare that core CSS is "unsupported", meaning don't assume it will never change. Classy would be supported and should stay the same, serving as the BC layer. The problem with this idea is that people new and experienced are likely to create themes without a base theme and not even think about it. (Especially, since this hasn't been a policy in the past.) They would be affected by any CSS changing in core.

Lewis brought up the idea of modifying 8 to make Classy a base theme by default. So anyone that creates a theme would be using Classy without even specifying a base theme. In order to not use it (the Morten, pure theme crowd) you'd have to opt out and declare you don't want Classy as a base. Maybe setting base theme: core or base theme: none or whatever in the info file. And those themes would have to pay attention to changes in core CSS, but we assume since they opted out they know what they are doing. And we'd make sure changes were only in minor releases, not patch releases, and the changes are documented/announced.

Another idea that came up was not having CSS, and maybe markup (?), frozen at 8.0 release. Instead, leave open the possibility to get these changes in, but declare a later point release when everything is frozen. 8.2, for example, as the frozen release.

Regardless of the overall policy, I think we should also discuss Seven and Bartik separately, and whether they need to be frozen at all.

Yeah, so we know the current policy is that everything markup- and CSS-wise is normally frozen after release. We want to see how much wiggle room there might be to change that policy.

I don't think this is the current policy. #2550249: [meta] Document @internal APIs both explicitly in phpdoc and implicitly in d.o documentation says:

Markup, templates, and CSS
We will change the markup and templates for specific user interfaces for usability or feature enhancements, but we will avoid broad changes to markup or CSS that will affect more than one user interface.

This boils down to no freeze at all for specific interfaces (i.e. we could end up completely replacing one interface, even if we left the old one in for bc maybe), but something like entity/field/form element default styling might not be able to change at all.

However there's no distinction in that sentence between visitor facing vs. admin facing interfaces etc. which in practice is likely to make a difference. It'd be useful if the people in this issue could help flesh out the line in that issue - then we could apply that sentence to the CSS/markup changes here and see what sticks.

The least risky option is unfreezing the work in #2489460: [Meta] Move module.theme.css files to Classy which isn't modifying or removing CSS, it's just moving it to Classy. This shouldn't break anything for 'Stark' users as the CSS does not have mark up to apply to, so it's effectively doing nothing anyway.

Is that frozen in the sense of no-one working on it, or for some other reason?

...there's no distinction in that sentence between visitor facing vs. admin facing

No, but that policy discussion looks specific to internals, which I don't think we consider any of the CSS or Twig templates to be. That paragraph reads to me like it relates to things like adding a form element to an admin screen that didn't exist before. I'd be happy to help write out that section of the policy, but I need to know what the policy is.

If it is not written in stone that styling and templates are frozen, it would be good to outline exactly what can change. Up to now, I think we've all been under the impression that all will be frozen. I haven't heard anything from committers in the past to contradict that, especially templates. Changing a template is considered an API break. I've also looked through the history of D7 and can find little to no changes to any CSS or templates. I only found two; broken throbber and some RTL fix. So if it isn't a written rule, history indicates it is treated that way.

Is that frozen in the sense of no-one working on it, or for some other reason?

Frozen after RC. People are working on it, but we assume if the child issues aren't finished that they will get pushed to 9.x. That is pretty much how we are treating a lot of the frontend issues. That if they aren't completely by RC most (at least ones that touch css or templates) will get pushed to 9.x.

So I think it would be good to have clear examples of what can and cannot change after release. Not only do we need the policy to be clear so what know what things are actionable, but also so it can be publicized. We should make sure that people using D8 know which components have the potential to change.

Here are some things I think about:

Can a core template change in such a way that the markup it produces is different? Can tags change from one type to another? Can a level of nesting change? Can attributes change? (printed or not printed, and values) Can logic change? (For example, a wrapping 'if' statement where there wasn't before.) Can template names change? Can a theme function be converted to a template file after release? Same questions for Classy, Seven, and Bartik individually.

Can core functional CSS change? Can core styling CSS change? How about CSS file names? Whether or not specific CSS files are included or not on specific pages? Can the path to specific files change? Can CSS be refactored, such that specific declarations change but there are no visual regressions?

Most of this does not involve a feature enhancement of any kind, but lets us fix problems we know exist, in particular inconsistencies.

In general, what is considered supported? Almost any of these things could result in someone needing to make an adjustment the their theme to compensate for the change.

Seven and Bartik we should probably mark @internal - so that people know they're not supposed to build themes off them (except perhaps by copy and paste, then changes don't matter anyway).

If it is not written in stone that styling and templates are frozen, it would be good to outline exactly what can change. Up to now, I think we've all been under the impression that all will be frozen. I haven't heard anything from committers in the past to contradict that, especially templates. Changing a template is considered an API break. I've also looked through the history of D7 and can find little to no changes to any CSS or templates. I only found two; broken throbber and some RTL fix. So if it isn't a written rule, history indicates it is treated that way.

Well we might not be able to change the actual templates, but we can probably do something like:

- add a new module
- override the template in a module
- enable the module by default in all core profiles
- leave it disabled for existing sites

Then there's no way for it to break an existing site, and contrib/custom code can rely on it by adding a dependency on the module.

Or do it backwards and put the old stuff in the module overriding the updated stuff, but add an update to enable it for all existing installs, keep it disabled by default in new installs. Then 9.x just rm -rf the module.

Can a core template change in such a way that the markup it produces is different? Can tags change from one type to another? Can a level of nesting change? Can attributes change? (printed or not printed, and values) Can logic change? (For example, a wrapping 'if' statement where there wasn't before.) Can template names change? Can a theme function be converted to a template file after release? Same questions for Classy, Seven, and Bartik individually.

Can core functional CSS change? Can core styling CSS change? How about CSS file names? Whether or not specific CSS files are included or not on specific pages? Can the path to specific files change? Can CSS be refactored, such that specific declarations change but there are no visual regressions?

A lot of this we can probably do with optional modules too.

With this "other" module, you aren't just talking about new features, correct? You mean put a new version of the page template in that module, but leave the old one in system to maintain BC? My brain needs to absorb some of that.

I think we'd all be on board with declaring Bartik and Seven internal, if we the committers are on board with that. A lot of refactoring still needs to be done, so continuing to work on it after release would be desirable.

I think that this workaround would eventually result in a really confusing themer experience.

Well yes it would, but so do backwards compatibility layers for module developers. This is why there'll eventually be a 9.x release that drops the bc layers.

If we move the old functionality to the new modules (which you can then disable), then themes could specify incompatibility to completely ignore the old stuff (or alternatively depend on the old stuff if they don't want to update).

If we want to maintain a reasonable expectation of contrib/custom themes not breaking every minor release, but still be able to refactor things, we need to have some kind way of doing it, which will usually not be pretty in itself but allows balancing both concerns.

+1 on making stark & seven internal.

Maybe im reading this wrong so sorry for if im missing everything. But arent we missing the whole point of classy & stark, and what themers are gonna use this for ?

If we look at the original concept on classy, it was build for people that was relying on a predefined markup provided by drupal. They would use the classy theme. if you want to be in control you would not be using classy, your expecting to not get anything (and probably gonna overwrite every template that you can find)

It sound like we now suddenly have a scenario where a themer "using stark" (which they wont do - lets be real here - they will write their own) is expecting to rely on the markup - that was afaik never the concept behind splitting the theme out into classy vs stark.

I would argue that themers that are not gonna use stark will know & understand that they will have a predefined variables to work with and expecting core functionalities to work (quickedit, toolbar, wysiwyg, login password indicators) but if stark get a .foo class moved, then that will not be an issue - if its a js-foothen its gonna be an issue.

Classy can't change its classes/markup that comes out but we can move a class / template from core into classy, cause thats where it should live.

OK I just confirmed with @alexpott and he and I both think we've said sorted this out before, and that it's actually the same as #17:

Core templates and CSS which are not in classy now, could be moved to Classy in minor releases.

If your theme depends on Classy there is no backwards compatibility break.

If your theme does not depend on Classy, then we assume you did not want the extra CSS/markup anyway.

CSS/Templates in Classy get treated as @api.

It would be good to document this properly both on https://www.drupal.org/theme-guide/8/classy and https://www.drupal.org/node/2562903

Marking RTBC and I think we can close this once that's done.

@catch do you have a definitive answer on treating Bartik and Seven as @internal?

I'm happy with Bartik being marked as @internal. There's a lot of refactoring left which on the most part will be standalone to the Classy theme and Core. Bartik has also become a learning tool for beginners to Core and for selfish reasons I don't want to lose that after D8 is released also.

As David has said in #19, there is no definitive mention of the @internal decision on Seven and Bartik within #18 which is the RTBC comment.

As far as I remember that's been the intention for a while.

I posted on #2550249-37: [meta] Document @internal APIs both explicitly in phpdoc and implicitly in d.o documentation in case I mis-remembered.

Moving of CSS from modules to Seven - wouldn't that break an admin theme that depended on Classy?

Most of this sounds good (esp. marking Seven and Bartik as @internal so we can continue to improve them throughout D8's release cycle), but how do you reconcile the fact that some Drupal end users will have a stable theme between minor releases (because the themer they hired used Classy as a base theme, and that is @api-ish) and others' themes could break every minor release, forcing them to re-hire a themer to fix it (because the themer they originally hired used Stark/core as a base theme).

It almost seems like we need a per-minor Stark (maybe in contrib?) that copies in all of core's templates at that given minor so that themers who are in the position to handoff a site to someone non-technical can give them a stable base. Or else I'm not sure how to handle the situation of, "We told you we wouldn't break BC in minor D8 releases, but oops now your theme is all screwed up and the only way to fix it is to dig into the code."

@webchick its called job security now that we made the theme layer easy to use :P

Having backwards compatible version of stark 8.0, 8.1 etc in contrib could be a solution - even that could be an headache to get out each time, but we would not leave anybody in the dust. plus we dont wanna pollute the core/themes/... with a ton of versioning of themes, that would make everybody unhappy.

@webchick, I don't think there is a good internal solution for that, unless exploring @catch's suggestion from #12. I'm still assuming we just aren't going to make those changes. Not because we don't want to, but because, as you've noted, it is going to break things.

I also want to point out that using Classy as a BC layer doesn't work unless you are already using it. Classy's templates are already different from core's. If we want to make a change to a template in core, we can't move that change the Classy. Classy already has it's own. This would only work in the cases where Classy does not have a version of that template, and we could only do it one time. But still, that is assuming you are already using Classy and not core. If you stick with core, you would see your markup change.

That is why I'm betting that regardless of policy we'll just end up not doing it unless we either have a "screw you, pay attention" policy, or a technical solution that requires no intervention. #12 was the only I've seen that could do that. I'm not ok with having BC compatible versions of core in contrib as we progress, and telling people that is how they deal with it. That sounds burdensome. Too much connect the dots is required. Maybe .... maybe if we included them in core instead. But then we're really in a situation where we make the base theme setting mandatory. I think that is a philosophical shift that we are too late for.

and others' themes could break every minor release, forcing them to re-hire a themer to fix it (because the themer they originally hired used Stark/core as a base theme).

If we mark Stark as @internal does that help?

If you have custom code written for your site that's not following best practices, then it's quite likely that it'll require developer intervention to get between minor releases. That's going to be the same both for modules and themes. A custom theme based on Classy or a contrib base theme should be fine (if the contrib base theme maintains bc at least).

In general we've said that for sites that don't want to do a minor update every six months should wait for LTS releases (i.e. stay on Drupal 7 until the 8.x LTS is out), where there's absolutely not maintenance going to happen at all that's the only option - then you can update for security and nothing else then.

If we mark Stark as @internal does that help?

I think we are mixing terminology. Some people are referring to Stark to mean "using the core templates"?

Stark itself I think should be marked @internal. There is no reason to use it other than for testing and/or just viewing things because you haven't made a theme yet.

...wait, now that I think about it maybe I'm confused? Did someone say to use Stark as a BC layer? We could do that I guess. Use Stark as a base theme to get the core templates, but if we change them, we move the old template into Stark. We'd still only get one shot at changing a template though, unless we keep making versions of Stark in core (Stark will need version numbers.) I still think that sounds like cruft.

Well it's OK to add cruft if we can add it in such a way that it's self contained so we can just rm -rf it for 9.x. Obviously if we can maintain bc, make changes, and not add cruft that's better though.

The question we need to answer is should someone that builds a theme directly against core (not using Classy) be guaranteed the theme will continue to work exactly the same, with zero intervention, from 8.0.0 until the end of 8's life? Markup and CSS include.

I forgot to add, my point being that decision is what will guide what changes we can and cannot make in the future. It does not matter if we policies on particulars, if that question isn't firmly answered. They will come into conflict.

I was saying "use stark as a base theme" as a short-hand for "just use bare core templates."

And what I'm getting at is there are two audiences here. The theme developer may well be following best practices by basing their theme off core's templates, since core's templates were specifically written to remove crufty classes and divs and other things that are unneeded. It's Morten's dream markup, and we want to attract more themers like Morten, not force them to use Classy as a base theme just because they want to hand something off to a client before LTS.

The other audience, however, is the end user of a Drupal site. They've been told that Drupal 8 will retain BC between minor releases, and that is what they will remember since they couldn't hope to parse something like https://www.drupal.org/node/2562903 in a meaningful way; that language is for developers, not for end users. It is reasonable therefore for them not to expect to retain a themer on staff and/or consulting hours with a themer every time they go to do a minor version upgrade. If D8 breaks in between minor versions, they're going to blame Drupal, or their rip-off themer.

I don't think we necessarly need a solution in core for this, but IMO we do need a solution for a hypothetical Morten who doesn't want to be forced to either a) use Classy as a base theme or b) wait to build D8 themes for clients until some unknown time years from now when D8 is on LTS. That would throw out most of the gains we got from this markup division in the first place.

So my suggestion was to keep a copy of Stark (or some other clever name) in contrib, and make a tagged release each minor version of D8 (8.x-1.0, 8.x-2.0), which consists of copies of the D8 core templates for that version. Then the hypothetical Morten, once he's done building the site for the client, simply sets his base theme to that theme/version, and BC is preserved, and everyone's happy.

Bumping back to CNR.

I think we have to freeze then. Having a contrib project serve as the gateway for this doesn't strike me as any different than using mothership or some other base theme. If it isn't in core, people will miss out on it, or not know they should be doing it that way. That still results in the scenario of some unsuspecting person relying on templates or CSS that can change right from under them with an update. If there is method of using core where you will see changes, there is going to be some percentage of the user base doing it, whether they chose it or their dev did.

Unless we do the catch option of making BC modules or maybe the previously proposed "make Classy a default, you have to opt out to not to get it". But even both of those have their problems, as there are some things that are impossible to keep functioning. I don't think there are a lot of options for making breaking changes but still allow a site owner to run updates without anything changing.

Just to add I think this is becoming less of an issue for templates now. We've cleaned up quite a bit. CSS is a bigger issue. There is still a lot of work to be done.

Well, or ship with that suggestion in core vs. contrib. To some extent I buy the cruft argument, but to some extent I don't. I thought shipping with "cruft" (meaning older versions of things that used to be standard fare in earlier versions of D8) was also how we were going to address the issue of upgrading front-end libraries in 8.1.x, 8.2.x, etc. in a BC-compatible way so we're not stuck on some old shitty version of jQuery forever. (Can't find that issue right now, but hopefully you know what I mean.)

Here it is: #1787222: [meta] Strategy for updating vendor JS libraries within a major stable version

So another possible option for CSS would be:

- move the CSS from core modules to Classy
- add a library alter in a core module, which alters back in the CSS - referencing the files in Classy
-if that's a new module you can uninstall it, or if not it could have a $settings check to disable the alter.

That way the CSS moves, people who want to opt-out of it can do so easily using just core, all existing sites (or including every new site by default too) would be opted in, the backwards compatibility layer is self-contained, and can be deleted easily for 9.x

Hm. That sounds more complicated than a copy/paste job every minor release to me. :)

Is the idea that'd be "Legacy" module, and the hook_library_alter would just have switch statements in it for every single module so that if it's enabled it pulls in the CSS from somewhere?

Yes I also don't get the cruft argument.

We're going to accrue cruft during minor releases for all kinds of things - as a result of keeping backwards compatibility layers for things we refactored. That's the trade-off with being able to refactor during a stable major release cycle at all.

The important thing is to keep the cruft self-contained and not littered all over the code base as much as possible, so that a 'remove all backwards compatibility layers' patch is just a lot of deletions and doesn't require any refactoring. And especially for front end to allow sites to run without the old cruft if everything's up to date.

I understand how that can maintain compatibility, putting cruft aside, for moving the files. I don't think it helps us if we want to make changes to those files, correct? If we need to fix declarations, class names, or anything else in a core file we're frozen. (same with Classy) I guess we could move the old file to this BC module and do the same, but that doesn't sound like something we'd want to do every time. Would this be only in minor releases, and all the changes we want to make would be bundled together in one BC module for 8.1 and one for 8.2, etc?

I can't wrap my head around how that would work if you started on 8.0 and core is at 8.5. Would you have all the BC modules installed, and we have to make them work together checking for visual regressions with them all combined?

The good news is I'm looking through core to find CSS to use as an example, and there is so little of it left. :)

+1 on the stark concept lewis - in that way we can move css files & markup from core to classy as it should be.

"basetheme : stark832 " will save the group that are depending on "stark"/core maybe even without knowing it (huh basethemes whats that) with 1 line of code.

Yes we will then have 8.32 at somepoint, but that will make it possible for us to correct & polish whatever mistakes have been done so far & make stuff better.
By using "stark" as a theme name that will actually give stark some meaning instead of now where nobody knows the difference between stark & core - and why are they not different things etc

afaik john albin is mainter of stark, so we allready have a maintainer ;)

Theming:
core is core, clean as snow.
stark is "naked" drupal but versioned so we have fallback for releases.
Classy is where its at.
seven & bartik are internal so thats that.

To me that makes a lot of sense, and imho not afraid of the cruft, i will rather have that instead of having to live with "why on earth didnt we do foo" now we have to live with that
As a sidenode we should run an optimized version of classy, where we can experiment etc so we have an alternative to the html hipsters, but thats another idea

I still go back to the original question, do we need to guarantee that a site built on 8.0, regardless of how it is built, can continue working without visual regressions for the life of D8? It sounds like a yes, and that will guide the post-release work we do. There seems to be wiggle room to make some changes post-release, if we have backwards compatibility. I'm less concerned with the solution at the moment. I just want to make sure the policy moving forward is clear.

Regarding #2550249: [meta] Document @internal APIs both explicitly in phpdoc and implicitly in d.o documentation, the text then needs caveats.

This is what I'm understanding:

A site - and this does depend on the site, not just theme - built on any version of 8 can freely update any patch release and minor release without experiencing visual regressions, which means they functionally get the same markup and CSS in perpetuity. However, we do not guarantee newly built sites on one minor release of 8 will get the exact same markup and CSS as a site built on another minor release.

I don't know how that second part would actually work with contrib and things people want to reuse. A theme or module built to work with 8.0 would not want to tag a release for 8.0 and another supported release for 8.3, or whenever something changes in core. And if I built a theme for a site originally built on 8.0 I'd have to verify that it works on 8.3 before using it.

This sounds like not using Classy will definitely be the advanced option, really advanced option. Like sign the release form on the dotted line before proceeding advanced. Which is fine if you have staff and can keep up as things move, but should be avoided from a support perspective.

I still go back to the original question, do we need to guarantee that a site built on 8.0, regardless of how it is built, can continue working without visual regressions for the life of D8? It sounds like a yes, and that will guide the post-release work we do. There seems to be wiggle room to make some changes post-release, if we have backwards compatibility. I'm less concerned with the solution at the moment. I just want to make sure the policy moving forward is clear.

Well. I could be sniffing glue, but AFAIK kind of the entire idea of semantic versioning, is BC within a major release:

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible
   manner, and
3. PATCH version when you make backwards-compatible bug fixes.

Stuff marked @internal (per https://www.drupal.org/node/2550249) is exempt. But that marker's reserved for things that are, well, internal. :) Specific forms/pages of specific modules, tests, database columns, etc. Stuff that "if you're calling this directly from your module/theme, you're really doing it wrong."

But default markup/CSS is not that, it's rather the exact opposite, it's "the" API for themers who are not using Classy. Marking it @internal would mean no one could reliably build any non-Classy themes until Drupal 8 LTS which might be in 2017 or 2018. While we could do that, it seems like a huge waste, and against the spirit with which the dream markup vs. class markup split was done (attracting more designers).

So if core's default markup is in fact /not/ internal, that means that we need to make improvements in a BC way, in order to respect semver. That's my understanding, at least.

Right, agreed. So catch's comment #37 in the other issue is somewhat misleading. I think this more broadly restrictive, because there will always be a scenario where regressions can happen if we make certain fundamental changes. For example, renaming/moving assets.

Had a great impromptu discussion at DrupalCon with @catch, @lauriii, @joelpittet, and @Cottser on this topic.

Both catch and I raised our various wild and crazy ideas for allowing old markup to stick around for sites that needed it. The problem is that any copies of old markup exponentially increases the maintenance cost of making bug fixes, esp. given there's no automated front-end testing. While we could try and document this condition of "core default = wild west," the problem is that's exactly what Drupal newbies will end up with, who are the least capable of helping themselves.

Thanks to a flash of brilliance from @Cottser, here's where we landed:

Let's add a new base theme that the Mortens of the world can use as their a base theme (TBD: Bikeshed the name. Let's call it "Blark" for now.), which is:

1) simply a copy/paste of all core's CSS/JS/markup before 8.0.0 (corollary to Classy's "locked" markup)
2) marked @api to indicate stability (also like Classy)
3) Is used as the default theme if base theme: false is not defined in a theme's .info.yml file (we would want to do this in Classy).

This would allow us to change core markup willy-nilly, while protecting the "Morten's clients" of the world, and also preventing experienced front-enders who are new to Drupal from accidentally landing in the wild west.

Thoughts?

I knew we discussed something like this on one of the Frontend/Twig calls, so I'd like to give credit to @LewisNyman and @davidhernandez and @mdrummond and others for the seeds of this idea. We were talking about making Classy the default but we had some of the building blocks :) https://youtu.be/93S2Xzyluy4?t=28m40s

I'm not sure that really helps us as much as it sounds. For one, how would we manage the libraries? They are still provided by the modules to include their CSS and JS. The other problem I see is what we want to do is things like make template changes. Most of those, in the future, are probably related to theme system changes we'd want to make. (adding/removing/modifying variables or whatever) If that happens, we'd still need backwards compatibility in the Blark, Classy, et al templates.

What percentage of themers do we think would be this group? We are recommending Classy to most people I imagine a large percentage of the Morten camp would actually be in the Blark group, because they don't want classes and divs, but they also don't want the rug pulled out from under them during an update. So is the wildest of the wild west actually a really small group?

We'd have to copy all of the CSS and JS to Classy as well. We've only been moving the .theme.css to Classy, not all of it. And I don't think we want any JS in there.

I think it would still preclude us from make name changes. Stylesheets remove, the twig include/extend, template suggestion, and some other things are very path and name dependent so we'd have to program in some BC weirdness to keep specific track of the things we change. If someone does stylesheets remove on system's ajax-progress.module.css we can't rename or move that file, or play musical chairs with what rules live in what file. So we try to figure out how to have a copy in Classy and in Blark and in core? The rename maintenance-page into page--maintenance is another example. Can we change those suggestions after release and make it BC? We'd have to keep track of the old suggestions.

It would definitely help in the case of "lets remove this div or class name from this template" but, honestly, I don't know how much of that we'll do after release, and that is the one problem that is easy for people to deal with on their own. The question is how well does it protect other kinds of changes? It might be helpful to detail some specific things we might want to change and see how the scenarios play out.

Also, for me at least, part of the motivation to make changes is to fix problems. If 99% of the sites won't ever see those fixes, what are we doing?

Just briefly, Blark would still get things we consider as bug fixes. I need to think some more about the JS/CSS/libraries but I don't know how else we can reasonably easily keep plugging away AND also satisfy these different groups.

The idea I had behind that solution was to move any CSS or JS that we want to change to Blark so that they'll be loaded instead of Cores ones. That would be done by library alter. That way when ever we have a Drupal 8 LTS release we can copy all the templates from modules and break the BC.

I also don't think the scope of this issue or core changes would involve changing theme hook names or consolidating or things like that. If we wanted to do that we would have to handle the BC in Classy and Blark, via registry alter or similar. We can do BC things.

PS. Classy would actually extend Blark.
PPS. Emma suggested Standard, which sounds nice to me.

Library alter is keyed on the library name, correct? I think we can use it to swap the files, but how does it affect processing? Would the new files get processed in the same category and show up in the same order as the previous one? Would files specified with stylesheets-remove get correctly altered?

Ordering is definitely a concern for me if a file moves. CSS coming from modules gets loaded much higher than ones from themes so if the file used to come from system, and then comes from Blark, it not only drops further down in the order, but it also ends up in the grouping with all the other base theme and sub theme CSS files, which means it can end up below sub theme CSS.

I think the problem is library assets don't have their own named keys in the library config. I was thinking about this the other day. If assets, and templates, were identifiable by name instead of by actual file name and path, we could play more tricks with them. For example, the problem of modules wanting to choose Classy templates.

This also gets us towards this idea, that I think I first heard Fabian mention, of turning the entire frontend into an independent library. Or have parts of it be separate libraries. That would solve most compatibility problems because we can version it.

I will try to put together a proof of concept on a separate issue, if anyone wants to help let me know.

New child issue: #2575421: Add a Stable base theme to core and make it the default if a base theme is not specified

Should we get the necessary signoffs after we've written up the plans? (see needs tags)

In the meantime I'll be working on a proof of concept.

I think we have agreed on this. I'll mark this RTBC.

Yes I think this can be marked fixed now - Stable is in. Adding commit credit here because a lot of work went into this issue and the related discussions in Barcelona.