Welcome to the community
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.
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).
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 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.