One of the sites I am developing is loading an external stylesheet:
#import url(http://www.othersite.com/stylesheet.css);
This works in every single browser properly, except for Safari. Safari does not even try to load it. What am I doing wrong?
Could it have to do with this old bug: http://www.thinkoomph.com/thinking/2011-04/odd-css-bug-in-webkit-and-safari-4/ ?
The solution is simple. My #import directive was surrounded by other
CSS instructions. Whereas IE tolerates this, the actual W3C spec
declares that #import directives should appear before any other CSS
instructions, and Firefox honors this restriction. Thus, my #import
directive was being ignored. I moved it to the top of the file and
everything started working.
and
At most one #charset rule may appear in an external style sheet — it
must not appear in an embedded style sheet — and it must appear at the
very start of the document, not preceded by any characters.
<link rel="stylesheet" type="text/css" href="http://www.othersite.com/stylesheet.css" />
I stumbled upon the solution while reading an article that details the pros and cons of using #import vs. tag. I tried using a tag instead of #import, and for whatever reason this solved my issue. Safari will now load the stylesheet. If anyone has any insight into why this works please comment :)
Related
I'm having an issue with FontAwesome (v4) webfont icon rendering in Chrome when Chrome's caching is enabled. Intermittently, across multiple user machines, a page will load with our FontAwesome icons displayed incorrectly as below. This issue happens only occasionally and can't be reliably reproduced or narrowed down to a single page. The only common repro steps are using Chrome and not having "disable cache" enabled in dev tools or elsewhere.
Checking dev tools computed styles for the icon elements reveals that Chrome is correctly detecting the specified font-family as "FontAwesome", but the <i> tags for the icons are being rendered in Times New Roman, rather than the FontAwesome webfont. The "FontAwesome" #font-face declaration and the above rule assigning font-family: FontAwesome to the .fa class exist in the same stylesheet, site.css, which is causing the issues.
Checking the source below, we see that site.css is properly specified in the site's <head> tag. It isn't being added to the <head> through JavaScript; it's present in the in the initial page loaded by the browser. The href points to the correct stylesheet, which loads without issue when opened in a new tab. This isn't very surprising, since all of the styles specified in site.css are correctly being applied to the page (except for the webfont, of course). Even the .fa's font-family rule is being read correctly by Chrome, as shown in the computed styles in the screenshot above.
My suspicion is that Chrome is loading the stylesheet from cache in a weird way that's allowing all of the styles to load but is interfering with the creation of the FontAwesome webfont. Potential evidence for this below:
Above is a portion of the network tab from the dev tools session. Nothing has been filtered out, but site.css has no entry in the list of requests, even though other cached stylesheets are present and the styles from site.css are being applied to the page. There are entries for theme.css, jQuery, AdminLTE, and other stylesheets specified just after site.css in the same <head> block. It's not pictured, but the fontawesome.woff2 webfont file, specified in site.css's #font-face declaration for "FontAwesome", is also being successfully loaded.
Refreshing the page or navigating to another one sometimes fixes the issue. Refreshing with cache disabled always fixes the issue. Every page of our (quite large) web app loads this stylesheet using the same <link> tag, and while this issue pops up fairly rarely, it has happened across many of those pages. The site.css stylesheet is clearly being loaded by Chrome, as it sees the font-family: FontAwesome rule along with the rest of our site styles. But something seems to be happening during the loading of the stylesheet from cache that's causing Chrome to fall back to Times New Roman despite the webfont being both declared via #font-face and specified as the font-family for the affected elements.
We aren't using a service worker or any server-side caching. We do some cachebusting via a GET parameter as shown in the screenshots above (the ?[productName]Version=2.0.13292.0), that value is baked into the initial document loaded by ASP.NET and changes only when our backend server's version changes -- so that shouldn't be the cause of the issue here.
Has anyone experienced anything similar with Chrome webfonts?
I had the same problem. My compiled CSS file was missing #charset "UTF-8"; and as a result, the cached icons font was broken. Please check if this helps you.
Actually we have one global.css style sheet in which we are using #import url("http://fonts.net/sample.css?type=cssandid=123") for fonts.
But it's creating issues in Bundling & minification so I got following solutions:
http://www.stevesouders.com/blog/2009/04/09/dont-use-import/
and I replace #import with element
<link rel='stylesheet' type='text/css' href='http://fonts.net/sample.css?type=cssandid=123'>
even after this I'm getting CSS errors as I checked in CSS Lint(http://csslint.net/) and not getting real UI effect as with #import.
Do we have any other solutions for this?
Environment: VS2015 , MVC 5.2 , sitecore 8.1
Thanks
Hope you found the solution since you posted this question
What you can do, to avoid the #import url('yourCssUrlHere') is simply copy/paste the URL on your browser and then copy/past the CSS that is displayed.
And then simply replace the #import by the CSS you just copied.
Most of the time if the import is a font, there will be other references to .woff or .woff2 files.
Just download them and store those files somewhere on your project folder and just add their absolute link on all the url() fields.
That way, you use external fonts or stylesheets, but internally, without request them outside of your website.
I'm using brackets.io for web dev.
The page looks great in the live preview, but when I just open the file from chrome by "file:///localurl/index.html" The page is not styled at all.
I'm using this in the <head>:
<link href="css/mystyles.css" rel="stylesheet">
Using "inspect element" on the page opened in chrome, it seems no stylesheet is applied. (There is also a bootsrapt CSS included, which I omitted for simplicity, but that one is not applied in chrome as well)
What am I doing wrong? The stylesheets are in the css subfolders.
Solved it, should have used ./css/mystyles.css and not css/mystyles.css
After upgrading to the release version of Divshot, I've noticed that CSS #import rules aren't being loaded in the preview panel.
For example:
#import url("http://netdna.bootstrapcdn.com/font-awesome/3.1.1/css/font-awesome.min.css");
#import url("styles.css");
does nothing.
I have tried different syntax and it didn't seem to help. I can put them in the head of the HTML page instead of calling them in a CSS file, but that only works for straight CSS. Font Awesome and Google font libraries rely on #import rules to work.
Any help would be appreciated.
Because Divshot runs everything secured via SSL, you will need to use the https versions of any CSS imports, or use // to make it work both ways.
I'm using Paul Irish's HTML5 Boiler Plate.
The homepage renders fine on Chrome, Firefox, and IE8 (apart from the shadows / rounded corners - which is not of concern right now)
The margins, nav list are messed up in IE8.
It is linking to the CSS correctly, because the styles for the elements in the header come from the same file, but the positioning, and the nav list don't get their styles?
This is weird, because if there were issues in the CSS, wouldn't it render incorrectly in the root directory as well?
The script tag you're using to load Modernizr is using a relative URL, so it will only work at your domain's root:
<script src="js/libs/modernizr-1.7.min.js"></script>
Replacing it with a root-relative URL should fix this.
<script src="/js/libs/modernizr-1.7.min.js"></script>
Another tag has the same problem, but it's commented out, so it's not the cause of your rendering issues:
<!-- Uncomment if you are specifically targeting less enabled mobile browsersdo w
<link rel="stylesheet" media="handheld" href="css/handheld.css?v=2"> -->