Streaming live at 10am (PST)

Non-CMS Love - Other Wishlist Items

Continuing the discussion from Classes not registering:

I’ve noticed this too.

I disagree with @Arthur in that “its a little thing”.

For Webflow to cater to those coming from HTML/CSS coding, or agencies wanting reusability, it really needs to iterate its style support and what “global” objects mean and how they interact with other sites under your account.

The fact that Webflow creates “compound” classes, in which you can’t explicitly modify a “parent” of a compound class while on the compounded element, is a big bummer. You end up having a “style guide” with a ton of orphaned (or temporary) div’s with your specific styling on it, and then chaining these individual classes in order to be able to reuse common things.

Although I appreciate the fact that the community has been asking for an integrated CMS, and I’m happy to see that Webflow has listened (but a bit concerned that everyone is ecstatic and drooling over just a cool animated video), I truly hope that there has been engineering effort put forth towards other (what I consider) fundamental items that the community have been asking for:

  • Number 1 for me: variables (at least) for use in classes. Eg: being able to define variables that contain styling in themselves, and apply those variables to multiple Webflow classes (similar to SASS and Less.) To “workaround” this, one has to create standalone/random/orphaned divs (see above), in order to properly cascade styles. If there were variables, and you wanted to change the definition of “primary-color”, you could do it in one spot.

  • Having the ability to copy “Global Objects” to other sites. The big argument here was always “well, it may override classes on the destination site”, and to that I say “so what, it’s an advanced feature, learn how to manage your workflow properly or don’t use it”. Imagine having a “master” site that has all of your symbols, classes, etc. that you can copy and paste freely to other sites (yes, I know a “workaround” is to keep duplicating your “master” site, but that’s at best pretty lame, and at worst a ton more upkeep.)

  • Proper asset management. I mean, we still can’t delete or rename assets? At least there is a cool After Effects video hyping up the CMS, though.

Now, I’m a big fan of Webflow, and have faith in their ability to eventually deliver, but I really hope that some of the 20-person staff have been tasked with some of these basic/core features that have been requested for just as long as the CMS features.

I’m looking forward to the CMS beta so I can see if Webflow has addressed these items – not because of the pretty video.


@dkenzik To address your point about “compound” classes (we call them Combo Classes internally), you should definitely be able to change the parent (non-combo) class even with an element that has the combo class on it. Here’s a screengrab of internal code that will be in production next week (going through heavy testing now, but similar functionality is available on the live Webflow now), but you can see me changing the more broad “Button” class while I have the “Button + Primary” button selected:

(Notice that when I select the “Button” selector while my Primary Button is selected, the background color is crossed out with a red line - indicating that even though I can make changes while I’m in “Button” mode, those changes have more specific definitions in “Button + Primary” so they will be overwritten, if that makes sense.)

Points #1 and #2 are really important to us, we’re already laying the technical groundwork for them, and they will happen!

Deleting assets is already implemented and going through the last round of testing as we speak :smile:


@callmevlad - Thanks for the GIF explanation. That’s helpful and definitely is useful (and I use it) after my elements are styled via dummy elements + standalone classes.

My biggest point about the Combo Classes is that there is no easy way to create the second class (“Primary” in your example) as a standalone class without creating a dummy/temp element. In your example, you can not use “Primary” as-is on anything but a “Button”. If you use it elsewhere, it will have a totally different context, and be treated as a new Webflow class.

My real-world example, which I’m sure you know but I’ll post it here for others: if I’m working on a Button (or any element) that I want to add a “Warning” class to – let’s say it will override “Button”'s background color to be red, and font color to be yellow and have that “Warning” class available to any other element, I currently must create a dummy div with the class of “Warning” so it’s usable elsewhere.

I then need to keep that dummy div around somewhere in case I want to change the shade of red on all elements that are using the “Warning” class – otherwise I have to edit every single element that is using that Combo Class.

This is my current workflow (as well as others, IIRC) in order to make managing complex stylings more maintainable over time – and inevitably produce cleaner code upon export.

Of course variables will help this, which Webflow has acknowledged as a feature in the works since I’ve been using Webflow, but variables alone can not solve the “unable to use Primary elsewhere” example as explained above.

Personally, it’s just getting to be a big PITA having to do it this way – it’s not scalable.

I welcome suggestions, however, especially if I’m talking out my bum or missing something completely.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.