How to Use Camelcase in CSS Class Names

Can I use camelCase in CSS class names

Technically yes, but it's risky because while CSS syntax is mostly case-insensitive, in some browsers under certain conditions, class names are treated as case-sensitive, as the spec does not specify how browsers should handle case when matching CSS rules to HTML class names.

From the spec, section 4.1.3:

All CSS syntax is case-insensitive within the ASCII range...

In CSS, identifiers (including element names, classes, and IDs in selectors) can contain only the characters [a-zA-Z0-9] and ISO 10646 characters U+00A1 and higher, plus the hyphen (-) and the underscore (_); they cannot start with a digit, or a hyphen followed by a digit. Identifiers can also contain escaped characters and any ISO 10646 character as a numeric code (see next item). For instance, the identifier "B&W?" may be written as "B\&W\?" or "B\26 W\3F".

...the case-sensitivity of values of the HTML attributes "id" and "class", of font names, and of URIs lies outside the scope of this specification.

Rather than learn the browsers and conditions where case is sensitive, it's best that you just realize that the best approach is the most compatible: use the same case in all code for a given CSS class, and don't create two or more CSS class names that differ only in case.

Is using camelCase in CSS ids or classes ok or not?

Technically, no, there are no technical issues. Do what you like.

Do try to follow a good style-guide though, like this one.

Which casing should I use for CSS classes when using CSS-in-JS?

In React first one always works in case of modules, so you do not need to worry about it. So, going with the below convention works fine.

React:

import style from './style.module.css'
//...
<Button className={style.myButton} />

CSS

.myButton {
background-color: blue;
}

Refer to this Medium link for more insight:
CSS in JS

React className naming convention

TLDR: PascalCase and Block__Element--Modifier

Check out the official doc of create-react-app. It provides a minimum example of creating a custom component. The js and css filenames as well as the className are all following PascalCase.

// Button.css
.Button {
padding: 20px;
}

// Button.js
import React, { Component } from 'react';
import './Button.css'; // Tell Webpack that Button.js uses these styles

class Button extends Component {
render() {
// You can use them as regular CSS styles
return <div className="Button" />;
}
}

Besides, the doc also provides an external link, which describes BEM naming conventions (link) for elements inside the component.

// MyComponent.js
require('./MyComponent.less');
import { Component } from 'react';
export default class MyComponent extends Component {
render() {
return (
<div className="MyComponent">
<div className="MyComponent__Icon">Icon</div>
...
</div>
);
}
}

// MyComponent.less
.MyComponent__Icon {
background-image: url('icon.svg');
background-position: 0 50%;
background-size: fit;
height: 50px;
}

What is the standard naming convention for html/css ids and classes?

There isn't one.

I use underscores all the time, due to hyphens messing up the syntax highlighting of my text editor (Gedit), but that's personal preference.

I've seen all these conventions used all over the place. Use the one that you think is best - the one that looks nicest/easiest to read for you, as well as easiest to type because you'll be using it a lot. For example, if you've got your underscore key on the underside of the keyboard (unlikely, but entirely possible), then stick to hyphens. Just go with what is best for yourself. Additionally, all 3 of these conventions are easily readable. If you're working in a team, remember to keep with the team-specified convention (if any).

Update 2012

I've changed how I program over time. I now use camel case (thisIsASelector) instead of hyphens now; I find the latter rather ugly. Use whatever you prefer, which may easily change over time.

Update 2013

It looks like I like to mix things up yearly... After switching to Sublime Text and using Bootstrap for a while, I've gone back to dashes. To me now they look a lot cleaner than un_der_scores or camelCase. My original point still stands though: there isn't a standard.

Update 2015

An interesting corner case with conventions here is Rust. I really like the language, but the compiler will warn you if you define stuff using anything other than underscore_case. You can turn the warning off, but it's interesting the compiler strongly suggests a convention by default. I imagine in larger projects it leads to cleaner code which is no bad thing.

Update 2016 (you asked for it)

I've adopted the BEM standard for my projects going forward. The class names end up being quite verbose, but I think it gives good structure and reusability to the classes and CSS that goes with them. I suppose BEM is actually a standard (so my no becomes a yes perhaps) but it's still up to you what you decide to use in a project. Most importantly: be consistent with what you choose.

Update 2019 (you asked for it)

After writing no CSS for quite a while, I started working at a place that uses OOCSS in one of their products. I personally find it pretty unpleasant to litter classes everywhere, but not having to jump between HTML and CSS all the time feels quite productive.

I'm still settled on BEM, though. It's verbose, but the namespacing makes working with it in React components very natural. It's also great for selecting specific elements when browser testing.

OOCSS and BEM are just some of the CSS standards out there. Pick one that works for you - they're all full of compromises because CSS just isn't that good.

Update 2020

A boring update this year. I'm still using BEM. My position hasn't really changed from the 2019 update for the reasons listed above. Use what works for you that scales with your team size and hides as much or as little of CSS' poor featureset as you like.

