Inconstant loading order of theme files causes css override issues

This issue has two distinct aspects, both stemming from the fact that the order in which theme files and the application’s custom styles are loaded is not constant but varies in unpredictable ways.

Case 1: Using Lumo as the theme, and applying tweaks to components with custom theme modules

• Any custom theme modules are loaded up-front when the application loads.
• If the initial view of the application loaded into the browser does not contain e.g. vaadin-button, the Lumo theme modules for vaadin-button are not loaded.
• When a vaadin-button is loaded into the UI for the first time, its Lumo theme modules are loaded.
• Since the Lumo theme modules have been loaded after the application’s custom theme modules, their css will override any css with selectors of the same weight.
• The only workaround seems to be to artificially inflate the specificity of styles in the custom theme modules, either by adding !important after every property, or e.g. by prefixing each selector with :host(vaadin-button).
• This issue can be easily missed by developers since it only occurs if the component in question is not present in the view initially loaded into the browser.

Case 2: Using a custom theme with Lumo as basis

• To clarify, this means creating a custom theme class and theme module files for each component, which import their Lumo equivalents.
• Since developers will rarely want to create a new theme from scratch, basing the custom theme on Lumo, by importing its component theme modules into the theme’s custom theme modules, is the most reasonable option.
• This is also a workaround for Case 1, since the custom theme modules are now loaded simultaneously with the Lumo modules.
• The problem is instead that Lumo’s default variable values sometimes (randomly?) override any values specified in the custom theme.
• This seems to be caused by the fact that Lumo theme modules for components import the Lumo base files containing the default values, and that these are sometimes (randomly?) loaded into the browser after the custom theme’s global stylesheet.
• This issue can also be easily missed because it only happens sometimes. In Chrome I’ve been able to reproduce it fairly consistently by soft-reloading (Cmd-R) the page, but I suspect that it depends on purely stochastic factors such as file size.
• I have not been able to find a reliable workaround.

@jouni knows more about the issue.

[rolfsmeds]

@rsivan the rationale behind my proposal #2 is that currently each Vaadin Component’s Lumo stylesheet (aka theme module) imports the Lumo base stylesheets containing the default values for each property, and these are loaded after whatever values you set because they’re lazy loaded, and thus override your values. So my proposal is to remove those imports from the Lumo stylesheets for each component, so that the loading of the Lumo base stylsheets (and thus the default values) could be controlled by the developer who can make sure they are loaded before custom values (e.g. by importing them in their own non-lazy-loaded base stylesheet).

That being said, I’m still not 100% sure about the mechanisms behind the case 1 and case 2 issues – just guessing based on my understanding of Flow, Lumo, html imports and my own limited tests – so I can’t claim any certainty in the validity of the proposed fixes.

[enver-haase]

As far as I can see the problem went away with Vaadin14’s npm mode.