Global CSS is very harmful in certain environments / should really be fixed

[xdev1]

Describe your motivation

Is it really necessary that Vaadin uses global CSS unexceptional?

Here are some examples:

web-components/packages/aura/src/color.css

Lines 26 to 29 in 47884e9

	color: var(--vaadin-text-color);
	background: var(--aura-app-background);
	background-size: 100vw 100vh;
	background-attachment: fixed;

web-components/packages/aura/src/typography.css

Line 40 in 47884e9

font: -apple-system-body;

web-components/packages/aura/src/typography.css

Lines 66 to 80 in 47884e9

	:where(body),
	:where(:host) {
	font-family: var(--aura-font-family);
	font-optical-sizing: auto;
	font-style: normal;
	font-weight: var(--aura-font-weight-regular);
	/* Set to auto to disable grayscale/anti-aliased font smoothing (and use default sub-pixel anti-aliasing) */
	-webkit-font-smoothing: var(--aura-font-smoothing, antialiased);
	-moz-osx-font-smoothing: var(--aura-font-smoothing, grayscale);
	/* We assume apps are built with responsive layouting in mind */
	-webkit-text-size-adjust: none;
	text-size-adjust: none;
	}

You cannot really use Vaadin custom elements in Wikis, CMSs or similar environments if Vaadin always modifies global styles.

Describe the solution you'd like

Hopefully, I am missing something completely here 😉
If not, wouldn't it be a way better solution to separate global styles from component styles and to provide two ways to import Vaadin styles: One way to import all styles (like now) and one way to only import the component styles (including the Vaadin custom properties of course)?

Describe alternatives you've considered

No response

Additional context

No response

[web-padawan]

Thanks for the issue. Overall, using global CSS is a conscious choice. Originally in Lumo theme we had separate .css files adding global styles, however due to how Lumo and Aura theme ships as bundled now, this has changed.

In theory, this should not be a big problem because of :where(:root) ensuring low specificity - so e.g. following resets it:

* {
  font: initial;
}

Component base styles do not define any global CSS and only use :host selectors so they might be a better option.

[xdev1]

Thanks @web-padawan for the answer.

One of the amazing things about Shadow DOM custom elements is that they can ensure their own styles do not conflict with global styles. They also make it unnecessary to modify global styles just to make the components look good.
If the "theme" of a custom element component library only defines namespaced custom properties (= its own design tokens), the world is in harmony.

But in reality, things are different. I import the Vaadin Aura theme, and the first thing I notice is that my demo app suddenly has a different background color than before.
Later, I use a <dialog> element containing <vaadin-email-field> and <vaadin-password-field> with the Luma theme, and I wonder why those two Vaadin components look completely wrong. The reason turned out to be that I had been testing WebAwesome custom elements in the same demo before and had forgotten to remove the WebAwesome "theme CSS". The WebAwesome "theme" also modifies global CSS, and for whatever reason, Vaadin email and password fields have most of their elements in the light DOM. Their own CSS and light DOM elements conflict with the global CSS from WebAwesome.

This means that the two most amazing web component libraries in the world do not provide their custom elements in a way that allows them to just work nicely, independently of where they are used. Frankly, this is a bit frustrating.

I wanted to use Vaadin (my first choice) or WebAwesome (my second choice) custom elements in an XWiki extension, but what I have to realize is that neither Vaadin, WebAwesome, nor especially XWiki seems to care too much about whether their CSS has a negative impact on the rest of the world.

Maybe the Vaadin team may reconsider some of these design choices in a future version.
Feel free to close this ticket after you have read the comment, as I think there is nothing we can do about these issues at the moment.

Independent of the issues I currently have with this particular combination of libraries, I really want to thank the whole Vaadin team for giving the world such a wonderful library.

[web-padawan]

for whatever reason, Vaadin email and password fields have most of their elements in the light DOM. Their own CSS and light DOM elements conflict with the global CSS from WebAwesome.

Vaadin web components are designed to keep input and label elements in light DOM due to accessibility reasons. In particular, vaadin-combo-box has to keep the input in the same DOM scope as the scroller to make aria-controls attribute work etc. We did face some issues e.g. with Tailwind overriding defaults for input elements and had to overcome them so it's a known issue.

Original versions of Vaadin components used to put everything in shadow DOM and that caused many issues. I realize that some things have improved over the years in newer browsers but screen readers often tend to lag behind and are tricky to deal with.

Supporting other component libraries is sadly not a priority for Vaadin at the moment. It might be also non-trivial especially for overlay based components where different libraries use their own ways of dialog / overlay layering based on popover attribute.

Thank you for the feedback! We might re-evaluate some things especially related to base styles in future Vaadin versions.