Not sure how to really categorize this question, but on this page, the file http://d1el287zd12c0j.cloudfront.net/assets/hitgrid-0a8239a14fba0de87431c06cd75774f3.css seems to be completely ignored by browsers. It appears to load successfully and no different than any other css file on the page, but the styles in it are simply not applied to the page.
The content-type, encoding and everything appears to be working as expected. Roughly the same content "applies" fine on my local installation of the app.
I'm at a loss as to what's going on here.
I just check it out and everything went right.
Try to make the filename shorter in the CDN. Large names tend to make error in some way or maybe check if no other stylesheet is interfering with the styles
If that didn't work, answer these questions and Ill try to git it a try again
Which OS are you using?
2. Are you using wordpress?
Related
I'm having a problem with a site that I just made live - I had to correct some CSS issues related to the background and some image placements. Everything of course looks great in VS Code. I open it in Chrome and Firefox and they look completely different - and wrong. Developer tools showed they were using the old CSS stylesheet (which was originally loaded, then replaced). If I open an incognito window, all is perfect. Any reason this would be? I'm new to this (changing careers) so I appreciate your insight!
This is most probably because the css file is cached in your browser. To fix this problem, you can use cache buster in the URL. For ex, your CSS URL is
https://www.abc.xyz/static/css/core.css
So, whenever you make changes in the CSS file, change the URL to this
https://www.abc.xyz/static/css/core.css?version=1.0.1
?version=1.0.1 changes the file URL and hence it is not loaded from cache. Just change the version number when you make the changes to the file so the URL is new again
It looks as though LESS debugging has come a decent distance since even a year ago, and I was wondering how many people have experience with debugging using developer tools in Chrome/Canary.
I'm trying to ensure that when I'm debugging a file, the element's CSS shows up as the LESS file, rather than the CSS file. It's of little use to have CSS line numbers show up, when I need to know the requisite line number of the LESS file. I can do this in firefox with firebug and fireless, but it's not working in chrome
I tried to follow the steps here, however it doesn't appear to be functioning for me correctly even after following the instructions carefully.
I'm running OSX, have LESS installed via node.js, and am using the ST2 plugin Less2CSS in order to process the less file on save. Using the command lessc --line-numbers=mediaquery style.less style.css works as expected and writes this to the top of my css file #media -sass-debug-info{filename{font-family:file\:\/\/\/Applications\/XAMPP\/xamppfiles\/htdocs\/sandbox\/lessDebug\/style\.less}line{font-family:\000035}}, however when inspecting an element, it's still only catching the CSS file, and not the LESS file.
I have the requisite Chrome preferences turned on (Support for SASS and Enable Source Maps)
Thoughts?
This is now working perfectly fine with less.js 1.5b4 and Chrome 30.0.1599.69
Basically, you need to make sure lessc generates valid source map url at the end of your css file:
/*# sourceMappingURL=/templates/lwks/css/template.css.map */
and that the .css.map file is being loaded by the browser. If this is still for some reason not working for you, in check chrome://flags Enable Developer Tools experiments is on
more details here: https://github.com/less/less.js/issues/1050
Blog post author here...I've gone back and updated my post so it now works with regular Chrome 26. Just checked in Canary and it doesn't seem to work anymore. So Chrome 24 - 26 are good but Canary is busted.
I think that the issues that you refer are not related.
As far as I understand you compile your LESS file on the server side and all you want to do is to retrieve the new css file and not the cached one? Am I right?
Did you tried disable cache on google chrome?
A copy of my code is here
http://pastebin.com/jcLRCrQr
Everything loads fine and the CCS sheets resolve, the javascript\coffescript files load and work correctly, however the styles fail to apply
a wierd thing is when i access the css files directly i.e /lib/css/bootstrap.css
they do not come out formatted, infact its as if all the whitespace has been stripped out.
I have tried this in firefox and chromium and get the same issue.
any help would be greatly appreciated.
Ok i figured it out , thanks to all that had a go.
the content type had to be set on the response for each .css file
i.e res.contentType "css"
We've reached the end of our tether here trying to overcome a nasty and intermittent FOUC in Firefox 3.5.x+ for a new release we're working on.
We've tried:
Disabling Javascript in FF
Using Quirks mode rendering by removing the DOCTYPE
Moving from #import for additional CSS to <link>
Switching concatenation on and off
Removing CSS files from the concat, one at a time
Switching the local cache off in Firefox
etc
Our previous release never exhibited any FOUC issues, so it's something we've done to this release. Changes we've made so far include:
Using Base64 encoded images over Data URIs for all decorative imagery, served via CSS.
Separating 'framework'-related CSS files from page-specific CSS and bundling them as two separate CSS files
To recreate the problem... use Firefox 3.5.x or 3.6.x, then:
Head on over to: http://my.publisher-subdomain.env.yola.net/
Login with username: 'stack#yola.com' and password: 'stackoverflow'
Once logged-in, you should be at http://my.publisher-subdomain.env.yola.net/sites/
Click the Account link in the main nav.
The Account page should load, and you should see a FOUC. If the FOUC does not occur, clear your cache and reload the page.
Your help would be greatly appreciated! :)
UPDATE:
The dev environment is still exhibiting the FOUC, but only if FireFox is running low on memory or has a lot of extensions installed. Latency and rendering speed definitely affect the visibility of this FOUC.
Although this is a very old question, I found it when I was searching for a solution to the same problem. So, I wanted to post the solution for future reference. I just needed to move the reference to my CSS files above the references to external Javascript that needed to be in my header.
I can be wrong, but this could be a concurrent connections issue. According to my Firebug's "Net" tab
the HTML page simply takes a lot of time to load - maybe also because it is on a development server? - and the style sheet gets loaded after the HTML page.
I can't claim to entirely understand what's happening here, but I would try putting the style sheet onto a different domain as a first measure. That should make Firefox establish a connection straight away.
It would probably also be a good idea to go back to normal images instead of data: URIs - that would reduce the size of the style sheet, and data: URIs won't work at all in IE < 8.
We have a lot of elements on the project I am working on that use ellipsis styles, which, of course, work fine with pure CSS in all major browsers but FireFox. We implemented the -moz-binding fix for that which references the xml file with the binding information for cropping an element defined with XUL/XBL as defined here and it worked great... Until we decided to move all our static files (CSS, images, etc) to performance optimized servers. The -moz-bindings no longer worked because FF has disabled XUL from working cross-domain as a security precaution.
I found a lot of references online about putting the binding xml directly into the url clause of the -moz-binding like this:
-moz-binding: url(data:text/xml;charset=utf-8,%3C%3Fxml%20version%3D%221.0%22%3F%3E%3Cbindings%20xmlns%3D%22http%3A//www.mozilla.org/xbl%22%20xmlns%3Axbl%3D%22http%3A//www.mozilla.org/xbl%22%20xmlns%3Axul%3D%22http%3A//www.mozilla.org/keymaster/gatekeeper/there.is.only.xul%22%3E%09%3Cbinding%20id%3D%22ellipsis%22%3E%3Ccontent%3E%3Cxul%3Adescription%20crop%3D%22end%22%20xbl%3Ainherits%3D%22value%3Dxbl%3Atext%22%3E%3Cchildren/%3E%3C/xul%3Adescription%3E%3C/content%3E%3C/binding%3E%3C/bindings%3E);
But that didn't work... the binding just fails and the element does not display at all in the browser. No error (that I can figure out how to capture at least) is thrown and so I can't diagnose what's going on.
I thought maybe it was just the way I encoded the xml but even trying the sample on the Mozilla documentation or this other sample doesn't work for me. I have tried simple html pages with nothing but an element with the Mozilla example and it fails. What is it I am missing configuration-wise to make this inline stuff work?
I am either looking for 1) a way to make the inline -moz-binding work or 2) a way to resolve it so that the external xml file works when the CSS is coming from another domain.
If anyone has advice it is much appreciated!
By the way, I'm not interested in any other solutions in applying ellipsis to fields (such as Javascript implmentations). This works fine for our purposes and is used too many places in the site as a CSS class to make a refactoring for another approach feasible.
You could try that adding in your .htaccess:
Header set Access-Control-Allow-Origin *
source