-
Notifications
You must be signed in to change notification settings - Fork 26.2k
Feature Request: ability to produce and load CSS via link tag in index.html #14914
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
See #11682 |
We would really like the option of having 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 is default in production mode in Angular cli but I still see styles added in head tag with SSR. |
@pcroc @naveedahmed1 The angular/packages/platform-browser/src/dom/dom_renderer.ts Lines 43 to 44 in 81e975a
|
@trotyl most of the styles I see in head tag with SSR are the styles of Material components. |
@naveedahmed1 That's reasonable, material are using component styles frequently:
Those styles will be compiled to JavaScript string (with placeholder for component id) during template compilation, and result to the final 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). |
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. What do you all think? |
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. |
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. |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
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:
<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 withViewEncapsulation.None
orViewEncapsulation.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.
The text was updated successfully, but these errors were encountered: