Disclaimer: There are a few questions on SO regarding CSS and debates over a single or multiple CSS files but I think this is a bit different
I have a pretty big Angular 7 app using Angular Material 2 and I want to introduce themes. Each theme will be retrieved on user login (the theme is saved on the server and cannot be changed by the user).
The question is mainly regarding whether it would be best to export a single CSS file using top-level classes (body or app container) for each theme, replacing only classes that change for each theme or lazy load a new css file on top of the main css file with only the classes that are getting overwritten.
My biggest concern with the first option is getting a huge single CSS file. The current file is already around 300kb (unminified CSS is about 11k lines of code) and with themes ranging from 200-500 lines each and there could be 10+ themes, the file can easily get double or even triple that amount.
On the other hand, lazy loaded CSS might cause the user to download 2 smaller files but the implications might be worse. For example a lazy loaded CSS file needs to be exported with separate configs in Angular CLI and the name needs to be specific so it can be loaded from Angular on login which means caching might be an issue if something changes and also no versioning (eg. theme-blah-2.17.css) is also not possible in the name of the file. Possibly other implications that I cannot think of at the moment too.
Look at how material handles themes.
Also, take a look at how teradata Covalent handles themes.
Related
I've just inherited a large React project. I do not have much experience with React but I'm trying to make some improvements where I know how.
One issue we have is that our main CSS file is huge and one of the main reasons for this is that a bunch of images used in background-image properties have been embedded as Data-URIs despite them being set to relative URLs in the original SASS files.
These images are used multiple times throughout the app and so we end up with a final CSS file that has the same images embedded multiple times!
The application is built using react-scripts build which I believe is the culprit. As stated here:
To reduce the number of requests to the server, importing images that
are less than 10,000 bytes returns a data URI instead of a path.
I don't want this. Is there a way I can disable this? The project isn't using Webpack or any other build tool/bundler. All I have is the scripts in package.json to play with.
I'm not sure if you can do this with a simple toggle, since create-react-app isn't very customizable by design.
In order to change any configuration you'd like, you have a couple of options:
Forking the configuration (https://auth0.com/blog/how-to-configure-create-react-app/), which allows you to modify the configuration but still stay within create-react-app's boundaries.
Ejecting (https://facebook.github.io/create-react-app/docs/available-scripts#npm-run-eject) which will irreversably give you full power over the build configuration (which means you also have to maintain it going forward).
I'm using CSS Modules (Sass) with rollup on a component library project, which is working well. Each component ends up with a dist folder containing a single JS bundle file, and a corresponding CSS file with the scoped CSS classes so consumers of the component don't have to worry about CSS class name conflicts. All they do is include the JS bundle and the CSS file and everything is great. Yay CSS Modules.
The problem I'm now facing is that some components really need separate "themes" - ideally, separate CSS files, one per theme. So consumers can continue as they've been doing: including the JS bundle, but now choosing which CSS file to include to pick a theme.
I'm not sure how to get this going with CSS modules & rollup, and whether this is even the sort of approach others are taking. From what I can see, rollup always handles bundling things together, whereas I want separate CSS files, all of which get their classes renamed identically during the build phase. That way, if within my JS I refer to styles.myclass, if myclass had gotten renamed to scoped-myclass by CSS modules for the original CSS file, for a second CSS file it would also get the same name.
This would keep consumption of the component extremely simple - just a matter of including a different CSS file.
Any suggestions?
Awfully late, but let me answer this 3 years on. So what I ended up doing was totally detaching the CSS generation step from rollup and relying on the Sass CLI to handle that portion of the build process. It felt a bit klutzy, but I remember it wasn't awfully hard to do and solved the problem I outlined above. I don't believe there was a plain rollup solution at the time, nor do I think there's one today.
However... in my case the whole approach was kinda mistaken. This certainly won't be everyone's scenario, but let me spell it all out because hey it may be useful and it definitely wasn't obvious to me at the time.
This was for an in-house shared component library, where each component and its corresponding CSS was a separate npm package stored in our Artifactory. When it grew, plenty of internal references popped up, e.g. multiple components would reference the Button component, and over time they'd reference different versions of the Buttons component - each of which needed its own properly scoped CSS, unique to that package-version.
So what I found was that by doing it this way - having the CSS generated as part of the npm package dist files - I had to write an additional layer for the consumer applications that would parse their node_modules/ folder for our own internal components and combine all the different CSS files, such as the multiple versions of buttons. e.g. the main application would directly import buttons v1.0.0 in its package.json file, but the Dialog component (also included in the package.json) could include buttons 2.0.0 as its own dependency. For every version of the package, there was a uniquely scoped version of the CSS - so the consuming application HAD to include every version otherwise the styling would be borked.
So all in all, it ended up being way more complex that I wanted. I thought I could make it easier & better with the separate generated themed CSS files as part of the package dist, but it didn't end up that way. If I could revisit that project today, I'd re-examine a solution used by Material UI and others which I kinda poo-poo'd at the time: automatic injection of the CSS into the page by the component JS, rather than generating standalone CSS files which required extra work by the consumer applications to gather up and add to the final webpage. Frankly, now I regard it as the "least crap". There are definite downsides to the injection approach (extra work done on every page render for everyone! Yikes!), but there's no doubt in my mind it hugely simplifies the job of the consumer applications. It's a balancing act, but in 20-20 hindsight I'd lean towards the injection approach. With that, scoping & theming is a different and much simpler problem.
If I got you right, consider looking at SCSS plugin: rollup-plugin-scss. It captures all spare .css files imported in the components, and then processes them through underlying node-sass. The catch is, it seems like you can write a custom callback function that'd handle your CSSs differently based on conditions you throw in.
Based on the example from the plugin's page:
import scss from 'rollup-plugin-scss'
...
export default {
input: 'src/index.tsx',
output: [...],
plugins: [
...
output: function (styles, styleNodes) {
// replace this with conditioned outputs as needed:
writeFileSync('bundle1.css', styles)
writeFileSync('bundle2.css', styles)
},
]
}
I'm new to web development and am developing a website using bootstrap. I've got quite a few .css files that involve bootstrap, an open source bootstrap theme, some style sheets for the plugins I'm using and etc. Thing is, I feel like I'm doing the same thing over and over again, putting a lot of overhead on things.
For example, this is how the styles on the web page I'm developing currently operate:
Bootstrap default theme is loaded
Bootstrap custom theme is loaded, overrides the majority of the default bootstrap css configurations
My own custom css file is loaded, overrides the majority of the custom theme css configurations
I guess it's worth mentioning that my custom css file only overrides colours and borders.
I'm thinking if the theme is open source, should I just edit the theme itself? Or should I still be editing everything within my own custom css file?
Again, I'm very new to web development so apologies if this is quite a silly question. Optimisation is key for me, though. After the development stage I will combine the CSS files using bundles provided by the Microsoft.NET optimization package.
Never modify a library directly (css, js, php etc.). What if a new version come out, fixing some bugs. You can not download it, because it will override all your fabulous work.
You get the right process right now. Import your libraries, then override them with you own file and lines of codes.
In your case, it does not matter at all the number of files you are importing, because you will combine and minify them.
If you really care about performances, I suggest you to look at the "CDN" systeme, for Bootstrap or jQuery it could be interesting and provide some good benefits.
Look at this question and the answers, they will give you some good hints : Single huge .css file vs. multiple smaller specific .css files?
I have a website which uses 1 css file, it is called body.css and it consists of 841 lines. Should it be sorted in different files (header.css, footer.css page1.css, etc...), is it better in just 1 file or does it not matter?
The only thing I know for sure is sorting it in more files is a lot more readable.
Also if someone answers this I'd be most grateful for a little explanation.
My opinion would be one of two things.
1) If you know that your CSS will NEVER change once you've built it, I'd build multiple CSS files in the development stage (for readability), and then manually combine them before going live (to reduce http requests)
2) If you know that you're going to change your CSS once in a while, and need to keep it readable, I would build separate files and use code (providing you're using some sort of programming language) to combine them at runtime build time (runtime minification/combination is a resource pig).
With either option I would highly recommend caching on the client side in order to further reduce http requests.
So, there are good reasons in both cases...
A solution that would allow you to get the best of both ideas would be :
To develop using several small CSS files
i.e. easier to develop
To have a build process for your application, that "combines" those files into one
That build process could also minify that big file, btw
It obviously means that your application must have some
configuration stuff that allows it to swith from "multi-files mode" to "mono-file mode".
And to use, in production, only the big file i.e. Single CSS
Result : faster loading pages
maybe this will help you..
For optimal performance it is better to have only one css file.
But for readability it would be better to have different files for different parts.
Take a look at tools like SASS, which help do that without sacrifice performance. Additionally it has features to make your files even more readable by introducing variables, function and much more.
Using more files means more requests. It will take more time to load and make unnecessary requests to the server. I'd stay with one file.
The only good reason to have other css files would be if you have third-party components, to keep them separated and be able to update them easily.
The order matters: Rules loaded later will override rules with the same name loaded before (this is valid even for rules in the same file).
What do you mean that your website uses one CSS file? Normally you'd write your style definitions in multiple files, and they are concatenated (or not) into one file. My point is, what you are working on in your development environment should stay modular, readable, it shouldn't be influenced by what you have in production.
As for the order of the CSS files, yes, it matters, as you can overwrite your previous definitions.
For optimal caching I'd recommend you to build all the vendor CSS in one file, and your CSS in another file, versioned, so that if you change something in your code, only that file has to be updated by the browser.
But these things depend on the infrastructure. As the browsers are able now to send multiple requests simultaneously, having multiple files can lead to faster page load than only one. But I'm not sure about this.
you might want to take a look at gulp to automatically optimize, and minify your CSS code.
All css in one file is OK.
But it's free : you can make as many css file as you want.
However usually this is how it is:
1 global css file for the entire page. You put the common css in here that is useful for every page on your site. You can call it app.css or style.css or mywebsite.css or any name you want.
1 specific css file for a specific page when you want to specially separate this css from the global css file. Because it will contains css only useful for a few pages. For example you have a special component made by your own or a special functionnality. Example : you have made a spcial javascript code working with some html for uploading some file and you want to have your code js/css separate.
Usually, you can also have one css page for each page, but always one global css file for the entire site.
Note : Same question is also valid for javascript
Note 2 : You can also think about using a framework to minify your javascript and css into one single css / js file at the end. At work our technical boss use wro4j which works for java but it should exists many more other frameworks as you can search on google.
I am making a website with concrete 5.7. and to edit some things i have copied the Elemental theme and created my theme. But there are two things i don't know how to edit:
1)Is there a way to define how the elements are going to be disposed in mobile version or at least at which size the autonav is going to be changed by the menu button?Also in small screens the logo becomes really small and all the elements appear disordered.(attached file shows those problems)
2) When i change the colors of my website,(settings->design->customize) where does this changes store, because for me it would be easier to use a text editor rather than doing it with the tool. I don't want to create a new color preset, only to know where these changes are stored.
Thanks for everything.!
Photo: https://plus.google.com/photos/109724001772064952270/albums/6114581190555851105 The first one is the original and the other is the mobile version.
That's actually a bit complex. In the elemental folder, there's a css folder. Inside that folder there's a bootstrap-modified.css file that is responsible for many things including the grid. As the name suggests, it is minified so hard to read and modify.
You also have a file called main.less and several folders containing a lot of other less files.
main.less gets processed and compiled into a css file on the fly, meaning when the site is visited and the css file was not generated yet or when less files were modified.
Anything you want modified you should modify in the less files.
Look for media queries "#media" to find styles specific to certain screen sizes.
how elements are disposed in mobile version is really something you need to deal with through the use of CSS. It is not really something Concrete5 has control over.
The changes to design made through settings->design->customize are saved in the database.
BUT the things you can modify are defined in the site's css file. You could simply modify the css file directly using any text editor instead of customizing design through the dashboard.