Why hyphen (-) separated class names are widely used in CSS

Readability:

ui-helper-reset readable,

uiHelperReset unreadable.

Safe delimiter:

When using attribute selectors like [class^="icon-"], [class*=" icon-"] to specifically and safely target the specific classname styles by prefix, while preventing i.e: .iconography to be matched.

Ease of use:

In every decent code editor, if you use - to separate combined-class-name you can easily highlight a desired portion by double-clicking it like: col-md-3, and replace it (or even document globally) to col-sm-3. On the other hand, if you use underscore _ like class_name_here, if you double-click it you'll end up highlighting the whole class-name like: class_name_here. Such will force you to manually drag-select the desired portion instead.

CSS Naming Convention Methodology

You can adopt a CSS naming concept like:

  • SUIT CSS
  • BEM (Block, Element, Modifier),
  • OOCSS (Object-Oriented CSS)
  • SMACSS (Scalable and Modular Architecture for CSS)
  • Atomic CSS
  • Your Own Concept CSS :)

They all help a team speak "the same language", by adopting a stricter "Naming things" such as:

SUIT CSS

/* Block */
.Chat{}

/* -element (child) */
.Chat-message{}

/* --modifier */
.Chat-message--me{} /* Style my messages differently from other messages */

/* .is-state */
.Chat.is-active{} /* Multiple chats - active state handled by JS */

or

BEM:

/* block */
.chat{}

/* __element (child) */
.chat__message{}

/* --modifier */
.chat__message--me{} /* Style my messages differently from other messages */
.chat--js-active{} /* Multiple chats - active state handled by JS */

If your .chat is part of the page you're viewing, you could use general Block classes like .btn and Modifier .btn--big like <a class="btn btn--big">Post</a>, otherwise if your buttons need a stricter styling specific to your chat application than you'd use .chat__btn and .chat__btn--big classes. Such classnames can also be preprocessed.

SCSS

I.e: by using Sass SCSS, a superset of CSS3 sintax you can do stuff like:

(Example using SUIT CSS)

.Chat {
font: 14px/1.4 sans-serif;
position: relative;
overflow-y: scroll;
width: 300px;
height: 360px;

&-message { // refers to .Chat-message
padding: 16px;
background: #eee;

&--me { // refers to .Chat-message--me
background: #eef; // Style my messages differently from other messages */
text-align: right;
}
}

&.is-active { // refers to .Chat.is-active (JS)
outline: 3px solid lightblue;
}
}

HTML:

<div class="Chat is-active">
<div class="Chat-message">Hi lt;/div>
<div class="Chat-message Chat-message--me">Ciao!<br>How are you? lt;/div>
<div class="Chat-message">Fine thx! Up for a ☕?</div>
</div>

jsFiddle example


Conclusion:

Adopting a stricter naming format among a team is important. Prevents and minimizes dead legacy classes bloating your HTML, helps code re-usability, readability and speeds up your workflow. Additionally, it forces you and your team to think in a much more modular way about your HTML structure - as components or atoms.

Whatever you decide to use is up to you - just, be consistent.

Are class names in CSS selectors case sensitive?

CSS selectors are generally case-insensitive; this includes class and ID selectors.

But HTML class names are case-sensitive (see the attribute definition), and that's causing a mismatch in your second example. This has not changed in HTML5.1

This is because the case-sensitivity of selectors is dependent on what the document language says:

All Selectors syntax is case-insensitive within the ASCII range (i.e. [a-z] and [A-Z] are equivalent), except for parts that are not under the control of Selectors. The case sensitivity of document language element names, attribute names, and attribute values in selectors depends on the document language.

So, given an HTML element with a Selfcatering class but without a SelfCatering class, the selectors .Selfcatering and [class~="Selfcatering"] will match it, while the selectors .SelfCatering and [class~="SelfCatering"] would not.2

If the document type defined class names as case-insensitive, then you would have a match regardless.


1 In quirks mode for all browsers, classes and IDs are case-insensitive. This means case-mismatching selectors will always match. This behavior is consistent across all browsers for legacy reasons, and is mentioned in this article.

2 For what it's worth, Selectors level 4 contains a proposed syntax for forcing a case-insensitive search on attribute values using [class~="Selfcatering" i] or [class~="SelfCatering" i]. Both selectors will match an HTML or XHTML element with either a Selfcatering class or a SelfCatering class (or, of course, both). However there is no such syntax for class or ID selectors (yet?), presumably because they carry different semantics from regular attribute selectors (which have no semantics associated with them), or because it's difficult to come up with a usable syntax.

How to configure WebStorm to recognise kebab-case class names when using CSS Modules with SASS

there is no way to configure this in Webstorm; please vote for WEB-28203 to be notified on any progress with this feature



Related Topics



Leave a reply



Submit