Cwicly status button (hide\show)

Hi everyone)

Can you tell me about the hide\show status button (grey\green indicator next to the class)?

When I insert a paragraph, the indicator is grey and the class is in the

inspector. If I click on the indicator, the class becomes . Everything makes sense here.

But if I insert a paragraph and change its value, the class also becomes and the indicator doesn’t light up.

Question, is it me who can’t understand the logic or is it a bug?

CleanShot 2023-11-05 at 10.13.26@2x

Hi @DenisKozeev,

Welcome to the community :slight_smile:
Thank you for bringing this up!

To clarify, I’d like to confirm that this is the current intended behavior.

Our decision is not to automatically enforce the class, even if it’s modified, as we believe a user might want the flexibility to modify it without forcing the class, especially when no styles have been attached, in order to maintain a clean output.

The behavior you’ve described is what we’ve implemented for the ID.
We assume that when a user modifies an ID, they likely intend for it to be activated.

We are open to hearing your thoughts and opinions on this choice, and we welcome further discussion on the matter.

Adding to discussion.

Thanks for such a quick response)

It’s probably convenient, haven’t realised it yet. It just doesn’t feel logical (maybe not used to it). And I want to understand the logic of how it works.

If I have described the logic correctly and it takes some getting used to, then ok.

It seems more logical to me that if I change the values of a class, I probably activate it, and it is logical to see the class switched on (it is immediately clear that I made changes to it, it is important to see when working with a large number of blocks).

But maybe I just haven’t got used to it in a couple of days after Webflow and that’s why I feel uncomfortable. Probably your team chose this logic for a reason and I just didn’t catch it).

Hi @DenisKozeev,

Several people have said the same thing to me and I suggested the following potential solution in the original feature request:

Also, you may be interested in this feature request:

For the sake of keeping things clean I have added a new feature request:

I find it quite surprising that this situation hasn’t been addressed to date, especially since there have been quite a few posts in that regard in the past. And I’m not even talking about all the user issues when the ID isn’t toggled.

I appreciate the ongoing improvement process and progress, and it’s fine to throw something in and wait for feedback (which was provided sufficiently in the past half year, imo).
But not addressing newly introduced flaws in a reasonable amount of time is a bit unfortunate.

Users, because the ID field is hidden,

  • don’t know whether a block ID is toggled on or off
  • can’t see the ID initially (in case it’s toggled on)
  • in many cases don’t even know an ID input exists

These few points create a considerable number of problems, not only in terms of workflow.
It is not something minor, it’s a real issue.

I like the changes that were made.
The general approach and implementation of the class/ID area is amazing, really.
It shouldn’t be changed significantly, only some minor refinement is required.
It’s just the lack of accessible/visible info when required.

I definitely agree with this. Every developer I have introduced to Cwicly without exception has hit this exact issue at least once and needed a quick intro to the ID field.

Finding the ID field is not intuitive at the moment.

I concur with this, primarily because these types of issues are regularly addressed with lightning speed by the Cwicly team.

While IDs are less of a priority in terms of general styling (due to the fact that block classes are used for that), the interactions side is where this has been presenting the most issues.

I would also still like to see this feature implemented as an optional setting:

I don’t have any questions about the hidden ID field. You don’t see it, but once you know where it is, there are no questions about it. If you read the manual, you will definitely see where this field is. Besides, ID is not used that often. And when you need it, you know exactly where it is and it’s pretty close. In the same webflow it is hidden deeper, and there are no problems with it.

Since this is a related topic, I think it’s fine to bring that in - especially since this has been tagged as discussion. It’s actually the very same topic since it’s directly linked inside the UI.

I wouldn’t have added any opinion here otherwise, as this is just another post about the same topic which has been discussed several times already.

I agree with this but one needs to consider users feedback too.
A little hint which, if possible, could be implemented in a smart way wouldn’t hurt.
If you ask me, leave it as it is. Clean and simple.

Currently, this is the case. This might change in the future when a user decides to style ID’s instead or classes.
Still, when an ID is used, I want to know that and a tiny visual indicator would be sufficient and I can’t find a reason here why this shouldn’t be a thing.

I appreciate that you have no problem with that.
If webflow wouldn’t have any flaws, I’d consider to add some thoughts.
One thing though. No, it’s not hidden deeper there. It can’t be hidden deeper than literally hiding it.