Feature Request: ability to produce and load CSS via link tag in index.html

[alxhub]

Currently CSS is built into NgFactory classes and added to the DOM during component instantiation (with deduplication). This CSS lives in the JS bundle as string constants and is shipped to the browser along with the rest of the application script.

This causes two problems:

• It delays parsing of the CSS until JS execution
• It causes the CSS bytes to be sent twice for server-side rendered pages (once as part of <style> tags, and again as part of the JS bundle). The browser pays the cost of parsing twice in this case, too.

I propose that ngc be optionally configurable to produce separate CSS files (for components with ViewEncapsulation.None or ViewEncapsulation.Emulated). We would need to do some work to figure out the exact mechanism - one CSS file per component? module? app? Do we need to run a CSS bundler? How is CSS loaded for lazy modules?

Ultimately, though, this would allow parallel parsing of CSS and JS code, leading to faster TTI. And in the case of Universal rendering, it would remove the overhead of sending two copies of the styles over the wire for every page load.

[tbosch]

See #11682

[pcroc]

We would really like the option of having ng build to output all styles (in our case, SASS) into a single .css file and not generate styles.bundle.js.

Our use case is a single app with no reusable components, and we would like to apply the same style sheet to server-rendered (non-Angular) error pages.

Edit: Discovered this achieved with --extract-css

[naveedahmed1]

--extract-css is default in production mode in Angular cli but I still see styles added in head tag with SSR.

[trotyl]

@pcroc @naveedahmed1 The --extract-css option is only for project styles (defined in angular.json), not component styles. There's no way to extract component styles as they're determined at runtime:

angular/packages/platform-browser/src/dom/dom_renderer.ts

Lines 43 to 44 in 81e975a

	style = style.replace(COMPONENT_REGEX, compId);
	target.push(style);

[naveedahmed1]

@trotyl most of the styles I see in head tag with SSR are the styles of Material components.

[trotyl]

@naveedahmed1 That's reasonable, material are using component styles frequently:

• https://github.com/angular/material2/blob/6d7f41739207e469e626963d64e661401629902d/src/lib/button/button.ts#L77
• https://github.com/angular/material2/blob/6d7f41739207e469e626963d64e661401629902d/src/lib/card/card.ts#L156

Those styles will be compiled to JavaScript string (with placeholder for component id) during template compilation, and result to the final <style> when rendered (placeholder being replaced).

So if this process can be done statically (pre-compute component id), then it can be exposed to build tool which helps a lot to bundling and performance (also for debugging as linked above).

[adrianhdz2]

I would like to add that this implementation would also help start solving the strict CSP problem. #26152. The big win of static component styles over using nonces is that there is no dependency on a back-end service.

Having component class styles that apply to all component instances would allow the angular compiler to have static css files because it knows all of the component classes . Therefore, ngc can develop unique hashes to keep encapsulation Ahead-of-Time(AoT) as far as component classes go. Of course, deciding how to bundle and how much css should go in one file is definitely difficult to figure out. You could essentially just do one css file per js files. This doesn't seem to unreasonable... When to load the css files would also be worth thinking about too, but having link tags inserted into the head to load styles does not violate strict CSP.

Developers following strict csp would have to be mindful of these two limitations.
1.) Component styles would be on a per class basis and not per instance.
BUT you can use styles tags (or link tags?) directly in angular template. So you could potentially still design around static component styles with that.
2.) You might be constantly loading css more often then you'd like or front-load all css on initial download.
Although, I find that developers who aim to have a very secure application are already accustomed to size and speed tradeoffs to make that happen.

What do you all think?

[angular-robot]

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

[alxhub]

I'm closing this out as not feasible. Breaking the connection between component classes (in JS) and their styles would lead to a whole host of problems. Some of these problems would require a vastly different serving architecture to solve.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}