I built this e-commerce site for a client using ReactJS and deploying via Netlify automatic github deploys. I'm getting very strange results in Firefox and Safari (Big Sur and before). This error appears in the Safari console:
Did not parse stylesheet at 'https://panthercityleather.com/src/index.css' because non CSS MIME types are not allowed in strict mode.
I'm assuming this is what is causing the layout issues? I tried to add type=text/css to all links and style tags but the command npm run build seems to remove these attributes from the tags.
I then locally ran npm run build (as opposed to letting Netlify automatically build), edited the build css to contain the correct MIME types, added autoprefixing to all of the css, and manually deployed this build folder to Netlify. Then I got a different error in regard to the index.css file:
Failed to load resource: the server responded with a status of 404 ()
I am completely lost at this point and would really appreciate any help. The layout issues only seem to arise on desktop Safari and Firefox and the issues are different in each browser. Here is an example from the home page:
Featured items on Chrome. Everything looks correct.
Featured items on Firefox. Note that the spacing between the headings and the images is too tight but the images are cropped correctly.
Featured items on Safari. Note how the images are now cropped wrong but the spacing is correct.
Maybe try adding type="text/css" to every link or style tag.
<link rel="stylesheet" href="css/style.css" type="text/css" />
<style type="text/css" > ... </style>
Turns out I had 2 issues:
I was linking index.css inside of index.html but with a React app this is not necessary. I simply need to import each css file into the react file that references it. This solved the error that I initially posted the question about but did not fix the weird styling behavior on other browsers.
My main issue was that my css was simply not supported on older browser versions. Specifically, aspect-ratio and gap did not have good support. I used the padding-top hack to provide a fallback for aspect-ratio. I simply removed all gap in my css because on Safari v14, the browser apparently supports gap but none of the styles were being applied. I've spent all day scouring the internet so I simply replaced all gap with something like this:
& > * + * {
margin-left: 1rem;
}
This applies a 1rem margin on all but the first element in a flex row. Change to margin-top for a flex column.
Related
I just added Helmet to my Node/Express/EJS project and have been configuring my CSP to enable inline scripts, styles and some external sources. I have it working fine on my Windows laptop in Opera, Chrome & Edge and now I'm connecting on iOS Safari mobile and it appears that no styles are being applied. I am successfully getting Bootstrap (JS for sure, I think the CSS too although it's not 100% clear and I have no console on mobile) but my own stylesheets and scripts are not being loaded correctly.
Here's my code:
app.use(
helmet({
contentSecurityPolicy: {
directives: {
scriptSrc: ["'self'", "'unsafe-inline'", "'unsafe-eval'", "*.googleapis.com", "*.jsdelivr.net", "*.jquery.com"],
styleSrc: ["'self'", "'unsafe-inline'", "'unsafe-eval'", "*.googleapis.com", "*.jsdelivr.net", "*.jquery.com"],
baseUri: ["'self'"],
fontSrc: ["'self'", "https://fonts.gstatic.com"]
}
}
})
)
I also notice that whenever I visit a link on my site on iOS Safari it automatically forces HTTPS when I'm only using HTTP on a localhost server. I have a feeling that this may be the cause of the problem - my stylesheets are referenced as
<link rel="stylesheet" href="/style.css" />
I think Safari may be trying to find it at https://(laptop-private-ip):3000/style.css when it really should be searching http://(laptop-private-ip):3000/style.css. Is it possible that it's trying the HTTPS link which is why I can't retrieve my own styles, but can access Bootstrap etc?
And what should I do about it? Any help massively appreciated - I've wasted hours on this.
Issue fixed. I am not 100% confident which was the problem due to cache seemingly playing a part but I believe it was one of the following.
Upgrade-Insecure-Requests
HSTS
We are using revolution slider for the slideshow on the home page. The links to buy tickets works in firefox, but the links are not clickable in chrome.
https://havenac.com
I turned off all plugins and turned them on one by one to test for a plugin conflict. As far as I can tell there is not a plugin conflict.
I created a blank page template here and hard coded the wp-head.php to test for css or javascript conflicts by removing each script one by one. What I found is that when I remove the style.css for the theme, that the links in the slider begin to work. So I am assuming there is something in that file conflicting with the revolution slider code. Here is that test page:
https://havenac.com/dj-battle/
I cannot tell what part of the css is causing the conflict. I am thinking maybe it is z levels or fancybox css. Or maybe chrome is rendering the css differently somehow.
Here is the line of code I am removing from the wp-head.php that is making it work.
<link rel='stylesheet' id='base-style-css' href='https://havenac.com/wp-content/themes/havennightclubgo/style.css' type='text/css' media='all' />
Anyone have any ideas/suggestions?
One of the many div layers under .tp-parallax-wrap, specifically .tp-caption slidelink has an inline style of max-height: 1px. I believe this is what causes the problem. I added a test class in the browser inspector with a max-height: 100% !important which fixed the issue.
I wouldn't use the !important style that I used. But the div that causes your problem has 1px height, which gives the inner a tag a 1px height as well. Try this out and see if this fixes your issue!
Chrome version: 44
When working in my normal development environment (C#, IIS Express) css files downloaded by the browser are available in the sources tab and I can see what styles come from what files in the element inspector. However, in my current development environment (PHP, Apache, Xammp). The stylesheets are being downloaded and rendered as style tags and are not available in the sources tab. This is rather annoying as I can't save locally edited styles to my working copy. I've never seen this before and can't seem to find any answers with a quick google. Does anyone know what would cause dev tools to render this way? I feel like it must be some sort of server configuration issue but I can't be sure. Example below:
<link href="css/bootstrap.css" type="text/css" rel="stylesheet"/>
is rendered as:
And looks like so in the element inspector:
Any help greatly appreciated!
I just met the same issue. Not sure if my case can fix your problem, but I found out that I had a script 'prefixfree' requesting redundant css files at loading. So I just commented this line out and my style in Element Inspector just back to normal.
<script src="~/Scripts/prefixfree-1.0.7.js"></script>
In my case, the problem appeared to be caused by a bad/malformed CSS style that was being applied to the target element. I'm able access the element's style normally after removing this style:
background: -webkit-gradient(linear,0% 0%, 0% 100%, from(#2521BC), to(#1C1957), color-stop(.5,#3A33E7));
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'm using jQuery's .css() method to set the background image of a div. The HTML in its final state is thus:
<div id="front-page-bg" style="background-image: url(http://peterfcarlson.com/wp-content/uploads/2011/09/ert-011.jpg); display: block; "></div>
It works fine, however, I'm getting an error/warning in Chrome, where the background-image property is struck through as though it's being ignored due to bad input, even though it is obviously being applied. Why would this be? Is it a problem with Chrome, or on my end?
I've tested the page in FF and IE, where it also seems to work without any errors or similar warnings. Any ideas about why this might be happening, and perhaps more importantly, should I ignore it, since the page seems to be working?
EDIT:
By inspecting more deeply (ignoring the first misleading 404 problem with image), seems that developer tools is ignoring the style definition; infact it applies a
not-parsed-ok class which appends the warning icon, and an overloaded class which causes the line-through.
The overloaded class is not appended if using background in place of background-image css definition.
But to discover the reasons of this behaviour would be necessary to analyze the developer tools source code.
My guess is that is a developer tools bug/incomplete feature.
This is my own test:
as you can see the image used is local, and have apix. And this is the resulting inspection:
Testing with a non existent css property, it shows the identical behaviour:
Your referenced image has some strange web server issues:
infact it is returning a 404 error (maybe timeout?), then a redirect.
So you should check the image and the web server path, not your actual html code.
Even trying to put in actual html code, the error is the same:
This is the actual response of your web server, instead of your image:
<!DOCTYPE html>
<html>
<head>
<style type="text/css">
html,body{height:100%;width:100%;margin:0;padding:0;}
body{overflow:hidden;background:#EDEDED url(http://peterfcarlson.com/wp-content/themes/comingsoon/pfc.png) center center no-repeat}
</style>
</head>
<body>
</body>
</html>
The problem is the DevTools/WebInspector bug.
DevTools UI code just shows the data not always correctly generated by the back-end part of DevTools.
WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=70325
Chromium bug: http://code.google.com/p/chromium/issues/detail?id=100646
#IsaacLubow; Both Chrome & Safari developer tool show that warning error. Then question is
Why they show a warning ?
Answer:- Both Chrome & Safari developer tool show warning when the property is not understand & recognized by them.
for example:- write -moz-border-radius in the css. Then check the page in chrome or safari. It's shows the same error which you have.
Then the second raised question is
But background-image property is recognized by all browsers !
Answer :- Yes; background-image property is recognized by all browsers & the image is still shows in the website but the way we define the image is cause for that warning/error. In your example if you define background-image property inside the html tag instead of css. It's shows the warning/error.
Check this example the first div images show an warning but second div is not show any warning:
http://jsfiddle.net/sandeep/RDmRz/3/show
So; why that's happen ?
Because assigning attributes in html tag is a Deprecated method means
Those deprecated features can still be used, but should be used with
caution because they are expected to be removed entirely sometime in
the future. You should work to remove their use from your code.
Check what mozilla said about that https://developer.mozilla.org/en/JavaScript/Reference/Deprecated_Features
https://developer.mozilla.org/en/DOM/HTMLImageElement
So; Developer tool are updated as per the new html standards & after introducing HTML4 some properties deprecated & outdated.
Check this for more http://fantasai.tripod.com/qref/HTML4/deprecated.html
http://www.createafreewebsite.net/html_tutorial/body_tag.html.
It's good to write background-image in css instead of html tag.
http://peterfcarlson.com/wp-content/uploads/2011/09/ert-011.jpg
Your image is not coming up, instead we are getting a 404 error. I noticed that you are using a wordpress site from the structure of your image url, what we might be looking at is not your image but the image included inside your 404.php page inside your theme.
The html that is returned is the following:
<!DOCTYPE html>
<html>
<head>
<style type="text/css">
html,body{height:100%;width:100%;margin:0;padding:0;}
body{overflow:hidden;background:#EDEDED url(http://peterfcarlson.com/wp-content/themes/comingsoon/pfc.png) center center no-repeat}
</style>
</head>
<body>
</body>
</html>
And this is the image being loaded instead: http://peterfcarlson.com/wp-content/themes/comingsoon/pfc.png
I'm quite sure that if you check your 404.php page from your theme that is what you will find. So you might want to re-upload the image and use the new url.
Comment
I know the question was answered but wanted to chime in with my results as to what i found. I noticed that, for some reason, when you specify a background-image to an element it sometimes drops a warning in a webkit browser, which is the issue that the OP was having. But i noticed that the warning disappears when the background shorthand is used instead.
Like so:
background:#ffffff url('image.png') repeat scroll right top;
I modified #sandeep's demo to show how it works:
Here is the full fiddle: http://jsfiddle.net/RDmRz/7/
And demo page: http://jsfiddle.net/RDmRz/7/show/
Check the page with the developers tools and switch between the divs to show how it is working for the "works" images and not working for the others.
A couple of screenshots:
Works
Doesn't Work