Make class names more consistent/closer to CSS

[missmatsuko]

Along the lines of #19, I am finding a lot of the class names unintuitive and inconsistent.

I really think the class names should favour clarity and ease-of-use over brevity, and lean on what developers should know about CSS.

Developers should know the property and value they want to apply to an element and it should be less effort for them to write class names of the property and value they want than to think about how its associated utility class name is formatted.

My suggestion is to use the format .[property name]-[property value] for all CSS utilities that only modify the value of one property. e.g. .margin-0 instead of .m-0, .align-items-stretch instead of .items-stretch, .text-transform-none instead of .normal-case, .max-width instead of .container.

Examples of some inconsistencies

• Some class names come from the property:
  • .pointer-events for pointer-events
  • .appearance for appearance
  • .resize for resize
• Some class names come from the attribute's value:
  • .block for display: block;
  • .flex for display: flex;
  • .visible for visibility: visible
• Some class names come from some combination of property and value, with something omitted:
  • .items-stretch for align-items: stretch
  • .flex-row for flex-direction: row
  • .table-auto for table-layout: auto
• Some class names use terminology that isn't used in CSS:
  • .invisible for visibility: hidden
  • .tracking for letter-spacing
  • .normal-case for text-transform: none;
• Some class names mix up terminology that is used in CSS:
  • .justify for justify-content, not text-align: justify
  • .text for font-size, not text-transform
  • .align for vertical-align , not align-items
• Some class names use abbreviations:
  • .m for margin
  • .z for z-index
  • .p for padding

Additionally, I think there are some class names that could reasonably be used for components or layout utilities. This would be mitigated if utility classes were named after their respective CSS property and value.

• .block could be a boxy layout element
• .content could be a content-containing element
• .select could be a select input
• .scrolling could be a state class to use with JS

This would also better distinguish single-property utility classes from complex utility classes such as:

• .clearfix
• .list-reset
• .truncate

Andd I'm not sure if it's already a functionality that exists, but maybe developers can shorten the base class names according to their own preferences. I think it would be best to mimick CSS by default, though.

Related Issues:

#413 .font-normal .font-regular .roman .font-not-italic
#577 .hidden .visible
#102 and #523 Customizable class names

• Future-proofing .content and .contents

[mumairofficial]

Concise class names looks fine; at least less typing in element attribute and already mind mapped i.e. m for margin and at the end class="..." will not flooded :)

[zaknesler]

I think consistency here is rather subjective, and I personally prefer descriptive and more identifiable class names rather than those that may more accurately represent the classes they apply.

[missmatsuko]

@zaknesler Can you clarify - do you mean the "styles they apply" rather than "classes they apply"?

Which specific class names would you say are "descriptive and identifiable", and why?

[zaknesler]

@missmatsuko I apologize, by "classes they apply" I meant "styles they apply," and I am simply referring to how .m-px is applies margin: 1px or how .items-center applies align-items: center.

Sure .align-items-center is more intuitive than .items-center, but once you learn the utilities, any inconsistencies become invisible. I think you will definitely see this in any utility framework. Hell, look at the god-awful class names of Atomic CSS, yet I guarantee that whoever uses them are lightning fast in their workflow.

As @mumairofficial mentioned, there exists a trade-off between highly intuitive class names and how much room they will take up in your markup. It's must better to be concise (and arguably still very identifiable) than to clumsily stick to using incredibly descriptive class names, because I think it's just unnecessary, and I think the conciseness and clearness of the utilities is my favorite part of Tailwind.

[missmatsuko]

That's why I'm thinking it might be nice to be able to customize the base class names for developers who want it to be super short like .m- for speed. Even the existing class names are going to take up a lot of markup anyways - I don't think that is a good reason to have inconsistent class names.

And I'm not sure, but maybe a tool like Emmet can be used to expand classes starting with .m- into .margin- to help with typing speed while not messing with the library's class names if it does get changed to be more CSS-like.

Seems like there is an issue with open PR for this feature: #523
Also an related closed issue: #102

[missmatsuko]

Another issue I thought about the other day is that the current class names aren't future-proof. For example, what about adding utility classes for some of the newer display values like display: grid and display: contents. Following the naming of the other display classes, the class names would be based on the values, so .grid and .contents. I think .grid and .contents are classes that could reasonable used for layout elements, and additionally .contents is so close to the existing .content class (which sets some max-widths) that I could see it easily causing confusion and mistakes. If we match class naming to the CSS specs, such naming collisions and similarities would be very unlikely.

Edit: Just noticed yet another inconsistency! The class that applies the style display: none is not named after the value as with the other display utility classes, but is .hidden instead. So .visible applies visibility: visible, but .hidden doesn't apply visibility: hidden.

[missmatsuko]

Looking at a class name like .invisible... as someone who is familiar with CSS and knows that "invisible" is not a standard CSS property or value, I wouldn't know from the name what style it's going to apply.

It could be (and is) visibility: hidden, but it could also be a number of other styles that hide an element. display: none, opacity: 0, positioning off-screen, or even a common screenreader-only style like this:

position:absolute;
left:-10000px;
top:auto;
width:1px;
height:1px;
overflow:hidden;

In fact, I would probably think it's probably some kind of screenreader-only style since there's utility classes like .clearfix which is not named after CSS properties or values and applies a common float-clearing style.

If the class were named .visibility-hidden, I would be pretty certain the style it's going to apply is visibility: hidden

[wmcmurray]

