Problem/Motivation
We should move Color module to a contributed project since as it stands, it doesn't provide enough flexibility to be useful for the majority of sites. To be able to create website matching to corporate identity, you would probably want to change at least background images and font families as well.
Umami was decided not to provide support for Color module, and it seems like the group working on a new frontend theme for Drupal (eventually replacing Bartik), has also already proposed not to support color. After Bartik has been replaced with the new frontend theme, it will likely be moved to contributed project. This would also mean that Drupal core will likely end up in a situation where it has no themes supporting color module.
Some of the accessibility maintainers of Drupal core have recommended not to integrate color module into new core themes because of its lack of color validation for accessibility. Color module also doesn't have an active maintainer or active contributors to solve these issues.
Removal has been discussed before on #1255674: [meta] Make core maintainable. On this issue, people mostly state that it should remain since it doesn't have many bugs and it is quite easy to maintain. While it is correct that there haven't been many bugs reported in color, it does still add extra complexity to the process of creating new core themes. This combined with the lack of flexibility besides changing colors and open accessibility issues seem feels like enough justification to support the idea of moving the module to a contributed project.
Proposed resolution
- Create a patch to remove the all it's dependencies from tests, themes, modules, profiles etc.
- Deprecate the module from 8.x to be removed in Drupal 10.0.0
- Set up Color in contrib: http://drupal.org/project/color
- Remove Color module from Drupal when Drupal 9 is released
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#6 | move_color_module_to_a-2808151-6.patch | 1.06 KB | lauriii |
#30 | gutenberg-color.png | 278.52 KB | webchick |
Comments
Comment #2
joelpittet+1 to deprecate and remove from standard install profile
Comment #3
tvn CreditAttribution: tvn at Drupal Association commented+1, sounds like a good idea.
Comment #4
tstoecklerI think this is pretty much a no-brainer.
- Almost no benefit to real sites, regardless of whether it's an enterprise level site or just someone trying Drupal for the first time, it's a real niche use-case
- No innovation for 5-10 years
- (Arguably) conceptually flawed (to pick the site's colors in the browser). At the very least very uncommon for core to provide such an opinionated niche feature.
- No maintainers
Comment #5
lauriiiComment #6
lauriiiI'm not sure if we should mark color.inc in Bartik deprecated or with @todo to remove it after Color module has been removed.
Comment #7
dawehnerThis certainly needs a product manager for sure. I think the fact that we have color module in color just shows how despairing we need a better theme.
Comment #9
cilefen CreditAttribution: cilefen commentedAFAIK anything needing product manager review belongs in this queue.
Comment #10
naveenvalecha+1 good idea to mark this as deprecated now to be removed in 9.x
Comment #11
davidhernandezThis might have to be 9.x. I'm not sure people will go for this since Bartik currently supports it. I don't mean it isn't technically possible to remove, just that doing so would remove an out of the box feature for evaluators and other people that might actually use Bartik. We might need to get a new default theme in first.
Comment #12
tstoecklerWell we could still "deprecate" in in 8.x and remove it from being a requirement for core themes.
Comment #13
joelpittetAnd maybe remove from default install profile
Comment #14
izmeez CreditAttribution: izmeez commentedWhen first discovering drupal, years ago, seeing themes with the color module feature allowing one to change the appearance was a real positive.
Comment #15
phenaproxima+1. I don't think there is any good reason for the Color module to be in core. I understand that it's impressive and useful for some, but I personally have never used it on a real site and I don't know anyone who has.
Comment #16
jmuzz CreditAttribution: jmuzz commentedIt seems like a good idea to me.
Since this is in the idea queue now it doesn't need to be needs work because of a failed test.
Comment #17
JurriaanRoelofs CreditAttribution: JurriaanRoelofs commentedI can volunteer to maintain the contrib module, I work with color module regularly and understand its internals. I'm actually looking forward to be able to fix some things about the developer experience of the module. My experience: have been building themes with it for almost 10 years, all these designs are recolorable with color module: http://www.sooperthemes.com/#Drupal_Themes
One thing to worry about: moving the module out of core will inevitably (visually) break user's sites, since not everyone reads release notes..
Comment #18
dawehner@JurriaanRoelofs
Thank you a lot for stepping forward!
Comment #19
Neograph734I had been secretly following this issue as it would affect my possibilities with the White label module (currently porting to D8). I am not interested in maintaining yet another module, but if Jurriaan would be interested in some help, I'd be happy to think along.
Comment #20
Jeff Burnz CreditAttribution: Jeff Burnz commentedDeprecate in standard actually hides really great feature from new users, a feature we know they love, we know this empirically from data collected in past user interaction tests.
I am confused as to why Drupal core has vision to remove much loved features. Seems to be we may be forgetting who we're building new core themes for exactly.
Sure I'd love to see markcarver take this over, he has the space, and huge vision for this module going by previous issues.
If he is not available, and we really actually do this (not good idea IMO), I would take it over also, with marc and jurrian, if we can wokr together :) Jurrian and I both have vested interests, lets be frank about it. But we also want the best for Drupal also.
Comment #21
lauriiiThis idea has not been approved, so we don't know what is product managers opinion on this.
The reason I proposed this was that in core the use cases for this are getting less relevant since we want to build themes for a more specific use case rather than being overly generic to make them more appealing with less work. I personally see that this feature has plenty of good use cases but it doesn't mean it would have to be included as part of Drupal core. Moving this module to contrib would be also a great opportunity for issues like #445990: [META] Refactor color module to happen with less work, therefore making it more motivating to work on that.
@Jeff Burnz: Since this idea has not been approved yet, it would be great to hear why you think it's not a good idea to move the color module to contrib.
Comment #22
Jeff Burnz CreditAttribution: Jeff Burnz commented1. Because people like it, a lot. You will not be improving Drupal core, but making it less attractive for new adopters. New themes should really be colorable, you can easily build specific use case themes with color module, Jurrians work is testament to that.
2. Because we loose control of the API. There is a lot of investment in contrib for stable API, if this is D9 we're talking about, that is less important IMO.
3. Themes can't declare modules as dependancies (yet, this might happen).
I have other reasons also, but limited time to give them the treatment right now.
Comment #23
phenaproximaMy full $0.02:
Correct me if I'm wrong, but I don't believe the themes currently bundled with core are colorable. In any event, we should not be giving new users the impression that all Drupal themes are colorable.
When you say "people like it" -- which people, exactly? I'm quite skeptical that developers (front end or back end) are very impressed by Color. For non-techs, well...quite frankly, there is so much more that we could do to improve other areas of Drupal core, that would be much more useful and no less impressive to less technical folks. It's like...okay, we can tweak the color scheme...but there's no easy admin-facing way to manage media assets or page layouts. Color is impressive on a surface level, but I think that only serves to obscure (temporarily) the areas where Drupal core is still deficient. Which all users will run into sooner or later. The maintenance burden currently imposed on core by Color -- not a very large one, to be fair -- is better allocated elsewhere.
Color is a toy. It is most useful for very small-scale sites, like blogs, with only one (or maybe two) site maintainers of limited technical ability. When it comes to more involved sites (i.e., any that involve a developer or a themer), I daresay that very few themers are going to want site admins (or other privileged users) arbitrarily messing with a site's color scheme. When that IS desired, contrib should be able to step up to the plate. Color, IMHO, is a textbook case of a core module that has long outlived its relevance.
Comment #24
davidhernandezBartik is colorable. None of the other core themes are. The new core theme being worked on will not be.
Comment #25
izmeez CreditAttribution: izmeez commented@JeffBurnz
I think this is a good observation. I know that when I first stumbled upon drupal the color module in themes was a very nice feature. Granted a lot of themes don't use the color module and I don't use the color module with some theming but it's helpful to remember what first impresses people with a platform.
I was also wondering why it was being considered for axing from core.
Comment #26
phenaproximaIn my view, the fact that Color is impressive to new users means that it should be moved to contrib and incorporated into a distro or installation profile that is built specifically for demo purposes, like Acquia's Demo Framework. I think core should only include those modules that will be most useful for the maximum number of common use cases, which (based on no hard data whatsoever) is not a criterion I think Color fulfills.
Comment #27
megan_m CreditAttribution: megan_m commentedIt would be helpful to provide links to the the issue(s) where the "the vision of Drupal theming in future" was discussed. Based on that it seems like this has already been decided.
I am working on a new contrib theme now, and I think having color module makes it much more useful. If I don't have that then there's not really much point in releasing it. I would be cautious about depending on a contrib theme to do that.
Color module is hard to implement for legacy reasons. Ideally it would be completely scrapped and something new built that would be a lot easier to implement (and also a lot easier and more fun to use). It seems like the difficulty in implementation is part of the argument for removing it. I don't understand why themes for a specific use case shouldn't be colourable.
Including a theme customization tool decreases the barrier to entry for Drupal sites. Wordpress has a nice one, as do lots of SaaS tools. It's fun to play with when you first get started, and gives people a good impression of the product. If Drupal doesn't have a standard way of doing this then people might go to another platform that makes it easier to customize a theme.
Comment #28
pingwin4eg@mmcdermott There's a plan to #474684: Allow themes to declare dependencies on modules.
A theme would just need to add
to its .info.yml file.
@all COLOR IS NOT GOING TO CEASE TO EXIST! It's just moving to another repository.
Comment #29
andypostColor module has no maintainer yet
Comment #30
webchickI was asked to chime in here wearing my product manager hat. Not removing the tag yet because these are just initial impressions, not necessarily Product Management Sign Off™ (kinda want to ask around a bit more before that).
But:
- I do agree that it's a useful feature for end users / evaluators / less technical site builders. I have fond memories of Drupal 6 days, sticking the client in front of Colour module, and by the time they'd decided on a scheme, I had their content model already built out and they were like 🤯. I would also say that some level of in-browser look and feel customization is a pretty basic expectation of CMSes today. (WordPress has it, SquareSpace has it, etc. and yes I know We ArE NoT WoRdPrEsS aNd SqUaReSpAcE, but nevertheless we should always strive towards providing a default user experience that delights, or at the very least that people don't actively hate ;), like these other tools provide.)
- Since the Drupal 6 days, however, the end user expectation for these kinds of front-end customization tools has gone way up. For example, Gutenberg (~25% of the Internet) allows you to select foreground/background colour on a per-block/paragraph basis, as well as font styles/sizes, swapping out "featured" images, etc. So I think it's worth asking whether keeping a feature in core that's so obviously out of step with what our competitors are capable of actually hurts Drupal more than it helps it.
- It looks like @Jeff Burnz tried to make a valiant case for keeping this module in core, rallying a team to maintain it, etc. a couple of years back. However, unfortunately, this effort did not seem to materialize. https://git.drupalcode.org/project/drupal/commits/8.8.x/core/modules/color shows really no changes to this module apart from core-wide conversions, e.g. removing deprecations, applying JS standards, etc. in at least three years (a couple of bug fixes in Dec. 2015 are the most recent that seem genuinely Color module related).
- I know the accessibility team also hates this thing because ATM it's basically a UI for choosing inaccessible colour schemes. ;) (Which could be resolved with some kind of check/warning/education system, but once again with lack of maintainership...)
- While it might nevertheless still be helpful in a demo situation, if it's moved to contrib and just becomes an extra dependency in your .info file, it's hard to make the case that removing it from core creates an unreasonable burden there.
So TL;DR I think I would support its removal in its current form, though long-term IMO we should actually think about developing a mechanism for providing more rather than fewer in-browser look and feel customization options, as long as they have built-in respect for themers' design choices and accessibility constraints.
Comment #31
webchickAnd tweeted here in a futile attempt to get more outside / end user opinions. https://twitter.com/webchick/status/1148377202590797825 (we already have plenty from devs and experts here)
Comment #32
webchickAlso, arguing against myself for a second, we do know from usability testing that customizing the look/feel of a default website to make it more "your own" is basically the first or maybe second thing someone will try and do when encountering a new CMS. Removing this module makes that much, much harder, because the UX for installing a new theme from the UI is catastrophically bad, all of the top themes are base themes which provide basically no look and feel, and so basically, your first 10 minutes with Drupal will involve knowing how to code and hacking core to change CSS, since there's absolutely zero chance you'll know what a sub-theme is, what directory custom things are supposed to go in, etc.
So, hmmm. 🤔
Comment #33
mherchel+1 I've used Drupal for over 13 years, and have not once ever used the color module 🤷♂️
Comment #34
cweagansWhere was this decision made? I'm curious about why/how that conclusion was reached. Additionally, the order of decision making here seems strange: the new theme isn't going to use color module, ergo color should be removed. Shouldn't it be the other way around?
From an end-user perspective, we're porting 300 D6 sites to D8 and we're planning to use the Color module pretty extensively as it's a really common need (as webchick noted). Would this discussion look different if there were a maintainer or two? For my specific use case, I don't care that much if it's in core or contrib, but if it's in contrib, I'd wager that it sees less use than it currently does.
Comment #35
geerlingguy CreditAttribution: geerlingguy at Midwestern Mac, LLC commentedI guess I feel a little weird admitting this... but I still use color module for a site or two, and one D7 theme I haven’t yet ported to D8 also integrates with it. It would be cool if it had more functionality associated with it (e.g. could integrate with sass or less and or other theme system components), but to webchick’s earlier point it is a far cry from the kind of front end design-y tools others use outside of Drupal.
For my purposes, it doesn’t really matter if it’s in core or contrib, though. It would be interesting to note how many Drupal.org project themes have color module integration, too.
Comment #36
lauriiiComment #37
andypost+1 to move to contrib - at least there it could get changes to be maintained
On custom projects we using color a lot but with many hacks for domains and so on
Comment #38
andypostComment #39
gaborkurucz CreditAttribution: gaborkurucz at Pronovix commentedWith CSS custom properties getting more and more support (only IE doesn't support it now) the color module is making even more sense.
Although I don't have a good argument to keep it in core, we're actively using it on our projects at Pronovix so some of us might also volunteer to help with the maintenance if it was moved to contrib. It would be also great to merge the core Color module with https://www.drupal.org/project/color_field.
Comment #40
webchickThe issue summary update from #36 states that the team from #3064880: Create new default front-end theme is proposing not to support Color module in the new default front-end theme. Let's flip this question around, then. What validation has that team done to ensure that removing support for recolouring the default theme meets the needs of new users, given that we know customizing the look and feel of their site is one of the first actions new users will want to take?
While anecdotes are not evidence, the Twitter thread did dig up a couple of responses supporting its continued use, including:
https://twitter.com/gregory_boggs/status/1148394832890646528 "Don't remove color. In fact, double down on customized look and feel in core. It was the single most requested 'how to' when I ran global training days sessions."
https://twitter.com/nmdmatt/status/1148389119720120320 "If Drupal core had a useful default theme using it, keep it. WordPress has this. Shit, there's so many skinned Commerce Kickstart 2 default themes, maybe there would have been more if it used the color module"
https://twitter.com/VladimirAus/status/1148400465324826626 "I’m running 4+ Drupal global trainings annually covering wide range of users and can tell that color is absolutely must have in core. I’m also adding support for color to #bootstrap4 theme."
It absolutely makes sense that Umami doesn't support recoloring, because Umami is not a "starter" theme. It is intended to be a throwaway demo and that's it. OTOH, the default theme in core will naturally be the place where new users start learning about Drupal and its capabilities, how to customize it, etc. So that's a bit of an apples / oranges comparison, IMO.
Also, for historical reference, cross-linking #88202: New drupal-theme: Garland which was the issue where this module originally was added in. The theme was named Garland after Judy Garland, "the actress/singer/gay icon. The theme offers a rainbow of possibilities after all ;)." Ha! :D
Comment #41
ivnish CreditAttribution: ivnish commented+1 for contrib
Comment #42
saltednutIf moving this to contrib means it will actually get maintained, I am all for it. That said, there needs to be ways that core themes can still support this contrib. E.g. If I turn on the contrib color module, it should still work with Bartik or whatever. If thats not possible, then I think we're looking at a regression. Or you could delay this to Drupal 9 and say all new themes claro and otherwise, won't support it.
FWIW, in my dept (sales at Acquia) we use color module all the time. Its really helpful for clients to re-color the admin theme on a per-site basis, for example.
Comment #43
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commented#40:
The Umami team is considering #3054838: Remove umami theme from profile and add it to core/themes. If the Umami theme gradutes from the demo profile to a general purpose theme, it might benefit from adding colour support.
#42:
Back in #17, @JurriaanRoelofs offered to maintain color module in contrib. However that was 3 years ago, so I don't think we should hold them to that. A fresh call for maintainers would be a good idea.
Comment #44
andypostMakes sense to decide it while DrupalCon
Comment #45
geek-merlinI made a working POC of a IMHO for better modern replacement. Please consider this.
If needed, PM me and/or we can schedule a call.
Comment #46
ckrinaSo far I see 2 main points here, that can be totally decoupled from each other:
Those advocating for keeping Color in core are talking about the feature, most of the points against it are about the UI.
I think we can all agree on the need of the feature, but the way it's implemented right now have several pain points:
This is been one of the most demanded features for Claro. But, as a designer or on an accessibility point of view, I don't want to give the whole spectrum to choose from to someone without knowledge. In an ideal world, we should give a limited palette to choose from, with colors that plays well together. We should be able to limit the choices.
And actually having a different accent color in Design System is something really normal nowadays. Even to have a set for dark mode.
So, imho to keep Color in core it should be updated and have a new UI. Otherwise it should be moved outside core.
Comment #47
andypostWe used to invest some time into making palette managment easy and used to came to yml or "configurable" palettes in styleguide contrib module
As 9.0.x is already open better to file feature to introduce storage for pallete definition and how to map it to CSS variables and second one to deprecate and convert "color-pseudo-hooks" to something extensible from theme level
Comment #48
davidhernandezComment #49
rachel_norfolkretagging
Comment #50
anruetherTentatively postponing on #3090894: Replace color module with a CSS-Variables based module to provide configurable theme parameters. Maybe we get a better picture once we have a color successor. For which we now have a working, ie11 compatible proof of concept in the linked issue. cssvars module also plays nicely with config overriden e.g. by domain config module.
Comment #51
anruetherComment #52
jasonawantAdding related issue #3086514: Investigate use of the changing color themes for Olivero; Has this been brought up recently with the advancement of Olivero?
Comment #53
Gábor HojtsyUpdate related issues to Drupal 10.
Comment #54
Gábor HojtsyActually link the Drupal 9 side issue first.
Comment #55
xjmLet's reopen this. Olivero does not depend on the Color module, nor Farbtastic, and assuming Olivero becomes the default theme of Standard in time for 10.0, Bartik will be deprecated and removed from core.
Would we agree to simply deprecate Color if/when Bartik is deprecated? It will still land in contrib where someone could improve it, themes can depend on modules now, and Project Browser will make contrib discoverable in general.
Comment #56
xjmComment #57
joachim CreditAttribution: joachim at Factorial GmbH commentedIf Color module is unused, why is its functionality being reimplemented in a single theme: #3257274: Implement color changing theme settings for Olivero.
Comment #58
Gábor HojtsyI read up on the issue summary but did not have a chance to review all the comments. I am a core product manager and support removing color module as indeed no core theme will support it following the removal of Bartik.
@joachim: that color module was not flexible enough to provide that simple color picker for Olivero is a good indication it is not core-worthy. It has a better chance in contrib to amass new maintainers or be forgotten in favor of better solutions.
Comment #59
Neograph734@Gábor Hojtsy I agree that the color module is old fashioned and not at all flexible. However, the decision of having the default core theme implement some tailor made logic for this feels like a weird one. Core will not depend on a contrib module, so included in the Olivero settings will be the the logic to change colors. This paves the way for all other themes to implement this as they like. In that case there is nothing to do in contrib space because it can never be compatible with all themes.
I have no preference for a certain color picker, or if it is RGB, HSL, or whatever color format. But I do feel that some standardisation in the way themes handle configurable colors is a must if we even want to have a chance in contrib. Something like #788332: Provide a parser for THEME.colors.yml.
I also see a lot of overlap with what is being done in Olivero in #3090894: Replace color module with a CSS-Variables based module to provide configurable theme parameters, so we are not even that far apart with ideas.
Comment #60
joachim CreditAttribution: joachim at Factorial GmbH commented#59 is the point I was trying to make as well.
If Olivero needs a colour picker, it should either use Color module or improve Color module, not create a custom implementation.
Comment #61
Gábor Hojtsy@Neograph, @joachim: I don't think keeping color module hostage of this situation is a good idea. Olivero is not an interface / not supposed to be extended and could be one of the starterkit themes in Drupal 10 to clone and modify from. I think we can keep improving the customization functionality without the baggage of what is in color module right now. Innovation on this front IMHO would be better done in contrib. Even if that does not sound it gives immediate results, keeping color module in core (which requires backwards compatible features to be kept, etc.) will also not bring results anytime sooner.
Comment #62
lauriiiMy thinking of Olivero vs Color module is that Color module as it is isn't matching the expectations of frontend developers in 2022. It was written before CSS custom properties existed which makes it seem clunky to integrate with. I think there's potentially need for a module like this, which is proven by having some color module usage in our contrib ecosystem. However, this need could be still fulfilled by a contrib module since after removing Bartik it's not being used by core.
What comes to Olivero implementing Color module alternative is that from product perspective it doesn't seem ideal. But I also don't see a realistic path where we would make Color module work so that it would match the expectations of the Olivero team. I think the pragmatic choice would be then to accept the path that they are advocating, which is to implement a far simpler, bespoke solution in Olivero. That seems better than the likely alternative which would be no color customization at all in Olivero. I think that making incremental progress is better, as eventually it could pave a path for the larger changes needed in Color module.
tl;dr: I still support the idea after 5.5 years. 😇 Since Olivero is not planning to integrate with Color module, I don't think it should be in core.
Comment #63
joachim CreditAttribution: joachim at Factorial GmbH commented> I think the pragmatic choice would be then to accept the path that they are advocating, which is to implement a far simpler, bespoke solution in Olivero
Could they at least make something that's reusable? There are better ways to do this, surely. We could make a color2 module in core which is the Olivero code and deprecate color module. It would be a crappy module name but better than the proposed situation.
> I think that making incremental progress is better, as eventually it could pave a path for the larger changes needed in Color module.
It sounds to me like it's creating lots of technical debt, because Olivero will have to be rewritten to support a future general colour system, with BC concerns as well.
Comment #64
lauriiiI've not seen any significant progress on the next-gen color customization tool since I opened this issue (I'm sorry if there has been, it could also that I'm unaware of that happening). I believe that the situation where we would have to worry about migrating Olivero over to a next-gen color customization tool still seems like a net win over the status quo.
My thinking on this has been that what the Olivero team is building, could evolve into something that's reusable in future. I've been thinking of that so that the new tool in Olivero is a v2, and there could be a v3 which is inspired by that. Depending on how different v3 is from v2, there might not be upgrade path to v3 from v2, and you would always have to pick one of the color customization tools. It could be that Olivero continues to use the v2 indefinitely if it seems less work to maintain it compared to upgrading to v3.
Comment #65
Neograph734Could there be some middle ground here? Let's set aside the whole UI part of the color module, that can be rebooted in contrib. Also the inner workings of it (rewriting CSS files and such) are obsolete and can be replaced with custom CSS properties. This will need work. However for that to work we need to define some standards. Any next generation color module would need a central place to find the color properties and color schemes, which Olivero now has defined in JavaScript.
As proposed in #788332: Provide a parser for THEME.colors.yml, defining the editable CSS color properties and color schemes in YML files and having a color parser built into core, will at least allow a contrib solution to work with this in a universally applicable way. Olivero could also tune into this system whilst sticking to their current UI. Arguable the color injection system could maybe also exist in core? Olivero could also benefit from this.
There will be no code progress in this issue otherwise, because there is nothing to make any progress on. We need some place to find the available colors and inject them back into the page again. After this I'd be happy to team up and work on a contrib UI.
I fully support deprecating color, but I would really like to see a workable alternative.
Comment #66
xjmI think it's OK to review new APIs like Olivero's or #788332: Provide a parser for THEME.colors.yml separately from deprecating Color.
Comment #67
ckrina+1 on removing Color from core. None of the new core themes are going to use it.
I agree, though, with several of you about the need of a reusable feature to customize a theme color/palette. But finding the best implementation for it is a discussion that can happen independently from removing Color from core and not block the deprecation of an old and unused (from D10) module.
Comment #68
Neograph734Thanks all. I think my main concern was that there would also be no need for such API once color moved out of core. But with the provided replies I feel that we can turn this into something functional.
@joachim would this work for you as well?
Where could we continue the discussion about the APIs? This issue has quite some linked related issues, but I expect you want to close this one?
Comment #69
xjmThis decision already has the needed signoffs from product, release, and frontend framework managers, so as such I'm marking this RTBC for the policy aspect.
Core provides many APIs that its UIs do not expose, so that would not be a blocker for providing color-related theme APIs in core if we decide in the future that is worth doing. The open related issues can continue even once this one is closed. Thanks!
Comment #70
xjmOh, a side note for those interested in Color's future -- you could volunteer to become maintainers of Color when it is moved to contrib if you would like to see it continue to exist and be improved. :)
Comment #71
andypostAs contrib color module created I still sure it's easy to deprecate it and iterate faster in contrib
Comment #72
Gábor HojtsyAll of the in the works core modules and new core modules added in recent years: Project browser, Automatic updates, Olivero, Claro, CKEditor 5, Media, Layout Builder all started as contributed modules. A Color2 module or some other name could also start in contrib and if it looks good and is sensible for core inclusion it could be included in core. Working in a contributed module allowed all of these new projects to iterate faster instead of the type of arguing we are doing here.
Comment #73
quietone CreditAttribution: quietone at PreviousNext commentedThis work has been completed in core.
Thanks!