CSS not displaying properly in Sharepoint on Edge Browser (SEC7111 Error) - html

Hopefully I can explain this correctly. I have recently been moved to a Windows 10 VM from Windows 7 and I'm trying to get a site for my team at work to display properly in Edge. I have a WebPart linking to CSS that is displaying everything as one large list instead of a table with dropdowns. When I open the HTML page on its own in Edge it displays fine, but with code in SharePoint it is not working correctly. Any ideas of why this could happen?
What should display
What is displaying in SharePoint
EDIT
After opening developer tools I find that I am receiving a SEC7111 error code on my CSS file that is being linked. Looking other places for solutions to this too, but any help is greatly appreciated!
FINAL EDIT
With the SEC7111 error I found out that the "file://" links I used for the CSS weren't going to work because they weren't considered "secure" (Although I got the same error in IE, but never had this display issue..?) So, I moved my linked CSS file to a secure folder in another SharePoint site I have, linked the CSS from there, and now it's working!

There are some ways that you can use to solve your problem (It's better to share your code within your question to get a better answer). So, I offer you below solutions:
Solution 1
Please don't use file:// for the published site in the webserver. HTML rendered on the client so you cannot access the local files. so you should not use the file://. you can read more about security concerns and more details on the file protocol here: (https://en.wikipedia.org/wiki/File_URI_scheme)
Instead of using local file protocol, you can use the Absolute/Relative path to your CSS on the HTTP/HTTPS protocols
Solution 2
Add X-UA-Compatible meta tag or HTTP response header to force IE to run with legacy document mode: 5, 7, 8.
X-UA-Compatible meta tag:
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=8" />
...
</head>
<body>
</body>
</html>
X-UA-Compatible HTTP response header:

Related

Open Graph share debugger scrapes empty html

I'm trying to set up Open Graph meta tags for a website. When I access the site normally using a browser and inspect the source, the tags are there. However, they don't show up when I use the OG debugger.
The site that I'm developing is here spurafrika-org.vercel.app (Next.js site). It's replacing the original site here: spurafrika.org (WordPress site).
When I use the See exactly what our scraper sees for your URL feature, I get this:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head>
<body><p>ÿþ</p></body>
</html>
See for yourself here. Vastly different from my actual source for my websites.
I originally thought it might have been a Vercel/Next.js issue, but when I discovered it also happening on the WordPress site, I was very confused: see this. I've checked other sites developed with Next.js and WordPress - the meta tags work fine on the debugger.
Another point of confusion is that the debugger tool seems to be able to pick up that on my Next.js site I've listed https://spurafrika.org as its canonical URL, which it can only tell through my og:url tag. Yet when I view what the debugger supposedly sees, it shows the above empty HTML snippet.
I thought perhaps it might have been an encoding or parsing issue, but I've validated my HTML source using several tools and there are no problems.
I'm stumped. Anyone know why this is happening?
I copied your code against a code sandbox - https://developers.facebook.com/tools/debug/?q=https%3A%2F%2Fkzi2c.csb.app%2F
Initially keeping the og:url as https://spurafrika.org/ caused warnings and og:description not getting picked up, once i pointed it to the actual url it all got fixed
Change the og:url to the right url may fix it, give it a shot and let us know.

Why is my CSS not working properly in localhost using xampp but working fine when same files are opened locally or from a Netlify site?

So I've been working on a website for college and I'm starting to learn PHP but for that I installed xampp and tried to access the website from localhost.
By my understanding, the HTML file and images, even (some) images defined in CSS are loading but the entire CSS file is not, like float and flexbox and some padding, borders, and different types of positioning isn't working as intended. It's definitely finding the CSS file so I don't think there's a problem in my <link> tag in the <header>.
HTML header:
<head>
<meta charset="utf-8">
<title>Home - akiro</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link href="https://fonts.googleapis.com/css?family=Oswald&display=swap" rel="stylesheet">
<link href="https://fonts.googleapis.com/css?family=Merriweather&display=swap" rel="stylesheet">
<link rel="stylesheet" href="style.css" type="text/css">
</head>
As Doc-Han Stated this is most likely caching, and its an issue I think most of us have run into during the UI development process.
One thing you can do to get around this, is to open and do your debugging in an incognito window which wont cache files and can be reopened to load new sets if session caching does occur.
Alternatively some code editors have an in-built web server instead for this reason. I've been using Adobe brackets for a couple years now and love it. It serves the pages using an internal Node server and as a result, they have it set up for real time code updates. Changes to the code are reflected in real time which i find helps a lot in dealing with UI development flow for me avoiding issues like this and just the saved 3-5 seconds of refreshing each time i make a change (which adds up when your making 5000 changes Im certain other editors offer something like this as well.
This is just because with Xampp the browser caches your CSS files. This means that if making changes to the file, the browser will still access the cached file rather than the new one. A simple trick is to open the CSS from the local server and refresh the page so that the new CSS will be used.
example open localhost:8080/project/css/style.css and refresh that page
Quite some possibilities why it's not working as expected:
As Doc-Han stated; an old version of the css my have been cached.
You're loading the css from a relative path: style.css. This means the css should be in the same folder as the html file. Maybe the css should be loaded from '/style.css' or '/resources/style.css' or another location
Maybe the css contains some simple typo's so you're applying 'flaot' instead of 'float'
Inspect your page through your browsers developer tools. Open the console. Check if there are there any errors. Check if the css did load, also check if the right version was loaded. Check if the styling rules are applied to the right html elements or are applied at all.
If it is a caching problem in Chrome you can open the dev tools, open the Application tab, click the 'clear storage' menu item and clear site data. Now reload the page. In the network tab you can also click 'disable cache' and reload the page.
Just clear your browser's caches and done!
I just had the same problem but opposite and troubleshooting with Google brought me here.
My server was working perfectly in localhost but when I tried visiting it live via Ngrok or port forwarding, I got broken pages without CSS. I read a comment in this post about visiting the CSS file directly and then refreshing and in doing so realized I couldn't visit a lot of my CSS files, and then realized I set rules in my .htaccess for rewriting. Only leaving this comment so if anyone makes my mistake and finds themselves here like I found myself here, check your .htaccess.

HTML relative URL resolution difference

I am looking at an older asp.net 2.0 web application. In the master page, there are the following tags:
<link href="style/template.master.css" rel="stylesheet" />
<script src="js/prototype.js" type="text/javascript"></script>
When I saw this, I expected some trouble with pages loading from folders within the site. I was not expected there to be a difference in how the relative URLs are being resolved. Below is a screenshot of the resolved URLs from a page in the Admin folder:
I expected the URLs to both be resolved relative to the Admin folder; but as can be seen, the URLs resolved differently. My question is why?
An explanation is fine, but I would really like a reference of the resolution rules that state the difference -- or of a bug that could causing this.
A bit more info:
There are no base tags in either the admin page or master page.
The behavior is the same in both IE 11 (in various compatibility modes) and Chrome 40.
The master page has an XHTML 1.0 Strict doc type.
Thanks
The head section in master pages usually have a runat="server" attribute and there is an 'Automatic URL Resolution in the <head> Section', this fixes the URLs for any link tags, but not for the script tags.
Why? don't know. Here's an article about URLs in Master Pages.
For a reference, you could look at the source, now that asp.net is open source.

Document mode defaults to 8, though using IE11. Why?

I have a problem that my webpage does not display as i wish it to do.
When opening the F12 developers tool in IE11 it says "Document mode: 8 (Default)".
If i change it to mode 9 or higher the page displays as i want it to do.
My code is included in the host web page through an Iframe. I do unfortunatly not have access to edit the host code. The host code includes the code:
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />
I thought this code would ensure that the code was not shown in document 8? The code is included at the end of the head tag, with 88 lines of code in front of it. Could this be what is causing it to use document mode 8? How can i work around this when i am not able to edit the head code?

Stylesheet not working in Chrome/Safari but can work in Internet Explorer

TL;DR
I've read through many questions on Stack Overflow on this issue and I've tried to follow the given advice. Still, my CSS stylesheet will not work in Chrome/Safari but it can work in Internet Explorer.
The only odd thing that I can see about my scenario is my server is returning all files as of type application/octet-stream. I cannot change this aspect of the server. Is there something I can do to interpret my CSS file as a stylesheet in Chrome/Safari and IE?
I have an embedded web server project that I am working on. I have very limited control of the server software and the ability to make page-level settings. All I can do is create static HTML, CSS, and image files that are compiled into the server application.
As such, all files that are returned from the embedded server are declared as application/octet-stream in the HTTP header. This produces warnings in Chrome but no errors.
Initially, I had a problem loading this style sheet in Chrome/Safari but it would work in IE. After reading through a couple questions on Stack Overflow, I found that I needed to change my stylesheet declaration from:
<link rel="stylesheet" href="/styles/index.css">
to:
<link rel="stylesheet" type="text/css" href="/styles/index.css">
When I made this change Chrome & Safari still failed to process the CSS file but IE also started to ignore the stylesheet.
Oddly, if I do not declare a DOCTYPE on my HTML document I can get linked stylesheets to work in all of my browsers. This is, however, not a desirable solution.
My guess is this issue has something to do with the HTTP header declaration and that it doesn't match the type declared in the link element.
What can I do to get this stylesheet to work in Chrome, Safari, and IE while following good web development codes-of-practice (i.e. using doctypes on my HTML files and not embedding the style code in the HTML headers?)
For clarity sake, the relevant CSS/HTML code is shown below.
index.css
html {height:100%}
body {margin:0;min-height:100%;position:relative}
iframe {width:100%;height:100%;border:none}
.hdr {min-width:765px;overflow:auto}
.logo1 {float:left;margin:4px}
.logo2 {float:right;margin:4px}
.menu {position:absolute;top:70px;left:0px;bottom:0px;width:175px}
.content {position:absolute;top:70px;left:175px;bottom:0px;right:0px;}
index.htm
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<link rel="stylesheet" href="/styles/index.css"> <!-- Removed the type declaration so that this would at least work in IE9 //-->
</head>
<body lang="en-us">
<div class="hdr"><img class="logo1" src="/images/logo1.png" alt="Logo #1"><img class="logo2" src="/images/logo2.png" alt="Logo #2"></div>
<div class="menu"><iframe name="menu" src="/menu.shtm"></iframe></div>
<div class="content"><iframe name="main" src="/home.htm"></iframe></div>
</body>
FYI, this is a new project that is being developed from an existing one. The original project did not declare a DOCTYPE on the HTML files. Therefore, all page data was loaded and executed in the browser in quirks mode. Furthermore, the index.htm originally consisted of multiple frames within a frameset.
I am trying to update this application, using correct, and up to date methods for developing web pages. I can make this application work, but I feel that this would be at a sacrifice of future-browser compatibility if I have to rely on browser quirks mode and framesets.
I have tried to close the link tag but that doesn't help. Technically, this shouldn't be an issue since this document is declared as an HTML5 document, rather than XHTML.
It's certainly due to the application/octet-stream content type. I can re-create the issue on my end. Soon as the content type is set to text/css your HTML/CSS load fine.
As a workaround you can use <style> tags for you CSS if you can't get the server to send the correct content type.
I hate to have to answer my own question this way but the problem was most certainly with the fact that the server was returning a content type of application/octet-stream within the HTTP header.
After discussing the issue with management we had to update the code associated with the HTTP processor. This is code that is part of a third-party RTOS and we have been extremely hesitant to making any changes to this code.
However, in this case the need has out-weighed that desire. I've integrated the necessary changes to fix the HTTP header to return a content type of "text/css" for cascading style sheets. All is now right with the world.
I think I'll just chime in here. Not to answer the question, but to confirm the issue and perhaps help people with similar problems.
I had the same problem: an external css file was loaded alright, but it was not applied in Chrome. (Safari and FF were ok about it). So, same problem, slightly different cause.
It turned out that because of a bug in the webserver code the HTTP response contained two Content Types, 'text/html' and 'text/css'.
The solution was to remove the faulty 'text/html' line. It seems Chrome is pickier than other browsers about response headers. Which I suppose is legitimate, but a warning would have been nice.
btw, you can see all the http information for a loaded resource in Chrome, when you open Developer Tools, and select Network. Then click on the file that you want to investigate. (it took me a while to find that)
We had a problems with an iframe wich it's contents was updated by an external javascript routine, the CSS were loaded but were not applied. But updating the body HTML from a routine present in the iframe head worked as suposed to.
This same behaviour was not present in gecko and explorer, but happened the same at Safari browser (webkit)
Hope this could give some light in this curious case.
I would like to add one bit of information that may save some of you some time. It appeared that chrome was not recognizing my CSS either. After reading the above post I reviewed the files in the Developer Tools->Network. Turns out that Chrome was using a locally cached version of my CSS. As soon as I refreshed as opposed to accessing the URL again, it worked!
I'm no expert, but i've made this mistake before, it's rather simple.
You've written:
<link rel="stylesheet" href="/styles/index.css">
If this is a folder in the same directory as your index.html file, then you need to remove the first /. like so:
<link rel="stylesheet" href="styles/index.css">
EDIT: I think someone else mentioned this already, but it may have been overlooked.