Content slider CSS class collision

[leofeyer]

Affected version(s)

5.0.0+

Description

Our content slider has an inner DIV with the CSS class content-slider:

contao/core-bundle/contao/templates/elements/ce_sliderStart.html5

Line 8 in 0059b15

<div class="content-slider" data-config="<?= $this->config ?>">

Since the new Twig templates use content-{type} as naming schema, we have to adjust the Contao CSS framework accordingly:

But adding .mod_article *[class*="content-"] would also apply the grid styles to the content slider DIV, therefore we should rename the CSS class of the content slider. @contao/developers Any objections?

---

BTW, we did not stumble upon this earlier, because the slider content element has not been converted to a controller yet. @m-vo Did we leave it out on purpose?

[ausi]

Could we instead use something like .mod_article > * to set these margins?

[leofeyer]

No, that would not really solve the class collision issue. It would just be a workaround in the grid.css style sheet, but the problem will likely occur in other places, too.

[m-vo]

BTW, we did not stumble upon this earlier, because the slider content element has not been converted to a controller yet. @m-vo Did we leave it out on purpose?

Yes, we left out all content elements that currently use wrappers. The intention was to implement them as 'real' nested content elements as soon that feature has landed. 🙂

[m-vo]

What about always adding a class to each content element in the base template? Then we could target content elements directly in the CSS instead of relying on search/prefix? (On that note: Why are we using [class*="ce_"] instead of [class^="ce_"]?)

Too bad we reverted the content element CSS naming in 817e867. 🙈 Otherwise you would have gotten a nice class="content-element content-element/text. But now content-element as a class name would clash with a type named element. Just thinking out loud but you get the point. 😄

[leofeyer]

What about always adding a class to each content element in the base template?

That does not solve the name collision issue, either, I‘m afraid. Once the slider element is converted, it would have the content-element CSS class on the outer DIV as well as on the inner one.

[ausi]

Once the slider element is converted, it would have the content-element CSS class on the outer DIV as well as on the inner one.

The inner classes of the other new twig content elements change too, so I’d guess that we would change the inner class name when converting the slider to a new element controller.

[leofeyer]

We cannot change the inner class unless we also adjust the slider JS. That‘s why I suggest to do it right away.

[leofeyer]

Unfortunately, #6435 does not fix the issue. 😞

Accordion elements get the class accordion ui-accordion-content … ui-accordion-content-active and [class*="content-"] matches that, too.

Why are we using [class*="ce_"] instead of [class^="ce_"]?

Because [class^="ce_"] would only match class="ce_text" but not class="foo ce_text".

Otherwise you would have gotten a nice class="content-element content-element/text.

I guess that would have prevented this issue. Maybe we should use content-element-{type} instead of content-{type}? Or both content-element and content-{type}? Then we could use a simple class selector .content-element instead of [class*="content-].

[ausi]

I think we should move away from selctors like [class*="ce_"] they are way too error-prone and can probably be replaced with better selectors. [class*="ce_"] would also mach classes like nice_box and so on.

AFAIK we use [class*="…"] only in the grid.css and nowhere else. So I’d suggest replacing these selectors there.

If we want to be extra careful regarding BC, we could move from [class*="ce_"] to
:is([class^="ce_"], [class*=" ce_"]) as a first step to avoid most collisions, and replacing them with something else in the next version.

[aschempp]

I think we could also just get rid of the grid.css in an upcoming minor release and have people come up with better solutions for that. 😬

[leofeyer]

Eventually fixed in contao-components/contao#16.