Bootstrap has allocated many keywords that we use when we develop web projects. Such as: container, navbar, nav, etc.. Sometimes I use these keywords for some of my projects. But for some other projects I don't need any feature of these keywords but I need the names. Is there any way to disable these keywords without overwriting them?
These keywords are important because these are what we call good practice. I don't like using menu or navigation-bar instead of navbar. So, is there any way to disable css of these keywords?
Thank you.
This is one of the downfalls of using a framework, and you have to ask yourself at one point whether it's worth your time building your own boilerplate for projects.
As for your question, I don't believe there's a "safe" way to do that with the vanilla css file, but if you have ruby installed and you download the SASS version you may be able to remove some of the other stuff you don't need by selectively commenting out components in _bootstrap.scss:
#import "bootstrap/component-animations";
#import "bootstrap/dropdowns";
#import "bootstrap/button-groups";
#import "bootstrap/input-groups";
// #import "bootstrap/navs";
#import "bootstrap/navbar";
#import "bootstrap/breadcrumbs";
#import "bootstrap/pagination";
#import "bootstrap/pager";
Related
I've discovered that #import has performance implications. However all of my sass files #import a global-constants.scss at the top of the file to reuse several variables for colour and other properties, so that I can change the main colour etc from one place.
Is there a more performant way to reuse variables in sass?
EDIT: upon pondering this further, I notice that my css file that is generated from my sass file after compilation, has no import statement, and all of the variables are rendered as proper css values. So I'm probably not going to get any performance issues anyway, is my guess.
When you are using #import inside the SCSS, it will try to include the whole file and send it to the browser, (it is better, if you have configured it to return only one single CSS file or minified). That way, it is clean and better:
No #import in the output.
Source code is split using #import, keeping the modularity.
Summary: No performance issues because of #import.
I am developing a new template for joomla and decided to use the Gantry framework. The mai problem of using it, is that i don't really understand the css/less structure. I need to understand it so i can make it more dry and easy to maintain. I find different overrides in difeerent css/less files. I don't really understand the logic. Can someone explain me how the css/less is structured?
Here is the global less file:(hope this gives an ideea about the structure)
#import "jui/less/mixins.less";
// Core variables and mixins
#import "variables.less";
#import "mixins/index.less";
// Core and Grid
#import "gantry-core.less";
#import "joomla-core.less";
// Template core styling and layout
#import "template.less";
#import "style.less";
#import "header-#{headerstyle}.less";
#import "jui/less/font-awesome/font-awesome.less";
#import "utilities.less";
#import "prettify.less";
#import "offline.less";
#import "error.less";
#import "jui/less/bootstrap-overrides.less";
Thanks.
It's a mess, I agree. It's clearly not been authored with end-users in mind, and it certainly isn't DRY. In my experience Gantry's LESS is very badly written, demonstrating a fundamental lack of understanding about how to use pre-processors responsibly or efficiently and creating some horrible outputs in the process.
If you want lightweight and maintainable LESS you'd be better writing it yourself, from scratch.
Last template I built with Gantry I disabled their LESS compiler, removed their LESS files and dropped in my own Sass framework instead.
The line #import "header-#{headerstyle}.less"; gives us a clue that from global.less you are able to load different themes depending on user selection in backend.
Basically you can follow the files inheritance by seeing what is being imported by each file.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Difference between #import and link in CSS
I've read about CSS #import as a bad practice, and was wondering about the methods I'm using.
I'm currently building a website using WordPress, which imports each plugin's stylesheets by link references, and the main stylesheet is linked in the same manner, however, the main stylesheet currently contains several #import declarations, which I believe I should be moving into the header or into the appropriate pages that they're used in (having two of them are only used on certain pages).
Are my concerns justified, and what are the implications of using those #import declarations?
The web provides a lot of information about this topic, I suggest reading:
http://www.stevesouders.com/blog/2009/04/09/dont-use-import/
#import vs link
#import or <link> for importing stylesheets?
I think you should use LINK for simplicity—you have to remember to put #import at the top of the style block or else it won’t work. It turns out that avoiding #import is better for performance.
link
Linking is the first method for including an external style sheet on your Web pages. It is intended to link together your Web page with your style sheet.
import
Importing allows you to import one style sheet into another. This is slightly different than the link scenario, because you can import style sheets inside a linked style sheet.
The most common reason given for using #import instead is because older browsers didn't recognize #import, so you could hide styles from them.
This link will solve your all queries
What's the Difference Between #import and link for CSS?
Using the import rule is not bad practice in itself. You just have to keep in mind that imports are only handled after the file including them has been downloaded. So if you have a bunch of files with these statements it can take rather long for your audience to see the css applied.
Each #import statement creates a new http request since it happens client side. So from this perspective you are hurting visitors with slow connections like mobile visitors on Edge or 3G.
A rule of thumb I hear a lot is to merge all CSS that you need instantly and only use #import for things you need later on.
It is best to NOT use #import to include CSS in a page for speed reasons.
importing allows you to import one style sheet into another. This is slightly different than the link scenario, because you can import style sheets inside a linked style sheet. Older browsers didn't recognize #import, so you could hide styles from them, It is the reason for #import.
check this:
http://www.stevesouders.com/blog/2009/04/09/dont-use-import/
css #import
I recently came across a use of the #import rule on Coda.com. They're actually using to import the main style sheet for the site, specifically the format:
<style type="text/css" media="screen">
#import url(./coda.css);
</style>
Which will hide the rules from Netscape 3 and IE 3 and 4. Since a web development tools primary audience will be using modern browsers, what other reasons would there be to use this rather then a link?
None. Using a <link> element also has the advantage of getting rid of the FOUC.
EDIT: Using #import in another stylesheet (.css file) can be used like an #include in C, but there isn't any reason to use #import in a <style> block.
For Coda's site, I'd imagine they did that more out of force of habit rather than any pressing technical need.
#import statements inside of actual CSS files (not in a <style> element in HTML) serve many purposes, such as making it easy to swap in and out other CSS files. The Blueprint CSS framework does this to let you easily remove certain portions of the framework such as the typography stuff or the grid stuff.
Of course, in a production environment, using a bunch of #import statements is frowned down upon because it increases the number of files a web browser has to pull down.
The only reason to use this rule today is to make your CSS more modular by splitting it into different files, like libraries.
So, while your page might link to one stylesheet, that stylesheet can #import other stylesheets for reset, typography, etc.
However, this does slow the loading of your page since it's just more sequential http requests.
I agree with Andrew. I also use imports to split out my css logically. Personally I like to split them out in 4: reset, structure, typography, general (bgs/borders etc)
Depending on the person doing it, their style and preference, css files can also be split out by page section eg header.css, footer.css etc.
One extra thing I do however to avoid the multiple http requests is have a build process which merges (in order of import) and compresses the css files for live deployment.
Hope this helps
I use a modular development approach myself, and often end up with 10+ individual CSS files. As you know, that's a pretty drastic number of HTTP requests, so I like to use Blender.
Blender is a rubygem that consolidates and minifies any number of CSS files into a single stylesheet. It also works for JavaScript.
You can define #media in your individual stylesheets to only serve the appropriate rules to the correct device types.
Can someone explain what are the benefits of using the #import syntax comparing to just including css using the standard link method?
As the answerer said, it lets you split your CSS into multiple files whilst only linking to one in the browser.
That said, it's still wasteful to have multiple CSS files downloading on high-traffic websites. Our build script actually "compiles" our CSS when building in release mode by doing the following:
All CSS files are minified (extra whitespace and comments removed)
We have a "core.css" file that's just a list of #import statements; during compilation, each of these is replaced by the minified CSS of that file
Thus we end up with a single, minified CSS file in production, whilst in development mode we have the separate files to make debugging easier.
If you use <link>s in your HTML files, all those files have to keep track of all the CSS files. This obviously makes changes and additions (both for CSS and HTML files) harder.
Using #import, you reduce a theoretically infinite number of changes down to one.
#import allows you have an extensible styesheet without having to change the html. You can link once to your main sheet and then if you want to add or remove additional sheets your html doesn't change.
Also, more smaller files help the browser do better caching. If you make a change in one part of a large sheet, the entire sheet must be downloaded again for every user. If the styles are separated into logical areas among a few sheets, only the file containing the part that changed needs to be downloaded. Of course, this comes at the cost of additional http requests.
One other handy bit, although pretty outdated, is that Netscape 4 couldn't handle #import, so it is a good way of serving a stylesheet to NS4, then having another stylesheet for more modern browsers that was imported in a standards compliant way.
#import is CSS code. <link> is HTML code. So, if you want to include stylesheets in other stylesheets (or if you can’t change HTML), #import is the way to go.
According to the CSS spec, all #import declarations must appear before any style rules in your stylesheet. In other words, all at the top of your stylesheet
Any #import declarations that appear after style rules should be ignored. Internet Explorer has never respected this; I believe other browsers do. This makes #import a bit less useful, because rules in a stylesheet that’s imported will be overriden by rules of equal specificity in the importing stylesheet.
It allows you to keep your logic CSS file spread over multiple physical files. Helps in team development, for example. Also useful when you have a lot of CSS files that you want to separate by functional areas (one for grids, one for lists, etc), let have accessible in the same logical file.
Say you work for Massive Dynamics, Corp.. It has a Widgets division. The Widgets division has an Accounts department. Accounts is divided into Accounts Payable and Accounts Receivable.
Using #include, you start the website with one top-level global.css stylesheet, which applies to everything.
Then you create a second stylesheet, widgets.css for the Widgets division. It #includes the global one, and its own styles (which can over-ride the global styles if needed, because of the Cascade). Then you create a third accounts.css for Accounts. It #includes widgets.css, which means it also includes global.css. Lather, rinse, repeat.