Why don't you just use normal CSS ? Wouldn't that prevent all the confusion ?

[Alonski]

Want to chime in here
@missmatsuko I think that some of the points that you bring up could be considered valid.
For example maybe instead of .hidden that name should be .dis-none or something.

The thing with making class names longer is that it could make markup much larger
Compare this with the current implementation:
<div class="min-h-88 pl-12 flex-row-reverse py-12 flex flex-1 justify-between" />
With this:
<div class="minimum-height-88 padding-left-12 padding-vertical-12 flex flex-direction-row-reverse flex-grow-1 justify-content-between" />

My Markup is already quite wide :)

[missmatsuko]

Yeah to me I think the markup is already going to be long anyways, so I don't really mind if it's longer, especially if it's more understandable.

…

On Sun., Feb. 3, 2019, 2:09 a.m. Alon Bukai ***@***.*** wrote: Want to chime in here @missmatsuko <https://github.com/missmatsuko> I think that some of the points that you bring up could be considered valid. For example maybe instead of .hidden that name should be .dis-none or something. The thing with making class names longer is that it could make markup much larger Compare this with the current implementation: <div class="min-h-88 pl-12 flex-row-reverse py-12 flex flex-1 justify-between" /> With this: <div class="minimum-height-88 padding-left-12 padding-vertical-12 flex flex-direction-row-reverse flex-grow-1 justify-content-between" /> My Markup is already quite wide :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#575 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARDkJhBnSoY0GWSi63nRYtCSNVc_47Klks5vJrVmgaJpZM4XdYcd> .

[aparajita]

@adamwathan explained why he didn't use a 1:1 mapping between class names and CSS attributes here:

#19 (comment)

There's no way to please everyone unless all of the class names are configurable.

[adamwathan]

Been meaning to add a thoughtful reply here for too long now, sorry.

@missmatsuko you make really good points and I really appreciate the thorough critique of the existing class names 👍

The thought process behind the current naming tried to optimize for a lot of different things, and often times one thing had to give because something else felt more important.

Brevity was definitely an important element, especially for things that are used a lot like margin and padding classes. One of the things I want Tailwind to be good for is designing in the browser. It's really nice when you have your editor open on one side of the screen, browser live reloading on the other side of the screen, and you can rapidly iterate on a design and see your changes quickly because a lot of the classes are short enough to almost feel more like keyboard shortcuts than like strings you are typing.

Every naming decision was basically a battle between brevity and opportunity for ambiguity. All of the background related classes are potentially ambiguous for example, they all just have a bg- prefix regardless of if it's a size class, a color class, a position class, an attachment class, etc. But I figured the odds of someone having a color named contain was low enough that I'd rather be able to type bg-contain instead of bg-size-contain.

If we didn't want to optimize for brevity at all, you're right it would be much easier and simpler to just mirror the CSS properties, and you can definitely make a strong case for doing that. Me personally, I actually wish some of the existing class names were shorter (having used them for a few years now and learning them) because I'd like to be able to design in the browser even faster, and read the list of classes on an element faster too.

The problem with going any more terse than we have currently is you scare away new users I think, because things can look really cryptic, so I've tried to be careful to find the right balance.

But all that said, brevity is a really important factor for me personally as a user of the framework, so there will always be trade-offs and tough design decisions to be made as a result.

I have changed my mind a bit from the opinion I shared originally here on a similar topic, and now I think trying to create too many small abstractions on top of CSS isn't a great idea (at least in terms of utilities that do multiple things, like truncate and clearfix), and revisiting some of those decisions is definitely something I'm going to be doing before tagging 1.0 in the coming weeks.

We may even make class names configurable one day (although I would discourage it in order to make Tailwind knowledge more transferrable from project to project), but for now you can always disable the core plugins and use Tailwind more like an engine for generating your own framework, by providing simple plugins for the utilities you'd like to use a different name for.

Thanks again for the detailed issue, and hope this explains some of the decisions 👍

[4refael]

I pretty like the current class names. I also appreciate consistency when possible but I don't think it's reasonable in this case, it will result in very very long class names. For comparison:

<div class="flex mr-auto mt-auto bg-black"></div>

OR

<div class="display-flex margin-right-auto margin-top-auto background-color-black"></div>

I definitely wouldn't want to write the latter.

[missmatsuko]

I kind of get shortening class prefixes to one letter when there could be multiple on a single element (e.g. margin, padding). But why would `z-index` need to be shortened to `z`? It's not that long and there should never be more than one on an element. Maybe having the full names is not necessary, but more consistency between the naming would help a lot. Maybe the first X letters of an attribute + its value instead of the mix of different variations there is now.

…

On Tue, Feb 5, 2019 at 2:11 AM Refael Iliaguyev ***@***.***> wrote: I pretty like the current class names. I also appreciate consistency when possible but I don't think it's reasonable in this case, it will result in very very long class names. For comparison: <div class="flex mr-auto mt-auto bg-black"></div> OR <div class="display-flex margin-right-auto margin-top-auto background--color-black"></div> I definitely wouldn't want to write the latter. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#575 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARDkJj8dDAthWi45OdP0jw0I0W0-KhCkks5vKVjCgaJpZM4XdYcd> .

[adamwathan]

Don't have any other thoughts on this really now other than what I shared here:

#575 (comment)

...and no intentions to drastically change our approach to naming things (although some class names may still change, just not because of being too short/ambiguous), so going to close this in an effort to clean up our issues a bit.

Thanks again for the thoughtful comments and conversation 👍