Blazy renders the same classes on all blazy elements on a page.

I created a patch that cleans out the function so the DOM is now a lot less bloated with unneeded classes.

I might miss the point why all these classes are added on every media element but they are not needed for the module to work and I don't see the value they add.

Feel free to enlighten me.

Thank you.

You are correct about DOM diet. I am glad you are aware of it.

However it has always been Blazy's concerns since the initial devs, and your particular OP issue been made an option later.
You can remove these classes at /admin/config/media/blazy

Remove field/ view wrapper classes
> Remove useful classes for DOM diets when you can get rid of Field, Block, Views, etc. wrappers so you have context for styling. Other required classes: lightbox, grid, etc. are intact if so-configured.

Another obvious useful DOM diet you might not notice is the removal of field containers:
.field > field__items > .field__item
to just:
.field

I know some people disagreed, that is why a hook_alter at Blazy is provided, and also an UI option is provided at sub-modules:
Slick, Splide, Blazy layout builder under Use theme field or Use field template options.

About the same classes logi
The same multi-value field will output the same classes whenever being split as an individual field block foe example when using blazy option By delta. That is the correct logic, no bugs. However each is unique as output. To prove its uniqueness, make each field output of the same field using Media switcher > Colorbox. You'll get individual unique field rendered correctly with its unique colorbox ID. Press F12, Inspect element the field container, and see its different ID.

Feel to contribute any more improvements, just be sure to read the entire docs at /admin/help/blazy_ui and /admin/config/media/blazy to avoid unnecessary dup efforts, and save yourself your precious time.

Thank you for your reply, I checked the Blazy settings page but it seems that I read over the checkbox to disable these classes.

If I may suggest an upgrade I think it's fair to check this setting by default as you a clean DOM is prefered over all these classes in most cases but that is just my view.

Thanks!

Good idea, but that might break existing installs which already utilized those classes, although it looks like very minor and can be solved by toggling this option.

We should minimize disruptions because not all people can communicate an issue in a civil manner like you did. I have enough rambling tyrants around my projects, and any disruption, even minor, will invite them to make it as a valid target for unnecessary strikes. These tyrants are not only abusive in adverbials and adjectives, but also not paying me a dime for using my works which is perfectly fine since they are open source, anyway.

I am fairly happy now, I saw more and more contributors can speak with data, and focused more on the underlying issues than useless gossips or side kicks.

Dear gausarts, thank you for the compliment and sorry to read that.

Just a thought:

If we would toggle this setting by default in the install file of the module it would only trigger / set it default for new installs.

Existing installs wouldn't be affected, if you want to affect those (which you don't and I totally get that) you would add this in an update hook.

If you are interested in a patch for the install file i'd be happy to make it but it is not a dealbreaker for me.

Thank you for all your work and have a great evening! There are a lot of good people out there so try to focus on those, that may help!

Makes sense. We can always consider this later. However till I have more free time for open source works, I prefer not to fix non-broken codes, or non-major broken codes that already have UI fixes :)

It is always a breeze seeing kindness around my projects. Yes, that is why I am still here after 10 years of insults, I also saw many good people around like you :)

Thank you.

For documentation purposes, I forgot to emphasize the reason for those useful classes as it was mentioned there:

> Remove useful classes for DOM diets when you can get rid of Field, Block, Views, etc. wrappers so you have context for styling.

As I said I am a big fan of @mortendk.
In a strict DOM diet, I normally clean out block and views wrappers whenever possible leaving these field classes are the only contextual and useful classes to work with. Possible means not always applicable like in Views AJAX, nor when running out of dev time.

Meaning, it might cause a bloat as you perceived initially, but has a nobel usage for a bigger strict diet plan in essence.

Anyway, that is what the option is for, to satisfy both scenarios :)

Automatically closed - issue fixed for 2 weeks with no activity.