I have been working on a web page and would like to load multiple stylesheets in an external library.
Unfortunately, this library has many CSS files spread under the same folder.
The names are complicated and its such a pain to manually link it one by one.
As it
<link type="text/css" href="site/libraries/folder/highlight-areas.css"></link>
...
Is there a shortcut that loads all CSS files on the same page within the folder site/libraries/folder
I know how to do this with Ruby on Rails but that is another domain.
Is there a similar technique available on the client side?
Thanks in advance
Would the CSS #import function help you? It allows you to import a CSS file into another, so you could create one master CSS that links to the rest of library styles.
Not as such, no. Javascript does not have access to server-side information at all. (And thank goodness!) However, if you wanted to, there is nothing to stop you from:
Creating a page in some server-side scripting language that either:
A. Grabbed the contents of all of the .css files inside of site/libraries/folder and served them up as one CSS file upon request.
B. Sent your client-side script a list of all of the names of the .css files in the folder so it can load them when needed.
Set up a script in your deployment phase that either:
A. Updates your .js, .css, or .html files with the names of the .css files you want to use.
B. Concatenates all of your .css files into one file and deploys that to your server.
Each of these approaches has strengths and weaknesses. 1A requires processing time for every request (unless you cache the results, in which case you might want to consider just going for 2B) 1B will not work for clients with Javascript disabled. Both 2A and 2B require that you always run your deploy scripts after you make an edit. So it's really up to you.
Just an idea (not tested):
setup the htaccess file to allow listing the directory contents of the stylesheets directory
parse the result to extract the file names
inject the link tags using document.write
Related
I want to know if installing jquery/bootstrap/font-awesome can be done automatically, instead of installing it via npm and then manually dragging the code to my css/js/fonts folder?
Is there no program that can update and automatically drag them to the correct folder?
I know people are saying that you can just manually drag the javascript file to the correct location, but bootstrap for example consists of more than a single javascript file. It includes font and css files.
If I were to include them in this manner:
\web
-\css
--\app
---\main.css
--\font-awesome
---\font-awesome.min.css
-\fonts
etc.
Then it wouldn't work, because font-awesome expects it's fonts to be one folder aside.
JQuery, Bootstrap and Fontawesome are not softwares or applications that you install in a webpage. They are just CSS and Javascript files. So these are like any other javascript or CSS file you may have written from scratch for your webpage. Except that they are well maintained, highly optimized and made for a particular application. (Like Bootstrap primary purpose is to provide a framework for making webpages responsive.)
To include them to a webpage all you have to do is tell the HTML file to use those files. And this is done by linking them to the HTML using the <script> tag and its src* attribute. (*W3schools link. Hehe).
Now in src attribute you may provide a URL to a location on the web containing the file or you may provide a relative local path to a location in your server or local machine containing the file. Yes, you can manually drag the files into your css/js folder and just include the files using that path. No Im not aware of any softwares to automate the process. But you need only place the file in one location for an entire webpage and its sub pages to access it. So its not a very intensive process.
As for why CDN's host such files for public access, an insight is given here : How cloudfare provides free service. And security, well, they are pretty darn secure, it is literally their job to provide secure access to the files they host. And why people use CDN in the first place is because this (in short performance).
Update:
As for how to include files in your HTML, it goes like this (Bootstrap example) :
<link rel="stylesheet" href="static/bootstrap/css/bootstrap.min.css">
<script type="text/javascript" src="static/bootstrap/js/bootstrap.min.js"></script>
You need to provide the path to the required CSS and JS files. In the case of Bootstrap these two are the only ones you need to include to get full functionality of the library.
I think it is not a good idea to use local files instead of CDNs until you are not working offline.
Here you can read about CDNs vs Local Files:
https://halfelf.org/2015/cdn-vs-local/
Multiple files on CDN vs. one file locally
https://www.sitepoint.com/7-reasons-to-use-a-cdn/
Although there is one another link that is just opposite:
7 Reasons NOT to use a Content Delivery Network
Nevertheless if you want to use the files locally you can follow the instructions below:
Move at the cdn link in your project
Copy the link from src or href and open it in your browser.
Save the file locally and give the reference of the file in your project.
I understand a couple questions (i.e. this) of this nature have already been posted, however no solid solution has been found. From what it seems, Meteor currently lacks of the ability to dynamically load/render different UI JavaScript (i.e. uilang) or CSS files per template. In my application, I have templates that require specific JS libraries and CSS as oppose to other templates.
For example:
user.html requires -> uilang.js, user_ui_code.js, userstyle.css
admin.html requires -> uilang.js, admin_ui_code.js, admin_style.css
I would need each js/css file to render/load depending on which route gets requested (i.e. example.com/user or example.com/admin), for things like different background-colors, transitions, etc. Meteor documentation states:
Files in /public are served to the client as-is. Use this to store assets such as images. For example, if you have an image located at /public/background.png, you can include it in your HTML with or in your CSS with background-image: url(/background.png). Note that /public is not part of the image URL.
So you would think that putting all your js/css/images assets in public and calling the needed files statically in head would solve the problem. Instead, it seems that the JS (CSS as well) files get concatenated and it all runs at the same time regardless of which route you are on, thus overlapping code. I'm not sure if I am missing something blatantly obvious or is this an actual issue in Meteor?
Thanks for any help.
Meteor doesn't yet support lazy/on demand loading of resources. The feature is on the roadmap as "incremental loading".
In the meantime, have a look at numtel:publicsources and numtel:privatesources, which let you create bundles for lazy loading resources, with or without authentication.
2 part problem whilst using minify. Finally got it working on localhost.
1) I have some scripts which can be linked externally to CDN, how do i include these in the minify?
<script type="text/javascript" src="/min/b=highaccess/js&f=styleswitcher.js,jquery-1.7.2.js,jquery-ui-1.8.19.custom.min.js,downloadxml.js,geometa.js"></script>
I also need to include this:http://maps.google.com/maps/api/js?key=AIzaSyAOpIKcVcsbojjjFIwnAOSsDwi_lARLp8o&sensor=false
If possible i will use hosted scripts.
2) I have managed to minify the CSS, but i have a style switcher for 3 layouts, when i include them in the minify they cascade, not what i intended. Is there a way to minify this or must I have seperate elements for each style?
1) Minifying the external assets from a CDN kinda defeats the purpose of using a CDN in the first place. You're offloading the content to another server and you gain the benefit of having those files being likely to have been cached already (downloaded when a user visits a site using the same CDN as you). If you must have them minified, just get your own local copy and include it in your minify script. Otherwise, I would just leave them as separate script calls.
2) Minifying CSS means that everything is combined into a single request, so yes, styles added later will override the earlier styles. If you have 3 separate themes, you'll need to have 3 separate minification processes for each theme. Just load them dynamically in tags with javascript and they will override at the time you switch.
I'm trying to optimize my website. I have a few plugins to include (jquery plugins with CSS), and my own javascript code.
Now I have the CSS in separate files for different plugins, as I downloaded them. And if I need one on the actual page, I generate code to include that. The same with the JS files. But when it comes to render a complex page with a lot of stuff, 9 CSS files can be called and 7 or 8 JS files, each of which are HTTP requests.
Should I put the CSS into one big file to reduce the number of included CSS files? But then everything will be interpreted by the browser even if the current page doesn't need so much stuff.
I've thought of a third way: generate CSS and JS files with PHP. Then it'll be always one JS and one CSS file, and only with the things which are needed. Or is it an absurd way?
What do you say, which to use to reduce page load time?
It is better to include all CSS in a file and all JS in a file and the minify them using many online services that minify and compress CSS and Javascript. this will reduce the number of http requests as well as volume of data to be downloaded.
If you generate CSS with php then the CSS and JS should be downloaded with every page and generating them takes some time, but if you pack them in one file it downloads once and the browsers caches it.
if your site has many different sections and packing all css in a file makes a huge file then you can pack CSS in two or three file and in each section load the related one.
reducing number of http request is very important.
I think your last solution is the best one.
Generate one js file and one css file from php, and don't forget to minimized/gziped them :)
Here is a very good article about optimization : http://developer.yahoo.com/performance/rules.html
This depends largely on how your users use your page. If most of the users just view one page then it makes sense to only send them the stuff that they need to display that one page (combining everything into as few requests as possible). On the other hand if most of users view multiple pages then it makes sense to send them more than they need so they will already have the CSS&JS on the next page view. But in this case you have to make sure that you are always generating the same CSS&JS with the same URI, so that the browser will not re-download the same content under a different name. You also have to setup proper HTTP caching.
What I usually do is split JS/CSS in two parts. Every page has a "common.css" and "common.js", which has stuff that every page needs (header/footer/... styles for CSS, and then jquery/common js/... for JS). Then every subpage has it's own JS&CSS that has just the stuff you need for that page (if required).
For me, the best way is somewhere in the middle - for CSS files, you better grab them all, join and compress to one file. For JS code - make for example 3+ files: one with compressed and joined external libs, one with your common stuff, and maybe next files for each bigger section - but I dont think its needed. Maybe splitting your JS code on part needed before user login, and after user login.
Remember to minify and consider asynch loading (with LAB.js for example).
Oh, and this php script... I dont think it is good idea - better use/write some script which joins and minifies your statics on compile (or deploy, or even run by hand), so there is no need to generate everythin over and over again.
Nowadays, we have tons of Javascript libraries per page in addition to the Javascript files we write ourselves. How do you manage them all? How do you minify them in an organized way?
Organization
All of my scripts are maintained in a directory structure that I follow whenever I work on a site. The directory structure normally goes something like this:
+--root
|--javascript
|--lib
|--prototype.js
|--scriptaculous
|--scriptaculous.js
|--effects.js
|--..
|--myOwnScript.js
|--myOwnScript2.js
If, on the off chance, that I'm working on a team uses an inordinate amount of scripts, then I'll normally create a custom directory in which we'll organize scripts by relationship. This doesn't happen terribly often, though.
Compression
Though there are a lot of different compressors and obfuscators out there, I always come back to YUI Compressor.
Inclusion
Unless a site is using some form of a master page, CMS, or something that dictates what can be included on a page beyond my control, I only included the scripts necessarily for the given page just for the small performance sake. If a page doesn't require any script, there will be no script inclusions on that page.
First of all, YUI Compressor.
Keeping them organized is up to you, but most groups that I've seen have just come up with a convention that makes sense for their application.
It's generally optimal to package up your files in such a way that you have a small handful of packages which can be included on any given page for optimal caching.
You also might consider dividing your javascript up into segments that are easy to share across the team.
Cal Henderson (of Flickr fame) wrote Serving JavaScript Fast a while back. It covers asset delivery, not organization, but it might answer some of your questions.
Here are the bullet points:
Yes, you ought to concatenate JavaScript files in production to minimize the number of HTTP requests.
BUT you might not want to concatenate into one giant file; you might want to break it into logical pieces and spread the transfer cost over several pages.
gzip compression is good, but you shouldn't serve gzipped assets to IE <= 6, so you might also want to minify/compress your JavaScript.
I'll add a few bullet points of my own:
You ought to come up with a solution that works for both development and production. In development mode, it should pull in extra JavaScript files on demand; in production it should bundle everything ahead of time. Switching from one behavior to the other should be as easy as setting a flag.
Rails 2.0 handles all this through an asset cache; other web app frameworks might offer similar solutions.
As another answer suggests, placing third-party libraries in a lib directory is a good start. You can also divide your own JS files into sub-directories if it makes sense. Ideally, you'll be able to arrange them in such a way that the files in a given sub-directory can be concatenated into one file.
I will have a folder for all javascript, and a sub folder of that for 3rd party/shared libraries, and sub folders for each component of the site to keep everything organized.
For example:
/
+--/javascript/
+-- lib/
+-- admin/
+-- compnent1/
+-- compnent2/
Then run everything through a minifier/obfuscator during the build process.
I'v been using this lately:
http://code.google.com/apis/ajaxlibs/
And then have a "jscripts" folder where I keep my custom code.
In my last project, we had three kinds of JS files, all of them inside a JS folder.
Library code. A bunch of functions used on most all of the pages, so they were put together in one or a few files.
Classes. These had their own files, organized in folders as needed, but not necessarily so.
Ad hoc JS. Code that was specific to that page. These were saved in files that had the same name as the JSP pages they were supposed to run in.
The biggest effort was in having most of the code on the first two kinds, having custom code only know what to call, and when.
This might be a different approach than what you're looking for, but I've been playing around with the idea of JavaScript templates in our blog engine. In a nutshell, you assign a Javascript template to a page id using the database and it will dynamically include and minify all the JavaScript files associated with that template and create a file in a server-side cache with the template id as a file name. When a page is loaded, it calls the template file which first checks if the file exists in the cache and loads it if it does. If it doesn't exist, it creates it on the fly and includes it. I also use the template file to gzip the conglomerate JavaScript file.
The template idea would work well for site-wide JavaScript (like a JavaScript library), but it doesn't cover page-specific JavaScript. However, you can still use the same approach for page specific JavaScript by including a second file that does the same as above.