Is There a Way to Allow Special Characters in Class Names?

I would like to use a special character in some of my class names – such as the at symbol (@).However, whenever I try to use it, it automatically gets erased by Webflow.

Is there a way to override this behavior and allow me to use the symbol in my class names?

The only way is to use custom code for the elements, so you can type whatever class name you want.

BTW do note that the @ symbol is invalid Which characters are valid in CSS class names/selectors? - Stack Overflow

Thanks.

I know it’s invalid. But if you escape it I believe it still works.

I once came across the idea of using special characters in helpful ways – for instance: red@tablet, blue@mobile etc., as a means of giving different styles at different breakpoints.

I was hoping to do something similar with Webflow. It’s not crucial – I just think it is easy to read and does not take up a lot of space.

Either way, thanks again for your answer.

What is the benefit of using specific classes to define breakpoint styling? Shouldn’t media queries be doing this for you without the need for additional classes?

Just create a class and style it as desired for desktop sizes (default view), then when it’s time to work on smaller screens just adjust the styling as needed without adjusting the class. The icon next to your class name will signify which break point your style is applying towards, so I would think this would be a bit redundant.

Unless I’m missing some extra functionality (which is very possible, I’ve only just started drinking my morning coffee) you shouldn’t need to make things more complicated.

I’m creating some helper classes that I can quickly use for styling purposes (I find it helpful for quick prototyping). So, for instance – I have some heading classes:

.h1
.h2
.h3
etc.

So, for instance, let’s say I want to have an h1 tag, but at a smaller size. I can just add one of these classes and I’m done.

At the same time, I have created device variations for these tags:

.h3--tb  // Tablet
.h3--ls  // Landscape
.h3--pt  // Portrait

So, if I want the header to be smaller at landscape and smaller – just add a h3--ls class in Webflow.

Personally speaking, though, I prefer the idea of using the @ symbol – i.e., h3@ls

But it’s not a big deal – h3--ls works just fine.

Thanks for the explanation, but I’m still a bit confused as to why you’re using break point terminology (tablet, portrait, landscape) instead of more human-readable naming (xs, sm, lg)? If it’s common to you that’s great, but what if another developer comes along? Will they know what tb, ls, and pt mean?

I think you’ll find that the double dash (--) for modifiers will be a better route in the long run, as it follows the same idea behind BEM naming convention and, as @samliew pointed out, the @ symbol is something that may want to be avoided to prevent browser conflicts.

Obviously you can use whatever method that works best for you, but I just figured I’d throw my two cents.

I got Tablet, Landscape and Portrait naming from Webflow: Loom | Free Screen & Video Recording Software | Loom

I haven’t decided if at the end of the day I want to use the abbreviated form tb or to write it out in full Tablet

I do like the double dash (and got it from BEM). I just wanted to use a different separating symbol for these classes because they aren’t really elements or modifiers (in my mind at least).

In terms of valid naming – here is what the w3c spec states (note the part in bold):

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+00A0 and higher, plus the hyphen (-) and the underscore (_); they cannot start with a digit, two hyphens, 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”.

I understand where the naming comes from but like I mentioned previously, Webflow creates these different class styles (that are active whenever you edit a class within each ‘view’) with media queries - so adding a separate class is only necessary when you’d like to override a class within any given canvas size.

Let’s say you have a link class, and you give it a text size of 20px within the desktop view. When you move to the tablet view, your link class can now be changed to 16px and not affect the 20px size given on the desktop view. This means you no longer need the link@tablet class. The main problem I see with these extra modifiers is that this causes problems when you’d like to make changes to your link class and have those changes cascade down to your other breakpoints.

You’ll notice that next to each class there is an icon that signifies which media query you’re editing, and unless you’re needing to assign two different style treatments to the same class within any given view, you shouldn’t need any modifier classes. I’d recommend that within Webflow you think of this as a pseudo-modifier that will let you know which class you’re editing.

In regards to choosing a separator for your class names, if you feel comfortable using @ and there are no conflicts then go for it, but most developers will probably tell you that it’s best to find another character if possible.

For me, these classes are best for rapid prototyping. Change the view, slap on the relevant class and voila – you have a different spacing, font-size, color, etc. If I don’t like what I see, then I can just quickly change the class and update the look.

Then, when I have the look that I want, I can create the actual class I want to use and give it the relevant styles using the built-in Webflow system.

In terms of the symbol, if I were hand coding the css then I would definitely recommend NOT to use the @ symbol because of the increased chance of making a coding mistake by leaving out the backspace.

If, however, I’m using a system like Webflow that (theoretically) can take care of the backspaces for me, then I think it’s less of a big deal (unless one plans on exporting the code and using that code outside of Webflow). With that said, Webflow doesn’t allow it, so double-dashes it is :slight_smile:

Be well,

Moshe