This is a very small optimisation but can add up given the amount of usage the Class/ID input gets.
The main impetus behind this request is that in 99.9% of cases, if you are typing in a new class or ID, you are likely doing so because you intend to use it, even if only temporarily.
Having to type it in, then toggle it as active every time is only a minor inconvenience but it will be so much quicker when setting 100’s of classes/IDs to be able to skip that step.
Hi @StrangeTech,
One sometimes forgets these little things, thanks for pointing them out.
I definitely think your proposal of toggling the ID on when modified is great.
For classes, I’m less certain this is useful as they are automatically added if any styles are applied to the block class.
Cheers,
Understood, this was something we also thought of - currently the blue dot is only shown active when the user toggles it.
We thought perhaps it could be shown in a different colour if the class is implicitly active (i.e. if Cwicly has detected it is needed based on having active styles for the block). Currently, it not being shown as active, even though the class is being added to the block confused a few people in our team initially.
I think that would add an unnecessary layer of confusion, also taking care of it and managing an additional setting per block basis isn’t something I would like to see here.
Although from a logical point, the current behavior is intuitive in my opinion, I also understand that some users might not get it at first glance.
In case this point gets addressed, there might be a smarter solution.
Any new feature could potentially be confusing and the best way to address that is to make it as clear and intuitive as possible. To clarify, there shouldn’t be a setting required for this specific aspect.
At the end of the day, while our individual preferences may differ on some minor details, we all want the same thing, an efficient and productive experience for us and our clients.
Currently, the class is shown as “inactive” when in fact it is implicitly active. This is not the best user experience for conveying accurate state information.
In other simpler cases, when typing a value in a field, the “dot” for that field is automatically activated to show the state has changed. The user can clearly see which fields are active and which are not based on this convention.
Because of the helpful automation of adding the class only when it is required, having the “dot” for the class field show as activated whenever the class is being added is perfectly logical.
The dual state (e.g. different colour “dot”) I am proposing is only necessary because currently the user couldn’t completely de-activate the class that is implicitly activated by clicking the “dot” because of the automation.
If preferred, another way to show the class is implicitly active can be used, but it seems the obvious choice to use the “dot” for consistency.
I agreed with your point, I partially disagreed with your proposition - simple as that.
Starting throwing in different colors could be problematic. That’s all I said.
Of course it should be visualized with the dot, that’s the whole purpose of it.
Your proposed dual state is most likely the perfect fit.
Tbh, I would care much less about all this stuff, but unfortunately, it’s not possible to tweak things according to my own requirements.
As usual, we agree on most points. The colour was just one option, as long as it is clear to the user what the state is, then there are multiple ways that can work for the UI.
Understood and agreed. Customisability will allow much more freedom.
Thank you @Araminta, the only thing that is not covered is what was in this comment:
I think this is probably best done in a separate feature request.