[RFC] The state of material colors about materialize

[doughballs]

100% agree. It would need some refactoring, but to have a colours component, that can be included/excluded at will, would be a big step forward.

Two theme colours, and 3-4 utility colours (success, error, disabled), would suffice for the people who use SASS I think. People using cdn can still take advantage of the whole array of needed.

[drusepth]

I think as long as there's still a way to import all the colors, this would probably be a net good for people just starting out in the library. Notebook.ai uses almost every single shade of every color throughout the design so I wouldn't want to be limited to N colors without a way to get them all back, but I recognize that's probably an exception to most designs and would be happy to just include something like @materializecss/colors.

[LoganTann]

I personally don't agree at first, but your arguments are fully valid for large projects.

So okay, making a separate package is a good idea, but I think we should make materialize like bootstrap :

• The full package in a single minified js and css
• Optional packages for download where you just choose what you need (materialize/colors materialize/grid...)

Also, may implement this will break components that depends on these colors ?
Anyway, that's an issue we have to consider for v2

[DanielRuf]

@materializecss/members

[nh916]

I personally love all the colors in materialize. I have found that the specific shades of colors in materialize are so much more vibrant than other frameworks. I would hate to see them all go away without a way of getting them back. However, I think it would probably be a good idea to have them as a separate package that if the developer needs all the colors they can import them all, import just the dark shades, or just define their own color pallet and use that only