Route-derived class names on the demo pane can collide with add-on CSS

[paodb]

What happens

TabbedDemo.showRouterLayoutContent names the demo pane after the segments of the demo's @Route, with no prefix. For @Route("splide/image") the pane becomes:

<div id="content" class="splide splide-image demos-v25">

Since the first segment is added on its own, the pane gets a bare, un-namespaced class name that is entirely up to the add-on's base path. If the add-on's own stylesheet uses that same name as a global selector, it now also applies to the demo pane.

Concrete case

The Splide add-on globally imports the Splide library stylesheet, which contains:

.splide { visibility: hidden }
.splide.is-initialized, .splide.is-rendered { visibility: visible }

The library hides .splide until its JS mounts. The demo pane matches that rule but never gets is-initialized — only the real slider roots inside it do. Result: anything placed in the pane other than the slider itself (a description paragraph, a caption, a button) is laid out but never painted. It is in the DOM with real dimensions, just invisible, which makes it look like the component was never added.

Suggested fix

Prefix the generated class names, e.g. demo-splide / demo-splide-image instead of splide / splide-image. That removes the whole class of collision for every add-on, instead of one add-on at a time.

Note this is breaking for any stylesheet that already targets the current names.

Workaround

Re-show the pane from the application's own stylesheet:

.splide[class*="demos-v"] { visibility: visible; }

Version

commons-demo 5.4.0

[paodb]

For context: this was found in VCF Demos (the Vaadin Component Factory demo site, which is built on commons-demo), not in a synthetic test case.

The Splide add-on is showcased there under the splide base path, so its demo pane gets class="splide …". We were adding a short description paragraph to each demo, and on the Splide ones the paragraph simply never showed up — present in the DOM, correct size, never painted. It took a while to trace back to the library's .splide { visibility: hidden } rule rather than to our own code, which is why it seemed worth reporting: the failure is silent and points nowhere near the actual cause.

Splide is just the add-on that happened to expose it. Any add-on whose base path matches a global class name in its own stylesheet would hit the same thing.

[javier-godoy]

The rule for route-derived class names follows a set of assumptions that clearly break in this case (in Flowing Code add-ons we avoid using "common words" as add-on classnames, hence the only unprefixed occurrence would be that in the demo).

While the requested change, as stated, is breaking. We could provide both prefixed and unprefixed classnames, while deprecating the unprefixed ones, so that we can remove them later.