slick.theme.css overrides Blazy CSS

Thank you.

Mind screenshoting before and after for better spots?

I don't always have laptop nearby.

About the reason, the convention is any modules should work with core defaults OOTB, hence Olivero is D10 theme default. Unlike the previous Bartik, Olivero is very advanced in CSS, thus posing more advanced challenges to contribs. The explanation is right above the fix:

/* Fix for unnecessary Olivero Grid surprises causing Slick excessive height. */

The problem also happens at Splide slider. Normally as a Views block and in a grid. No problems are outside these two conditions.

The actual problem:
Both Slick and Splide have massive widths, only hidden partially to make sense in sliding displays. It was fine so far, until D10 Olivero adds problematic CSS rules, and to my investigation, pretty much useless, that is by allowing the child elements' widths to expand beyond its parent and reveal excessive widths and heights, while they should be hidden in the case of these carousels.

However I am interested in seeing your actual by-products.

Thanks for the quick response. Full page screenshot attached, the top element is Slick Carousel (loaded as a block) but the affected element is a part of a Drupal view used for the frontpage.

We have our own set of classes and CSS, the display:block property basically overrides a display:grid property.

That spots the issue better, thanks.

Let's make it clear:

• The fix is fixing core Olivero integration problem, and it works for core OOTB stuffs. We cannot nego core stuffs for now.
• I understand it breaks your previous custom works, but you must understand it is your own custom works. We are concerning more about the most common use cases here, things like OOTB. Core integration wins over custom works. That is the ugly truth you might never hear nor want to. And the fix corrects it very well.

This might be a regression to old D9 context, but not a bug in D10 context.

It fixed the new bug introduced by Olivero at D10. Without the fix, similar issue like Splide's would be reported here.

Solutions:
Just update and override that rule in your own custom CSS, be sure to have more specificity or exact CSS class to avoid issues at other areas to win over this module.

I hope you understand such a situation.

We've already fixed it on our end but wanted to flag as it didn't seem like the best approach for a module to have CSS that applies outside of its own scope.

Our custom CSS is already applied to our own defined classes and ids. No other module we use overrides it. What happens here is that when Slick loads there is a CSS rule that overrides all .view, .view .view-content, .block .view, .block .view .view-content classes with a custom rule. That simply didn't seem right to us.

We might have a very specific use case and I understand it might not be worth fixing as it doesn't seem to affect many people. We simply assumed it was worth flagging as it might affect others at some point.

My guess is that you might be able reproduce this bug without any custom css but using blazy grid display and get similar results but I could be wrong. In any case, we'll stick to a fix in our CSS for now.

On second thought, makes sense, out-of-scope rule is not right. It was more a quick and dirty fix to D10 Olivero integration.

IIRC, the latest Blazy in 3.x already sniffs for Slick and Splide in Views, and provides the more scoped CSS rule overrides.

So this Slick kill-em-all rules could be removed later after another check.

Thank you for good communication and keeping civil!

This 'fix' is also bleeding into my theme. I've got many .view divs that are being displayed with flexbox. Forcing the .view into a display:block breaks the theme.

Removed the quick-dirty rules.

FYI, the fix is still needed, otherwise Slick has gargantuan width and height.

Only now left to Blazy to be more scoped, and should no longer bleed.
If for some reason the gargantuan width issue crops up somewhere else, Blazy scoped rules fail due to being too scoped.

To solve the issue, simply copy the removed rules, or adjust the ancestor selector to not have problematic grid rules, into your theme as needed.

Thank you for contribution!

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