Class names ideas

[notenociz]

Class names ideas

[notenociz]

I'll start off I guess.

How about using the same kind of names as Emmet uses. It is a common plugin used by people who use more visual editors such as Sublime Text and has the occasional user on command-based editors like VIM (Vi Improved). Thus, it would make sense to have it.

Here is the cheat sheet which will be useful when deciding.

[notenociz]

And, this is a pretty good round up of naming conventions.

[mrzmyr]

tl;dr: I like the 'css-property-to-class'-API, but it should be more consistent and separated from the components.

As I came across projects from @mrmrs, I liked them for their clearness and the fact that they are principle driven. So did I with Tachyons. What made me hesitating using Tachyons were also the naming conventions and the system they are built upon.

Low level API

On the one hand there is this low-level, lets call it API, which provides a way of assigning css properties by css classes. (e.g. .pos-abs for position: aboslute).

The naming behind it makes totally sense to me and is easy to adopt. For example, if i know .pos-abs and can pretty much guess what class I can use for position: relative.

But, what breaks my head is the inconsistency.
Example: .ttc is text-transform: capitalize; where .underline just uses its value instead of the property name. I'd rather expect something like .td-u.

@enociz, I like the idea of looking into the emmet conventions for consistency. (Could be easy parsed 😁)

Components ?

On the other hand there are some kind of low level components (e.g. in _type-scale.css), a bit more high level components (_typography.css or _forms.css) that are not separated from the 'css-property-to-class'-API.

May we should checkout an idea like ITCSS (by Harry Roberts) to make the difference and separation more clear.

[notenociz]

Good thoughts.

@csswizardy also recently did an article but I personally feel that it is a bit complicated and doesn't apply well to the Tachyons framework.

[mrzmyr]

csswizardy maintains / consults companies with huge / complex css bases and more in a corporate field, if I got his job right. We are talking in the scope of a framework here, which is slightly different I guess.

[notenociz]

Agreed, however, it is still a class naming methodology and so is valuable (even if used for a reference to bigger architectures) in this discussion.

[mrzmyr]

Ture. So, what are your thoughts on the components ?

[mrmrs]

I also consult companies and deal in massive css codebases. That is not the reason for differences. Just different priorities and philosophies.

Sent from my iPhone

On Aug 8, 2015, at 7:20 PM, Moritz [email protected] wrote:

Csswizardy maintains / consults companies with huge / complex css bases and more in a corporate field, if I got his job right. We are talking in the scope of a framework here, which is slightly different I guess.

—
Reply to this email directly or view it on GitHub.

[notenociz]

@mrmrs — I agree with that but forgot to mention it.

@mrzmyr — what exactly did you mean by your components things. I didn't exactly understand. Could you perhaps explain with an example?

[mrzmyr]

@enociz – The difference of the 'property to css class' declaration and the components I described above.

@mrmrs – Totally agree, I meant the priorities there. What are your thoughts about sorting out the difference between components and 'property to css class' declaration?

[mrmrs]

Inconsistencies in naming patterns are in most cases a result of observing what is easiest for people to grok. Don't really understand your definition of components @mrzmyr - to me components in this architecture are composed of a number of classes and not represented by the css in anyway.

[notenociz]

@mrmrs — Agreed