Materialize: Improve the naming scheme for classes

[alexisdiel]

Following a naming scheme for classes can make it easier and faster to understand and develop. I have identified a divergence in the names of vertical and horizontal alignment classes.

center-align
valign-middle

I suggest, when possible, to use the property-value logic.

align-center
valign-middle

[bert-w]

grey
grey-text

darken-2
text-darken-2

i keep switching these around too

[DanielRuf]

Imo it makes sense to add the property (text for foreground or none for background) first, then the effect / color and then the value of it.

grey
text-darken-2
darken-2

Switching colors and effect values (lighten, darken, color names) should be easier with this structure. From big to small. Like it is in the (v)align helper.

It's just an idea. How would your proposed solution look like @bert-w?

[bert-w]

@DanielRuf either that or grey-text i.c.w. darken-2-text (as long as the word "text" is on the same side).

I have no preference, code completion doesnt matter for me in this case since phpstorm picks them both up

[alexisdiel]

Exactly @DanielRuf, the _text-darken-2_ is an awesome example.
From big to small.
component > attribute > value > variation

[StephenMP]

I didn't feel it proper to create a whole new issue for this, when there is already a topic discussing improvement of the naming conventions.

Anyhow, has the Materialize team ever considered switching to the BEM naming convention?

Currently, Materialize works fine on it's own when you don't introduce a whole lot of other CSS/JS libs into the playing field. This, however, changes when you begin using libs which may contain similar class names.

Also, when examining documentation or examples, it can be extremely difficult to determine what is a necessary/required class for the Materialize framework, and what was put there as an 'added class' for secondary styling by the user.

Thus, an idea to consider while the framework is young enough, is to possibly switch to using the BEM naming convention.

Now, this is obviously a HUGE change and would definitely be something to do in a major release down the road. It would include an overhaul of the framework to follow BEM standards, an overhaul of the documentation, and the writing of an upgrade guide.

The benefits, however, are massive as the Materialize components would then be unique to the framework itself and allow for easy extensibility from third parties. It would also be easier to learn Materilize which could add to the adoption rate.

Personally, I chose MDL over Materialize back before MDL went EOL simply because the BEM made it SOOOO much easier to pick up and start building web pages with. And honestly, if MDC didn't look like garbage (Materialize is very pretty :smile:), I would have likely used it because of how easy BEM makes it.

[Dogfalo]

We do want to improve on this; possibly renaming some of the more ambiguous classes into something more materialize specific, but it's still a bit out there on the timeline. Thanks for giving feedback.

[StephenMP]

Yea, I think even doing something as simple as using a prefix would add a ton of benefit (e.g. all materialize classes start with mz- or something. mz-card, mz-button-flat, etc.). This would also be much easier to implement and updating the documentation would be simple. Then, all you need for an upgrade guide is:

Upgrade Guide: Add mz- before all your materialize classes

:smile:

[djensen47]

Using a prefix for all of the classes provided by Materialize is essential. I stopped using Materialize and retooled my entire app for this reason alone. Even in my own css, I use a prefix. As more projects start using BEM, I think you'll find more people will appreciate it when your project uses it. Cheers!