On this site http://gaeilge2013.ie/ some stylesheets are not loading in IE9. In Chrome / Firefox / Opera / Safari it's all good. Very strange.
This is the css which is not applying:
<link rel='stylesheet' id='dzs.timelineslider-css' href='http://gaeilge2013.ie/wp-content/plugins/dzs-timelineslider/timelineslider/timelineslider.css?ver=3.5.1' type='text/css' media='all' />
Link is good. ...
Thanks!
The problem you have is due to a limit that IE imposes on the number of stylesheets. IE can only load a maximum of 31 separate CSS files in a single page.
There are plenty of references for this one the web, but here's one from MSDN
This is a hard limit in IE. It is possible to load more CSS files than that by using specific techniques: if you use #import to load CSS files from inside others, it is possible to import up to 31 files for each of the 31 main CSS files. But it's not an ideal solution.
In general, it's better to reduce the number of files if possible -- each file that loads is a separate HTTP request, and having large numbers of requests can have a significant impact on page load performance.
My suggestion would be to try to combine the large number of CSS files you have into fewer files. This shouldn't be a difficult task, but there may be WP plugins you could use that would do this for you automatically if necessary.
You can use Modernizr for fixing this issue. It is a powerful crossbrowser javascript plugin that fixes all those special cases as for the multiple IE versions as for the rest of the browsers.
I leave you the link here so you can take a look:
http://modernizr.com/docs/#installing
Related
what happens to them? are they loaded by the browsers?
should I split my CSS files into more stylesheets, so only images the css/images that are used are loaded on the page?
Seeing as people are saying the same thing I said in my comment I guess I should have added it as an answer.
I was going to recommend firebug, but I believe the images are not downloaded until you reference them in the html. You can confirm this using chrome or ie or firebug developer tools. as far as splitting the css, I would only do so if you have an excessively large css file, or you need to split it up for different css files for browser capability i.e. you have styles that are ie7 or ie 8 specific
Browsers will only download images that are actually used on the page. So images that are specified in CSS as background images will not be downloaded unless that CSS rule is applied on the page.
You can use Firebug or other similar programs to see what is loaded by the browser; however, I believe the answer is that since the DOM element is never created, the image is never requested from the server. No bandwidth or loading time is wasted (other than a few more bytes of CSS, but that shouldn't be too much overhead.)
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 I specify a CSS link with an unsupported media type ("bork") it still gets downloaded by every browser I've tried (including both desktop and several mobile browsers).
<link href="bork.css" media="bork" rel="stylesheet" type="text/css" />
And it gets worse...
If the file bork.css #imports an other CSS file (also with an unsupported media type) that second CSS file also gets downloaded.
/* Inside "bork.css" */
#import url("bork2.css") bork, bork;
Why!?
My first assumption was that some browsers might be searching for nested #imports or #media blocks with media types that they supported - and then apply the styling rules contained within those files...
/* Inside "bork2.css" */
#import url("all.css");
#media all {
/* rules */
}
...but as far s I can tell, not a single browser does that. (Fortunately, as that would be a bug.)
So all this downloading seems wholly redundant - unless there's some explanation that I've missed all along.
EDIT: What I'm trying to understand is that motivates browser makers to go:
"Hey! We're trying to make our browser crazy fast! Let's download a bunch of CSS files that we have no intention of applying, and halt the loading of other resources meanwhile!"
I think the answer is this:
Browsers are allowed and encouraged to parse media descriptors - no matter what the descriptor - as a way to make them future friendly
Future versions of HTML may introduce
new values and may allow parameterized
values.
*From: http://www.w3.org/TR/html4/types.html#h-6.13
In this way, media may one day include 3d-glasses or other descriptors, including bork ;-)
EDIT:
The latest CSS3 spec on media queries says this, which supports the above, to a certain degree:
Unknown media
types evaluate to false. Effectively,
they are treated identically to known
media types that do not match the
media type of the device.
*From: http://dev.w3.org/csswg/css3-mediaqueries/#error-handling
So they are treated as known and downloaded to be used, just not at that time/for that device.
Thinking that the real reason that they load all media queries is because many devices CHANGE their responses to these queries after load.
Imaging an iPhone5 that is in portrait on page load (reporting 'width' as 640px, but not 'portrait, unfortunately the iSeries do not support those queries)... you then decide to turn the iPhone sideways, and the browser now activates the pseudo landscape mode (again, triggered from width # 1126 rather than 'landscape').
Most likely, a responsive web design has been designed to feed different stylesheets to a browser displaying at 640 (rather narrow, probably a phone/tablet) than it does to a browser displaying at 1126 (more likely a laptop).
If it hadn't bothered to load the additional media query sheets, then it would suddenly have to stop, shoot an http request out, wait for the sheet to load, and then parse it to display. This could result in a rather ugly delay.
As most browsers follow a pattern of code reuse, and the core chunks of Webkit or Gecko, for example, may not be aware whether they are on a laptop or a tablet (as if those lines aren't beginning to blur anyway), it simply loads each media query regardless of whether or not they choose to display it.
While this saves each browser from looking bad, overall it breaks a good chunk of the utility behind media queries.
A cell phone or a cheap android tablet shouldn't have to download the additional files (especially on limited data plans) that it will simply never need.
At the moment, my designs DO use media queries, but I use them sparingly. Much of the media queryishness on my sites is implemented through javascript loading of required files to eliminate this waste. The remaining queries are used in cases of javascript being shut off, or for sheets that need to be loaded 'just in case' (my 640px layout, for example, is usually always loaded, as most devices might display it in one situation or another).
If anyone out there has a better, cleaner, method of handling this, please let me know.
In the meantime, if you can think of a simply to implement functionality that might circumvent this (maybe android-style manifests built into browsers?), you might want to drop a line to the Mozilla or Chromium teams... seem like they could use a hand on this one.
After thinking about this more, I formed the theory that there might be a general "rule" at work - that any stylesheet, image or script would be downloaded, no questions asked, regardless of the specified mime-type or media attribute.
However, after a quick test, the results are a bit ambigious...
<script src="bork.js" type="bork/bork"></script>
<script src="bork2.js" type="text/bork"></script>
Chrome 12 downloads neither.
IE8 downloads #2.
Firefox 4 downloads both.
Opera 11 downloads both.
Safari 5 Win downlads both.
Still no parsing or running takes place in any of the browsers. A javascript alert(); inside either file does not run. And this is slightly different from the CSS loading case, because there the browsers parse the bork-media CSS code for #include directives and downloads those resources recursively.
The answer may come down to media queries. Consider these for example:
<link rel="stylesheet" media="(min-width: 300px)" href="example1.css" />
<link rel="stylesheet" media="(min-width: 1000px)" href="example2.css" />
If a browser with a window size of 600px is used, the example1.css stylesheet will be applied. If the window is resized to 1200px then the stylesheet example2.css can be immediately applied without waiting for it to download first.
Its worth noting that even though the non-matching media query stylesheet is still downloaded, it does not block rendering while it is downloading (normally all CSS files need to be downloaded before rendering will begin).
Sometimes, it's necessary to consider the prosaic answer. It's possible that all stylesheets are downloaded by browsers simply because the authors of each browser only really consider the case where there is a single (master) stylesheet when optimizing for speed, and the practice of a lot of sites of having a single stylesheet encourages this behavior. If nobody is testing for it, it's almost certainly not a case that's being optimized, as people prefer to work on results that are visible (or at least measurable). Maybe your question will encourage someone to change the testing regime…
Also, I'd venture that the overwhelming majority of sites' stylesheets are static documents, and so capable of being very highly cached (and delivered by CDN too, if the site owners choose to pay).
The only logical reason I can think of is that when you are changing dynamically (javascript) the faulty attribute's value of the <link> element to a recognized one, the file must be available immediately.
In fact in certain cases it could be considered a feature if you wanna load the file but defer its appliance for later.
So if you really do not want to download the CSS file until something happens, the you can try to validate when the page loads if certain conditions are meet and if so, then you can do a "lazy load" and store the commented code (type 8 element, that would be in this case your style tag) inside a newly created style tag child, and that will make the browser to validate the newly created content and will download the CSS file for the style to work.
Any question you may face trying to implement it, do not hesitate in asking some clarification, maybe i can help you with your problem. It works for almost anything (images, js, css, etc..) you do not want to be downloaded or processed until something occurs or some restrictions are meet.
I already tested it and IT WORKS :D, so you can use this code to start, hope it helps
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>TEST CODE</title>
<script type="text/javascript">
function test(){
var elems = document.body.childNodes;
alert(elems);
for (var i = 0, il = elems.length; i < il; i++) {
var el = elems[i];
alert(el.nodeType);
if (el.nodeType == 8) {
var style = document.createElement('style');
style.innerHTML = el.nodeValue;
document.getElementById("css").appendChild(style);
break;
}
}
}
</script >
<style id="css">
</style>
</head>
<body onload="test()">
<!--#import url(red.css) (min-width:400px) and (max-width:599px);-->
</body>
</html>
Is it a good idea to put all conditional CSS rules in one conditional stylesheet instead of making multiple stylesheets for different versions of IE?
Example:
<!--[if IE]>
<link rel="stylesheet" type="text/css" href="all-ie-only.css" />
<![endif]-->
Content of all-ie-only.css:
selector {
color : green\9; /* IE8 and below */
*color : yellow; /* IE7 and below */
_color : orange; /* IE6 */
}
Using IE underscore/asterisk hacks see: http://webstandardstips.com/2008/11/18/css-hacks-for-ie-only-style-rules/
The advantage I see in this technique is that you have just one style sheet in your server which may be easier to maintain.
The disadvantage is that users will need to download the whole file which may be 3 times bigger hence taking more time to download and to process.
Appart from that, I think there's no other issues with it.
Yes, it's fine. I think it becomes a question of how many items the file has to hold. If you're just overriding 1/ 2/ 3 things, the single file makes much more sense. At some arbitrary point (10 things? 100 lines of code), I'd say the trade-off swings the other way and it's simpler to maintain the three files.
What if IE 10 comes along and invalidates some of these hacks? I think this approach defeats the purpose of using IE conditional comments in place of hacks, that being more of a future-proof implementation.
Plus is there any advantage, besides slightly easier maintenance, and negligible HTML file size savings? As LuckyShot mentioned, it's already a detriment for IE users which will have to download a larger browser-specific file.
this is right to use this for all IE Version. but when you use this then you will find that, this is not w3c valid. Generally IE create problem.Safari, Chrome , and Firefox will run these good.I think this is better idea to use one Css for all IE version.
As long as it works and its valid, then it doesn't really matter whether its in 1 file or 3, its just personal preference.
Personally, I prefer to have a seperate sheet for each IE version (if needed), as I find it easier to organise.
Like I said, if its W3C complient (god, don't we just love them), then its all good.
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.