I was hoping to import other css files from withing the Chrome's custom stylesheet C:\Users\*\AppData\Local\Google\Chrome\User Data\Default\User StyleSheets\Custom.css but it doesn't seem to be working. I have a stylish.1misc.css and a stylish.2img.css inside the same dir as above. Also with symlinks I've set them up on my localserver as http://localhost/.my/stylish.2img.css but none of the #import rules seem to be working
#import "stylish.1misc.css";
#import url("stylish.1misc.css");
#import url("http://localhost/.my/stylish.2img.css");
#import url("file:///D:/.localhost/.my/stylish.1misc.css");
Why wont it import?
related
Although I am having the same issue with Chrome as well, but the statement concerning inclusion of local stylesheets in case of every browser with the exception of IE lacks merit. Opera, Firefox, and Safari all allow inclusion of local stylesheets. Safari and Opera even allow users to use stylesheets which are located anywhere on their hard disks. As the process of instructing a web browser to use a local stylesheet requires a local user's involvement, hence the chances of violating the security remain minimal to almost non existent.
As CSS files have to conform to strict rules, hence that probably provides another reason for making it possible for users to choose local CSS files from any directory on the hard disk, as browsers simply stop parsing the file in case it does not conform to predefined rules and standards.
Related
I am compiling several stylesheets into one min stylesheet in a staging environment The styles are applied locally in IE where each stylesheet is separate, but they are not being applied in the staging environment in IE where the stylesheets are compiled into one min stylesheet. I have run the stylesheets through a CSS validator and have gone through each stylesheet and corrected any syntax errors that I found. I don't necessarily need to know how to solve the problem, I mainly want to know where the problem exists. The IE developer tools aren't giving me any feedback related to the problem of styles not being applied.
Here is a link to the login page in the staging environment: https://s-app.joinhere.com/manage/sessions/new. The styles are in the stylesheet, they just aren't being applied in IE. Here's a link to the compiled min stylesheet: https://staging.joinhere.com/assets/manage-d4f70cefc93b170b5f2a04509db697c8.css
Thanks!
I tried your page, and it works fine in Chrome. However it looks weird in IE9, as if the CSS styles are not being applied, just as you described. For example, the style body#manage-sessions #main_container #login_container is not getting applied. I looked at the css tab in the developer tools, and it turns out the style is not even there, which explains how it is not working. To find out why, I used the networks inspector from the developer tool and examined the response when IE9 is downloading the css, and the style body#manage-sessions #main_container #login_container is indeed in the response. This lead me to believe that there must be some limit on the max css file size for IE. It appears that this is indeed the case as described here. Apparently IE simply ignores additional styles if the css file gets past a certain size. So this explains why everything works when the css files are separate, and why things fall apart after you combine them. To solve the problem try splitting up your large css file into 2 or more smaller ones that fall under the IE limit, and see if this corrects the problem.
I'm not sure about your personal setup, however, anything < IE 10 can only handle 32 individual stylesheets, anything after will still show up in the Dev tools like its working but rest assured, the 33 stylesheet is committed to a life of silent failure.
I have a css file that I only want to be visible to Firefox browsers. I thought I was super-smart coming up with
#-moz-document url-prefix() {
#import url("/a-large-css-file.css");
}
...only to find out that #import directives cannot be nested like that.
More details:
The file is heavy, so it's not an option for me to include its
content inline inside the "conditional" as I don't want for it to
affect total request size for other browsers
The file contains a font-face declaration with the font itself
base64-encoded. Why you ask? Firefox does not allow for fonts to be
downloaded from a different subdomain and that's how twe host static
content. There's a nice recap of the issue here and here
If you've looked through the links in the point above, you'd see a
suggestion to add an Access-Control-Allow-Origin http header -
unforunately this is not an option for me given our infrastructure
setup and deployment procedures.
Even more details:
Static content is hosted on a url similar to
resources.environmentN.domain.com while the pages' urls are similar to environmentN.domain.com where N is different across
the environments.
We're have Apache Tomcat running Liferay Portal.
At this stage I'm open to almost any workaround :)
Edit
I probably should have phrased this differently, but I must mention that I'm probably not open to javascript workarounds, the reason for that would be an unstyled content flash even after the resource is successfully cached locally - this would be the case with solutions proposed so far.
My apologies for the confusion!
You should really just bite the bullet and get the server side fixed, since http://dev.w3.org/csswg/css3-fonts/#same-origin-restriction requires the Firefox behavior and the other browsers will update to it at some point.
Detect browser with JavaScript then append stylesheet link if it's FireFox
$('head').append(' <link href="a-large-css-file.css.css" media="screen" rel="stylesheet" type="text/css" />');
If it possible to use #import in a .css file to load a style sheet from another site? Specifically, I have a main style sheet for my site which loads in other (local) style sheets using #import. I'd also like to load in a jquery ui theme hosted by google, e.g.
#import "http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/themes/ui-lightness/jquery-ui.css";
This does not seem to work - I wanted to check whether this is allowed before working out exactly where the problem is.
That should work. Are you sure it is not loaded? What browsers does this happen in? Can you confirm using Firebug?
There is no mention of it not working in the w3 specs nor in the related MSDN Article (The latter applies to IE only of course).
According to those specs, adding url(...) around the address is optional, but try whether that yields better results.
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.