This question already has answers here:
Create a variable in .CSS file for use within that .CSS file [duplicate]
(13 answers)
Closed 8 years ago.
Im working on a website and my boss wants me to use CSS variations and I dont know what he is talking about.
Let's say I have 20 different elements using #7d2d39, rather than having:
background-color:#7d2d39
color="#7d2d39"
All over the style sheets he wants me to call it using:
background-color:red1"
color="red1"
and somewhere define what "red1" is that way we can globally change one hex color vs. changing it 20 times? It makes sense as I type it, but I dont think this exists.
You'd need to use something like LESS which supports dynamic stylesheets and variables.
CSS preprocessors are a way of making CSS more "programmatic" by using things like functions and variables. The two most popular are:
SASS
LESS
And then there's others:
Google Closure Stylesheets
Stylus
And there's projects like Twitter Bootstrap which uses LESS. There's nothing directly usable in CSS at this moment. It all requires either a JavaScript or a backend processing to convert the LESS/SASS file into CSS.
But it can help developer keep code organized and cleaned and make managing updates faster.
I've never heard of the term "CSS Variants" before but I would suspect your boss might have meant "CSS Variables", which is more what you're describing. But variables are only a part of the functionality preprocessors offer.
I hope that helps!
I think he is talking about css variables but this is just a draft. LESS and SASS are options, too.
Related
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
This question already has answers here:
Best way to structure a CSS stylesheet [closed]
(2 answers)
Closed 8 years ago.
I am creating a design for a mid-sized Web application. It's my first time, and there is no established design process at my workplace. Previous projects are small internal applications, and the back-end developer used a minimal design just enough to make stuff align where it should.
I started doing the design for each type of page separately, and created a new CSS file for each type of page, e.g. a separate one for input forms, another one for the search interface, and so on. I also made one large file with elements used everywhere (header, footer, buttons, warning messages and so on). It was the only reasonable structure I could think of.
I've been at it for a while, and I'm now noticing that I've created some sort of chaos. When I have an element and need to change the definition of its style, I always have to go through Inspect Element and then Visual Studio's search function, which is still reasonably efficient. But I also frequently find myself looking at definitions in the stylesheet, having no idea what they are for, or if they're still in use at all - maybe we have already thrown out the elements which use them, or they were an attempt to solve a problem which got a better solution.
I am already trying to give good, semantic names to my classes, but it's not sufficient, and sometimes even impossible - every workaround I use seems to leave me with names like .centeringWrapper.
What is a good, workable structure of CSS code which prevents these problems? What principles can I apply to arranging the code?
How can I divide the code into files so I can find the correct file?
How to structure code inside the files so I can keep my orientation within a file?
How to keep the overview of different definitions for the same element which are used within different #media blocks?
Any advice for making my work less messy is welcome.
The best practice for structuring your CSS is to structure your CSS. By that I mean have a system. It doesn't really matter what your system is, as long as it makes sense to you and your team and people can consistently maintain it (at least for a reasonable length of time).
I can tell you one way not to do it, though and that's by not designing each page separately with its own CSS.
I think you've figured this out already, but it's worth repeating.
Now, there are times when I've broken this rule. But it's rare and it's typically on small marketing-centric sites where I simply have 4 very different pages. In general, though, you want to re-use as much of your CSS as you can across all your pages.
One way to achieve that is to start with a pre-existing structure by working off of a CSS framework. A common one is Bootstrap, but there are literally dozens and dozens of options out there.
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.
This question already has answers here:
Would it be a bad practice to use less.js in a production site (client-side javascript compliler for LESS style-sheets)?
(4 answers)
Closed 1 year ago.
Just getting into the fun world of CSS preprocessors. Let's say we're using LESS to render our CSS. I'm wondering about two different approaches:
Using LESS to render the CSS on every page load.
Using LESS as part of the Build Process and just using the rendered CSS in production.
I'm wondering if there are times where you'd use one and not the other. On one hand you have dynamic CSS a runtime and the other static CSS build from a (hopefully) concise and clear LESS template.
This is an article written on CSS-Tricks from Chris Coyier
Chris says that it is possible, with LESS, to use an .less file using the link tag like you do with normal .css files
<link href="style.less">
Although this is one way to process the file, it is not the most efficient way to do it. It could severely slow down loading cases, and it could possibly crash the browser It would be better to use the LESS gem to convert the LESS into CSS. As Chris says,
The "pre" part of preprocessing you can think of as "before you send these files to the live website."
Here is a good article that explains the different ways you can process the .less files.
On the Client-Side compilation, the writer sums it up nicely
Rather than the Sass/LESS code being compiled once, it’s compiled on every single page request — and to make matters worse, you’re passing that burden off on your users, rather than doing it yourself
For your second point, that is essentially what CSS preprocessors were built for. They were made to have a manageable CSS script that is high in readability, and low in difficulty of change. Then, you don't even have to look at the CSS file. Just ship it off to the land of the browsers, where it will get torn apart anyway by browser specific renderings (cough, cough IE).
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.