I agree with Black Max. They are as long as they need to be to get the job done. No more no less. Of course you want to rationalise as you go and not duplicate common styles but the css will need to be as long as it takes to get the job done.
I have worked on some very large sites where each section is vastly different from what went before with only a few common elements between them. In those cases I split the css files into each section rather than having one massive css file. I separate the common elements into a structural file and then have section related css. If you can get away with one CSS file, that is great. I would say I average CSS files per page. Keep in mind with CSS, it's cascading style sheets , meaning that if I have 3 style sheets linked on a page, make sure you understand how the styles cascade down, or you may get some unexpected results.
Each web page doesn't need it's own stylesheet. You can call that same style sheet from every header on every page, and have all of your styles for the entire site in one CSS file. This is were relative web paths will be great for you. And that otherwise, yes, you can copy and past your header and footer code from page to page, you may just need to update the links you have in those blocks of code to match the page location. Keep in mind you don't want to be copy and pasting header and footer code for long, there are better ways to include those chunks of code.
Probably not on your first site, but eyes on the horizon, you'll want to have your header and footer files eventually separate from the main page of the site, and include, or call in these files as the browser request them. Kevin what are your on average? Personally I like to use only one and have it compressed when I put the sites live. I use sass compiled from many organized files and have a media query included for print as one of them.
On occasion we've had clients needing to print from older versions of IE where I've needed to include a separate css request; but most of the time I'm able to get away with a single one.
I've played with it a bit, but it's not where I've spent much time. I'm actually using this method in WP to override some styling from some WP functions until I can find a better solution. In this case it loads a CSS file if the search get variable is present to reset what showing as the active link in the WP generated code.
I should have clarified. My reset is normalize. I put that and a stripped down version of bootstrap together as my one file to not edit or touch, than my css file, and finally my search. Bootstrap overrides normalize, my style overrides bootstrap, and my search. Break out your CSS by function, so you can end up with 1 or 2 per page on your site. However in the end you should compile them into just one to cut down on HTTP requests. I'll give you an example on my 5 page portfolio site I have 8 CSS files that I wrote myself plus one for a reset and one for syntax highlighting, for a total of 10 CSS files.
The team style guide should always win over your own personal preferences. There often isn't a right or wrong way to do things, but consistency is important. If you get to set the rules for the project or are working alone, then the most important thing to do is to keep things consistent. Consistency can be applied in all sorts of ways, such as using the same naming conventions for classes, choosing one method of describing color, or maintaining consistent formatting.
For example, will you use tabs or spaces to indent your code? If spaces, how many spaces? Having a set of rules you always follow reduces the amount of mental overhead needed when writing CSS, as some of the decisions are already made. There are a couple of ways you will see CSS formatted. Some developers put all of the rules onto a single line, like so:. CSS doesn't mind which one you use. We personally find it is more readable to have each property and value pair on a new line.
Adding comments to your CSS will help any future developer work with your CSS file, but will also help you when you come back to the project after a break. A good tip is to add a block of comments between logical sections in your stylesheet too, to help locate different sections quickly when scanning it, or even to give you something to search for to jump right into that part of the CSS.
If you use a string that won't appear in the code, you can jump from section to section by searching for it — below we have used. You don't need to comment every single thing in your CSS, as much of it will be self-explanatory.
What you should comment are the things where you made a particular decision for a reason. You may have used a CSS property in a specific way to get around older browser incompatibilities, for example:.
Perhaps you followed a tutorial to achieve something, and the CSS isn't very self-explanatory or recognizable. In that case, you could add the URL of the tutorial to the comments. You will thank yourself when you come back to this project in a year or so and can vaguely remember that there was a great tutorial about that thing, but can't recall where it's from.
It is a good idea to have all of the common styling first in the stylesheet. This means all of the styles which will generally apply unless you do something special with that element. You will typically have rules set up for:. In this section of the stylesheet we are providing default styling for the type on the site, setting up a default style for data tables and lists and so on.
After this section, we could define a few utility classes, for example, a class that removes the default list style for lists we're going to display as flex items or in some other way.
If you have a few styling choices you know you will want to apply to lots of different elements, they can be put in this section. Then we can add everything that is used sitewide. That might be things like the basic page layout, the header, navigation styling, and so on.
Finally, we will include CSS for specific things, broken down by the context, page, or even component in which they are used. By ordering things in this way, we at least have an idea in which part of the stylesheet we will be looking for something that we want to change. If you create very specific selectors, you will often find that you need to duplicate chunks of your CSS to apply the same rules to another element.
0コメント