So, documentation has shown that using #import on stylesheets is a bit slower, and plus it makes extra server calls.
Example:
#import url('narf.css');
Well, I HATE using one giant stylesheet, it is messy. I am a neat freak when it comes to my code. hahaha.
Anyway, I use dreamweaver for my design, but it does not "respond" to using regular includes to include another stylesheet (even with boilerplate). Basically, you cannot access the "included" styles when you are designing.
These do not work when using Dreamweaver (although they may work on the server).
<!--#include file="narf.css" -->
<?php include('narf.css'); ?>
So, I ask, are there any other alternatives to actually USE the styles during the design process and still keep the server requests down? I appreciate any insight you may be able to share.
Thank you again overflow community!
You could just have multiple stylesheets, and concatenate your stylesheets for production, that way you can separate your stylesheets, and keep the server requests to a minimum.
Related
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.
Im just trying to confirm if I understood #import correctly,
Basically what It can do for you probably at least one of the things is to give your css some structure by separating the different layouts in separate categories.
Right now each of my css files look insane, I have about 10 of them for one site and alot of them are using up space for the same code and only some new stuff have been added.
I am guessing that I can use #import to only add style where it is needed?
Yes, it works pretty much like include or require functions in PHP.
You can separate your style in multiple files and include some of them where it's needed.
Unlike PHP, CSS use HTTP requests to import files, which means your site will be slow if you separate your CSS to many files (try to keep it up to 3, but only 1 is ideal).
I suggest you to separate files only during the development period which would allow you to manage your files easier, but put everything into 1 file before launching your site.
I've been working with the ModX Revolution manager, and was wondering if I can turn my CSS into ModX Resources rather than files. I'd also like to utilize Templates and their variables. Is that possible? What are the drawbacks of doing so? Are there any advantages (aside from the ones I think below)?
The reason I would prefer this is that I use several CSS pages with the #import statement to object orient my CSS a little bit better. If I could do this directly in ModX, it would save me uploads and syncing.
In previous versions of ModX (Evo and Revo), you used to have to go through tricks. Now with 2.2.2pl, it is possible with very few tricks. The information to do this is sparse and inaccurate any more. Here's how you do it:
Create Your Template
Create a new Template. I named mine CSS Stylesheet. (Simple as that)
For the content, simply put [[*content]].
Create Your CSS Page
Create a new resource. Name it whatever you would like.
Add your alias. Make sure you do not add the .css at the end. ModX should do this for you.
Now, make sure your new page is published. You may also want to hide from menus.
Add your CSS code. No funny tricks... Just copy and paste it like you normally would.
Test the Stylesheet
Simply navigate directly to your new page as if it were an html document. Don't forget the .css instead of .html. If you see the CSS code, then you've succeeded.
Add Your CSS to the Templates
This one is the tricky part. You won't be able to use the <link rel=></link>.
Simply go to your <head> element. Add the following code:
<style type="text/css">
#import url("");
</style>
Test the
Inside the url("");, just place the url to your new resource.
Advantages
Aside from the saving the uploading and downloading, you can now edit your CSS using any of the ModX tools. Additionally there are a few other perks:
If you're like me, file names are useful, but often not descriptive enough. You can name them whatever you like! Its the alias that is important anyway.
Handy tool-tips based on the Description of the resource.
You may also utilize the Summary of the resource for other things. I place the important file comments in here, so that my CSS is smaller.
Template Variables! In previous versions of ModX, you couldn't have a Template for your CSS.
Chunks and Snippets, if you so desire. You have to write them as plain text, rather than HTML, but it's still useful if you are creative.
Your CSS is now shared between all of your Contexts if you like. This is due to the nature of the #import statement.
You can edit your CSS from any computer. You may even set up your front-end for the editing.
Drawbacks
There's always trade-offs, and with this technique it is no different. A lot depends on how you have things set up for your site.
Your saving and editing is based on your server performance.
Your URL requests will be based even more on your ModX performance. For some, adding these extra resources could slow things down. Often, its not enough to worry about, but its worth mentioning.
It's now managed by the database, so its subject to database security. This can be good or bad. Even it is good, it probably will require extra set up from you.
Your Templates, Snippets and Plugins can break your CSS, if programmed incorrectly. This is something you really want to be careful with.
Each CSS request is treated as a separate request by ModX. The Template Variables and plugins do not apply to the web page you are viewing. They apply to the CSS content.
Conclusion
The whole process takes about 15 minutes. And ultimately, it's even faster to revert back if it doesn't work for you (just don't delete the raw files until you are sure). The added functionality is worth it to me.
We can write CSS as the following types:
Inline CSS
Embedded CSS
External CSS
I would like to know pros and cons of each.
It's all about where in the pipeline you need the CSS as I see it.
1. inline css
Pros: Great for quick fixes/prototyping and simple tests without having to swap back and forth between the .css document and the actual HTML file.
Pros: Many email clients do NOT allow the use of external .css referencing because of possible spam/abuse. Embedding might help.
Cons: Fills up HTML space/takes bandwidth, not resuable accross pages - not even IFRAMES.
2. embedded css
Pros: Same as above regarding prototype, but easier to cut out of the final prototype and put into an external file when templates are done.
Cons: Some email clients do not allow styles in the [head] as the head-tags are removed by most webmail clients.
3. external css
Pros: Easy to maintain and reuse across websites with more than 1 page.
Pros: Cacheable = less bandwidth = faster page rendering after second page load
Pros: External files including .css can be hosted on CDN's and thereby making less requests the the firewall/webserver hosting the HTML pages (if on different hosts).
Pros: Compilable, you could automatically remove all of the unused space from the final build, just as jQuery has a developer version and a compressed version = faster download = faster user experience + less bandwidth use = faster internet! (we like!!!)
Cons: Normally removed from HTML mails = messy HTML layout.
Cons: Makes an extra HTTP request per file = more resources used in the Firewalls/routers.
I hope you could use some of this?
I'm going to submit the opinion that external style sheets are the only way to go.
inline CSS mixes content with presentation and leads to an awful mess.
embedded CSS gets loaded with every page request, changes cannot be shared across pages, and the content cannot be cached.
I have nothing against either method per se, but if planning a new site or application, you should plan for external style sheets.
Inline
Quick, but very dirty
This is (sadly) also the only really sane option for HTML formatted email as other forms often get discarded by various email clients.
Embedded
Doesn't require an extra HTTP request, but doesn't have the benefits of:
Linked
Can be cached, reused between pages, more easily tested with validators.
You want external css. It's the easiest to maintain, external css also simplifies caching. Embedded means that each separate html file will need to have it's own css, meaning bigger file size and lots of headaches when changing the css. Inline css is even harder to maintain.
External css is the way to go.
Where to start!!??
Say you had a site with 3 pages...
You could get away with Inline CSS (i.e. CSS on the page itself, within tags).
If you had a 100 page website...
You wouldn't want to change the CSS on each page individually (or would you?!)...
So including an external CSS sheet would be the nicer way to go.
Inline CSS is generally bad. It's much easier to modify the style of a page when all the styles are located in one central location, which inline CSS doesn't offer. It's easy for quickly prototyping styles, but shouldn't be used in production, especailly since it often leads to duplicating styles.
Embedded CSS centralizes the styles for the page, but it doesn't allow you to share styles across pages without copying the text of the embedded style and pasting it in each unique page on your site.
External CSS is the way to go, it has all of the advantages of embedded CSS but it allows you to share styles accross multiple pages.
Use external CSS when:
you have a lot of css code that will make your file messy if you put it all inline
you want to maintain a standard
look-and-feel across multiple pages
External CSS makes it a lot easier to manage your CSS and is the accepted way of implementing styles.
If the styles are only needed for one file, and you don't foresee that ever changing to apply to other pages, you can put your css at the top of the file (embedded?).
You should generally only use inline CSS if:
It's a one-time formatting for a specific tag
You want to override the default css (set externally or at the top of the file) for a specific tag
To everyone in the here and now, reading after 2015, with projects like Polymer, Browserify, Webpack, Babel, and many other important participants that I'm probably missing, we have been ushered into a new era of writing HTML applications, with regards to how we modularize large applications, distribute changes and compose related presentation, markup and behavior into self-contained units. Let's not even get started with service workers.
So before anyone forms an opinion on what is and isn't feasible, I would recommend that they investigate the current web ecosystem in their time to see if some issues related to maintainability have been gracefully solved.
Pros:
Allows you to control the layout of the entire site with one file.
Changes affect all documents at the same time.
Can eliminate redundant in-line styling (Font, Bold, Color, Images)
Provide multiple views of the same content for different types of users.
Cons:
Older browsers may not be able to understand CSS.
CSS is not supported by every browser equally.
In this case, the pros far outweigh the cons. In fact, if the site is designed in a specific way, older browsers will display the content much better (on average) than if the site were managed with tables.
If you are using a server side language, why not embed CSS and use conditional programming to display it as necessary? For example, say you're using PHP w/ Wordpress and you want some homepage specific CSS; you could use the is_home() function to show your CSS in the head of the document for that page only. Personally, I have my own template system that works like so:
inc.header.php = all the header stuff, and where page specific CSS would go I put:
if(isset($CSS)) echo $CSS;
Then, in a specific page template (say about.php), I would use a heredoc variable for the page specific CSS, above the line which includes the header:
Contents of about.php:
<?php
$CSS = <<< CSS
.about-us-photo-box{
/* CSS code */
}
.about-us-something-else{
/* more CSS code */
}
CSS;
include "inc.header.php"; // this file includes if(isset($CSS)) echo $CSS; where page-specific CSS would go ...
<body>
<!-- about us html -->
include "inc.footer.php";
?>
Is there something I'm missing that makes this approach inferior?
Pros:
1) I can still cache the page using standard caching techniques (is there a caching method that takes advantage of a CSS only external file??).
2) I can use php for special case conditional formatting in specific class declarations if absolutely necessary (PHP doesn't work in a CSS file, unless I'm missing some server directive I could set).
3) All my page specific CSS is extremely well organized in the actual PHP file in which it's being used.
4) It cuts down on HTTP requests to external files.
5) It cuts down on server requests to external files.
Cons:
1) My IDE program (Komodo IDE) can't follow the Heredoc formatting to properly highlight the CSS, which makes it slightly harder to debug syntax errors in the CSS.
2) I really can't see any other con, please enlighten me!
Which method is best for importing multiple stylesheets? Is one method more efficient than the other?
I once read this article about performances and <link> vs #import : don’t use #import ; quoting a small portion of it :
use LINK instead of #import if you
want stylesheets to download in
parallel resulting in a faster page.
It's quite recent (April 2009), so should still be mostly true -- and written by Steve Souders, whose name is quite well-known when it comes to front-end performances.
On a more subjective point, I quite prefer using several <link> from my main HTML file : this way, I am able to see in only a quick glance what css files are called -- either looking at the template file on the server, or looking at the generated HTML source on the client side.
On some (all?) implementations #import is processed at the end of the loading of the page, so you'd have the undesired Flash of Unstyled Content using it.
link works usually better, but if what you wan't is to define a different media, you could use it without problem. Also, its a neat trick to hide CSS from older browsers (<IE5.5).