Ability to remove ID's/classes, make HTML more clean

From old feedback: https://feedback.cwicly.com/boards/feature-requests/posts/ability-to-remove-id-s-classes-make-html-more-clean

Well, i am not sure if this is even possible or if it would break things.
But why don’t we have the option to remove ID’s from blocks? I have no problem with it when they are generated automatically but why no option to delete them? Since they are not used for any styling (thank you so much btw. to attach the styling to the class an not to the ID, like every other tool does, which is a no-go in my opinion), they are just sitting there doing nothing? When I just need a DIV I have an ID and a class sitting there for no reason which I can’t delete. Cwicly is really close about having 100% control over the HTML and this is a “feature” i would love to see. If it is not possible, I am curious about the reasons. Just a small addition related to clean HTML code. When using interactions, the related code is injected via JS inside the HTML I guess? Creating complex interactions would result in something, I don’t want to see inside my HTML so I would prefer to write my own JS which is really unfortunate since the interactions are a really huge feature Cwicly has to offer. Maybe this can be solved with a data-interaction-id attribute and the code can be attatched to that in a separate file or something like that.

This would be a great option once implemented.

Hello everyone,

I wanted to get back to you and have a little discussion about classes and IDs. I have touched upon this but wanted to clarify things and hopefully have your opinion on the matter :slight_smile:

I also want to get this “fixed” quite soon, as it is fundamental in showing the direction Cwicly takes.

Currently, Cwicly adds a few default properties to every block (notably display and position).
In retrospect, this was a bad decision as it marks all the Cwicly blocks a user creates, and basically makes removing these defaults impossible (as it would affect too many users).
These defaults were added because of Gutenberg’s awful tendency (in the past) to be very opinionated.
They are no longer required.

No more defaults (for most blocks) = class unnecessary = we can remove the class automatically (and add the class if properties are specified, depending on the user’s preferences).

The only way I see this achievable now is going the block defaults route: allowing the user to specify the defaults for every Cwicly block (much like Gutenberg does in FSE).
This way, the current Cwicly defaults will be maintained for every block type, but the user can modify those defaults which will be reflected on ALL Cwicly blocks (past and future).

As for IDs, we will provide the user a way to show/hide by default, automatically adding them if needed with a specific Cwicly function on the frontend.

What do you think about this solution? Suggestions welcome :slight_smile:

5 Likes

Thank you for giving us an update regarding this.

Sounds really promising to me. This is something I am really looking forward to.
Dedicated block defaults sounds great, also in terms of finally getting rid of all the current defaults, which can be really annoying.
Will there also be an option to add default classes?

Can’t wait for it! :tada:

1 Like

I am not familiar with the code and would like to hear other people’s opinions on technical matters. Therefore, I would like to express my opinion as someone who does not know much about codes.

I think the default class assignment is great. It would be useful to be able to edit that default option on the global style edit screen or on the Cwicly admin screen.
In particular, it would be useful to add margin-bottom: 20px, etc. from the beginning for paragraph blocks, since these blocks are basically infrequently changed.

As for block ID/class, it would be useful if nothing is given in the initial state and it is automatically generated with one click, for example. (I don’t know how difficult this would be to develop.)
When a global class is given, other classes are basically not used, so I don’t think it is necessary by default.

For the convenience of users who customize highly, I think it would be useful to have a toggle switch on the Cwicly settings screen for “automatically assign ID” and “automatically assign classes”.

I like how you’re thinking. It was my contention that the class should be added automatically only if the user adds some CSS styling to a block. Which makes sense, I think. Otherwise, no class, no IDs applied, and we can add our global classes and style as we see fit.

Would go a LONG way to clean up the markup and the associated CSS.

If you need to implement it as an option in settings, I’m okay with that, too.

Looking forward to how this plays out.

1 Like

You don’t need classes to define what you’re talking about. The implementation to add default styling for certain blocks is there, but it’s still unfinished. More CSS properties need to be included.

I, personally don’t like default block styles (you have to override for things that are different), but they can be very useful.

I think this would work very well. It would be helpful though to set some notification for users in case they add the same ID to two different elements on the same page, as it is not recommended.

Sorry for my lack of understanding, but when I grant the global class I created, do I need to remove the class that is granted by default?

You don’t need to, but you can.

1 Like

I feel like this needs to be looked at soon.

Referencing a bug report I made earlier: Block ID identical after duplicate

I am running into issues with duplicate IDs and Cwicly default classes when using reusable blocks. Copy-pasting using Cwicly’s function is not a problem, but Gutenberg duplicates the class names.

This causes issues where a previously defined element affects a current element, or changes made to one specific element ends up changing a series of others, because they share the same default class.

In addition to adding unnecessary CSS, it’s a source of frustration for me, as I’m having to go back and forth to undo changes made that affect other elements inadvertently and losing a lot of time in the process.

Hopefully we can get a fix for this soon.

Hi there @owynter,

I’m sorry that you’re experiencing this problem, but I do wonder if using Reusable blocks in this instance is the best solution.

May I ask why you don’t prefer using the Cwicly Collection method? It is precisely meant to “reuse” blocks while giving specific actions like “duplicate” or “linked”.
I’d love to know the reason :slight_smile:

I had never explored the Collections, to be fair.

Having just tried it, it’s easy enough, and does most of what the Reusable block function does. Sadly, the classes and ids are still duplicated.

I saved a section which was made up of a number of blocks. The id/class of the container is changed, but all the elements within keep their original id/class.

See this video screenshare: https://drive.google.com/open?id=1cayCxjzK7CQdzMSXL1_KKIuE1EtAo9-o

Indeed, thanks for bringing this up @owynter. This particular issue with the Collection should be fixed in 1.1.5.2.

1 Like

Amazing!

Thanks, @Louis!

Adding default classes or not in the settings would be awesome. Importing a css classes framework like automatic css would be awesome too. When designing a site, either I use a framework or only classes on elements I reproduce throughout the site. So classes by default only bloats the whole thing. I refer to add them or add a real css framework.

1 Like

@Louis This would be huge. The ability to use a framework like Automatic.css

2 Likes

Will this also be addressed?
I was kind of “okay” with it, when working with Firefox.
I currently do consider switching to a Chromium based browser and it is not fun, working with the browser tools to be honest.

Firefox:
Screenshot 2022-06-17 132850

Chromium:
Screenshot 2022-06-17 132659

As you can see, this is the same element.
Not sure why there is even a difference.
It’s not even close to a complex interaction, so I wonder how it would look when doing something more advanced.

This is a pretty decent suggestion in my opinion.
I think Webflow is doing something similar.

Any feedback is appreciated.

1 Like

I want to resuscitate this topic as now with the new classes importer is even more important.

For start, the part that bugs me most are the default properties added to most blocks. (position, display) Removing them, would clean a lot of the classes added by cwicly.

Maybe adding a toggle in the backend for backwards compatibility (to keep old defaults), but having it unchecked on new installs.

2 Likes

Block defaults and the possibility to remove classes/IDs has been introduced in the latest updates with 1.2.1.6 being the last one to focus on these specifics.

2 Likes