Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
When my site depends on many css files, I realize it is a mess. It means, I use different css files from another team, and I put them together with mine. Hmm, many files then!. I get stuck with organizing them. Anybody has a good solution?
You can use cssmerge to merge the files after removing duplicate rules and properties.
Your 'all in one tub' approach suggests you might trample on each-other's CSS definitions.
The ordering in which you include each CSS file may well dramatically affect your site.
There isn't an easy answer for you. You need to get the other team(s) to work in the same way, or perhaps work with them using a version control system where you all contribute CSS to one place.
I'm really interested in hearing about how people group their CSS files and prevent naming conflicts.
But I also think you should consider how you package the CSS for a production release. It really depends on the framework you're using and your application code, but ideally you'll have some way to specify which pages depend on which files, and a build step that concatenates the CSS files for a page together and runs them through YUI Compressor, and outputs a unique filename including a checksum of the content or a date, so that the file can be cached indefinitely. (And then of course you'd put the CSS file at the top of the document)
These are some tips for merging and organizing CSS manually
Separate code into sections like Link Styles,Common Classes ,Layout or Structure Styles ,Header ,Navigation ,Content ,Footer
Indent descendants and related rules
This allows you more easily recognize page structure within your CSS and how elements relate to each other. This method can also be applied for a specific tag such as a heading tag.
Compress your Code to one line
Instead of having each attribute on its own line, have them all on the same line. This reduces the file size of your CSS file and also makes it easy to scan when trying to find a specific tag.
Alphabetize attributes
This just seems to make my CSS easier to read when I’m scanning it or looking for something.
Use shorthand wherever possible
This makes your CSS easier to read and understand and is much more efficient.
Reset your CSS
There are a ton of methods for resetting your CSS
Use separate CSS stylesheets for different elements
Have a main style sheet that you import others into. You could have a stylesheet just for typography, another for layout, and another for colors. By keeping these elements organized within their own style sheets this can make it easier to manage your code.
Declare colors used at the top of your CSS files
Within CSS comments at the top of your file code the colors you are using in your file and the color they represent.
I really like styleneat.com. Only if it wasn't a web app.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
EDIT: While my specific issue is due / relating to the Twitter Bootstrap
system, the solution I am looking for does not need to be Twitter
Bootstrap specific, but more a solution for any CSS style sheets.
I am starting to explore the world of Twitter Bootstrap for a current project I'm working on. I am using Bootstrap 3.3.6
The Issue (why I have the problem below)
The basic Bootstrap CSS file is 6760 lines, as well as additional files for adding my own custom CSS to the site. In total this gives that the site for each page loads ~8700 lines of CSS (unminified).
But the rules applied to the website use only ~700 of these lines. That's a massive overhead for each page, and even with minifying the CSS into the .min.css format this is still a huge percentage overhead.
I am looking for a way of reducing this overhead without removing any of the used rules from the CSS files.
What I've tried (And why it didn't work or is impractical)
I have previously used with great success the Firefox Dust-Me CSS refiner which can identify all unused CSS rules in a page, or even on a whole site.
This is the sort of thing I want, but it has two serious drawbacks:
It only retains CSS rules that are used on the page for the device/media that is used (so for example, it tells me that all the rules in the IE10 viewport bug workaround CSS file are not used because I'm using Firefox browser rather than IE10). It also does not take into account media query specific rules.
The other main drawback for using Dust-Me (specifically, but other similar programs I've found have a similar shortfalls) is that while it will tell me which rules are not used, it doesn't give me an ability to copy/paste the used CSS from the source files.
I have also looked into a few other CSS spare rule removers and the Google Chrome Developers Audit which is useful, but does the same thing, listing in text format the unused rules, which is barely half the job I am looking for.
The Problem (Why I need your help to solve this)
So I am in a position I have a Google Chrome Audit that tells me that 88% of bootstrap.css and 65% of bootstrap-theme.css are unused. These unused elements are listed in text format, and there are hundreds of them. currently I can only see that I would need to do find/replace on each one, removing them [the rule identifiers] from the source before then going through the CSS file and removing all the commands that no longer have any rules.
So I am asking this:
What is the best method or approach for me to read the CSS from a whole website, and
return only all the CSS rules that are referenced in the site, so rules that
are not referenced are not returned to the operator?
I can then take the output from this function and then minify it and save the massive CSS overhead of bootstrap.
Or, is there a completely different way of doing this I've not considered?
Additional:
I have read How to remove unused styles from twitter bootstrap? which is similar to what I'm asking, but the correct answer here references some sort of Bootstrap selection where I can choose which styles I take from the Bootstrap. This is dated 2013 and seems to refer to Bootstrap version 2.
Also, I do not use Grunt and am unfamiliar with Less. Sorry :-/
You can customise the components that are compiled at http://getbootstrap.com/customize/.
This way you will have a smaller outputted file but all dependencies will be met.
To get even finer control you can use the source .less files to compile only the components you want.
You can use unused-css.com which takes an URL as input, which is what you asked for.
This question already has answers here:
css best practices - combining all css into a single stylesheet?
(4 answers)
Closed 8 years ago.
Are there any notable differences between placing all my CSS into custom.css, and dividing it up by controller (For example, putting all user-related CSS into user.css, etc)?
Dividing it up is more organized, but one concern I have is that if I have to write '#import "bootstrap";' at the top of every css file, my app might load bootstrap seperately for every file, thereby possibly increasing the load time.
Any input would be appreciated!
Adding css in different files is, as you said, purely for organizational purposes. It has no functionality differences.
However, when you refer to the #import bootstrap implementation, i would suggest against adding that in every css file, for the reason you stated above (because you can miss something or you can link it twice). If you simply add a reference link at the top of your template html page (if you are using one) or at the top of your html pages (if you are not using one), it ensures that bootstrap is loaded once per page (or once per session if its a single page application) so you wont have to worry about missing bootstrap or loading it multiple times unnecessarily.
hope this helps!
I think it is a matter of personal preference. the more you have code, the more difficulty you will have when debugging or going through the file. For me, I usually store them under the root folder in a Css folder. and I also like breaking them down and not mixing my bootstrap files with my custom cssbut that's just me.
I also split it using specific values like for example if i have a css for a specific browser, i put it in the folder a folder like css/firefox/overrider.css
I think it is just a matter of preference. for the import, individual csswill be better (correct me if I am wrong). It is better explained here: Import vs Link files
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
SO I have a big ASP.NET MVC Razor application that has a large Site.css with over 7000 lines of code, we have been discussing splitting that file into multiple files depending on Views.
For example with have the following views:
About Folder
Index.cshtml
Detail.cshtml
Contact Folder
Index.cshtml
Detail.cshtml
Support Folder
Index.cshtml
Detail.cshtml
and so on...
What we are considering is creating a Common.css file that will be added to the Layout.cshtml
And for each Views folder create a css file specific to those views, is it good practie to do this? Is is it a good idea?
I would keep everything in one css file (especially in production) because it requires only one request to get everything and the browser will cache it for future requests. You can make an exception for views that use excessive css (big 'file' size) and not requested frequently (you can track your visitors browse behaviour and optimize the css loading depending on that). For example you can consider splitting the css for a page that users/visitors only request once or not very often.
However I think it is a good idea to split the css files in development. This will keep things conveniently arranged and easy to maintain. Once you've ready with development you can merge the css files and minify them to decrease filesize. you don't have to do this manually. I'm not an ASP.net'er but I'm sure there are libraries out there that do exactly that. Also you could easily write a css merger by yourself. In the end it's just getting the content of all css files and merge them in one file (in the right order). This file can then be passed to a css minifier like http://code.google.com/p/reducisaurus/
An other option could be to embed the correct css in your html view files between style tags. This way you can separate your css without increasing the number of requests. In fact it will decrease the number of requests by minimum one. However this is not a good idea for dynamic pages as the css will always be a part of the http response (so no caching here, unless its a static page that has not been changed)
EDIT
So to conclude, I would go for a good library to handle your css. Preferably a library that supports less css as this will keep your css even more organised and a lot easier to maintain. With lessCSS you can import css files, nest classes, define variables, do other logic, etc. Great for developement! In production you simply use the compiled css.
for asp.net you could use:
http://www.dotlesscss.org/
for php you could use:
http://leafo.net/lessphp/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Is there any best practices or very practical solutions to organizing mass amounts of css files.
Firstly, how should you use css within a page, should you have a external style sheet for each individual page, and a include css file for 'css reset' and all common elements. Say you have a included header how would you style it, would you have another external style sheet.
This just add up to mass amounts of style sheets, then secondly how to you organize them, do you have a folder for each external style sheet for each page?
Lastly, is there any standard naming conventions, for example if the file was an include would it be 'filename.inc.css' or if it was for a specific page would it be 'filename.pagename.css'
I object to the premise of the question...somewhat. The fact you have so many CSS files speaks to unnecessary bloat. You are probably coupling your styles to a specific context rather than to classes of content. Check out what they are doing at Yahoo for what I mean.
When your CSS is less-context specific, it becomes leaner. This then dramatically reduces the size of your files and mitigates your issue by curing the disease rather than treating the symptom.
So take the time to rethink your CSS to make sure it is only as big as it needs to be. Then organize your layout according just to whatever makes sense for you. After all, the layout of your CSS into multiple files is for your benefit only as a developer. The files will be minified and combined into a single file for the purposes of caching and performance.
And CSS files that are less likely to change because they have been designed for maximum immutability are ideal for caching.
Check http://smacss.com/
SMACSS (pronounced “smacks”) is more style guide than rigid framework.
... SMACSS
is a way to examine your design process and as a way to fit those
rigid frameworks into a flexible thought process. It is an attempt to
document a consistent approach to site development when using CSS.
My advise is always use a preprocessor, it makes the modularity easier. And use SMACSS because is the best way to do CSS especially when dealing with large styles. Check bootstrap repo for an example https://github.com/twbs/bootstrap/tree/master/less
If you have a stylesheet for each page, then every page will have to download a new file. That's definitely not good. You want to take advantage of caching (this goes for anything on the web, not just css) so it would be better to have a little more overhead on a larger css file that only needs to be downloaded once for the whole site. This is a subjective question, however, so there could be and probably are cases where it could be better to split them up - maybe if there were two distinct parts of a site that both needed a massive amount of css.
Generally, having multiple css files is for development only and they should be combined for performance reasons. For example, if I had a menu.css, header.css, etc, those should be in one file when deployed. One example where multiple css files is more acceptable is when they are lazy-loaded by a plugin system like Content Management Systems use. Because the content is so dynamic and the plugins are not tightly coupled to the CMS, it doesn't make sense for all of the css to be combined. That would make it pretty difficult to add and remove plugins.
Oh! In addition to combining all of the css, minification is also great!
There are also libraries like LESS and SASS that are useful in organizing code and cutting down on the amount you need to write.
The best practice would be to have one external style sheet for the entire website. If you can try to name your classes and id's uniquely where they need to be set apart so that there is no confusion between them all in your styling. This way you can maintain the entire site from one file.
If it is absolutely necessary for you to have different style sheets for each page then keep the majority of the styles you will need to render and load that are not page specific and occur on all of the pages to one main css file, then keep the remaining ones that are page specific to a minimum, this will keep your performance higher and save yourself a lot of headaches down the road.
The less technical debt you acquire the better.
Also if you do need multiple style sheets and there are page specific styles you will need that occur on several pages, I would recommend bundling and merging your style sheets to keep the downloads to a minimum and keep your performance higher.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I would wish to start a discussion to get some good ideas on how to organise style sheets in a very big project with a big team of developers working on it.
One possible approach here is to have just one sheet with all the styles organized using comments and regions, unfortunately even using a one-lined writing approach with tabs this sheet would become incredibly big and even having SVN commits and updates could become messier.
So we think it would be better to divide styles in different sheets. What we are not sure is how to organize this as we have different ideas for it.
One possible idea is to organize it for types: colors.css, fonts.css, forms.css, ...
Another idea is to group them by functionality/behaviour: navigator.css, menu.css, warnings.css, errors.css, ...
We could also organize them by page: login.css, contact.css, home.css, ...
Or even use a combination of those three ideas together.
Now what worries me is the fact that we would prefer not to add all the styles to every page, as not all the pages require all the styles and we are really worried about performance as our project is consumed by millions of users everyday. We of course compress it later on deploying but even so we think it's wiser to load only the required ones per page.
On being so, I am worried about other developers not loading styles in correct order, as having different sheets needed to be loaded depending on the page, or on the group of pages, they could get this messed up and on doing so cascading will fail (imagine they load menu.css before global.css, global would override some menu styles!!!).
Now we could just go for one sheet, we could just load all of them always, or we could use some idea we came to like using an alphabetical prefix to tell developers the loading order:
a_global.css
a_forms.css
b_region1.css
b_anotherregion.css
c_page.css
But that looks a bit horrible being honest. So now I was wondering if there is some type of popular css architecturing out there or at least some good ideas we could use for our project here.
Many Thanks!!
Go with a preprocessor, so you can organize source files however you want. (Our team uses LESS, because we've started with Twitter Bootsrap and it stuck). The compiled CSS file should not be under version control, each developer should compile their own version for testing. I'd recommend a grunt task to compile a minified version for production. I'd go with component-centric approach (forms, navs, grid, typography etc).
Using a preprocessor gives you the power of variables and mixins. You can keep files like variables.less and mixins.less in which you define common styles. So you when that blue color changes into slightly lighter blue you just change it in one file.
One large file including all the CSS you need should be fine as it is cached by browsers, so it minimizes HTTP requests to your serwver. Page-specific stylesheets are OK when a particular page has many uncommon elements.
Create a style guide html template which includes every common element you can think of. Headings, link colors, lists, photo thumbnails, form inputs, grid configurations, accordions etc. When you need to create a new component add it to this template, modify the stylesheets, see if it breaks any other elements and how it fits with the rest. Then use these snippets to create particular pages.
SASS or LESS
This will help you to keep your code easy managed. (variables, mixins etc)
Divide in multiple count of files.
Always a good idea. How to divide.
I suggest basically to divide them per page.
BUT -
Exclude general styles to seperate files which will be included everywhere.
By the way, one single file doesn't imply low performance. Are you sure that 10 requests for smaller sheets will be faster than one request for bigger file?
Additionally this files will be cached in web browser, so one file doesn't look like a bad idea.