why stylesheet disabled in Sharepoint Default Masterpage?

Question

I am using Sharepoint Online, Classic Team site and default master page (Seattle.master), all default stylesheet of SharePoint such as pagelayouts15.css & corev15.css have "disabled" attribute.

See this screenshot

Answer 1

I suggest you contact Office 365 support team, check if have some updates occurs this issue.

As a workaround, we can add the css references into master page using SharePoint designer 2013.

<link rel="stylesheet" type="text/css" href="/_layouts/15/1033/styles/Themable/corev15.css"/>

Or try to go to SharePoint Admin Center, and make sure "Custom Script" setting is enabled. If not, enable it. After change, it might take up to 24 hours to take effect.

Answer 2

If this just started happening but was working before and you haven't made any changes, chances are it's an update by Msft that's altered the way registering css files works. I was using this format in a custom master page:

<SharePoint:CssRegistration ID="cssreg5" Name="<% $SPUrl:~SiteCollection/Style 
Library/xxxx/CustomBrand.css?Rev=27%>" runat="server" />

What I saw was the top navigation on sites using that master page got messed up, whereas sites using a different master weren't affected. One difference was the problem master page was acquiring the "disabled" attribute shown in your screenshot. I'm not sure but it appears the registered css functionality was supposed to work by injecting all the css as inline styling, and disabling the link to the file. For whatever reason that screwed up my custom top nav code and triggered the mobile hamburger menu.

Replacing the css registered links with direct links as suggested above, didn't work for me but I was able to switch to an older copy of the master which resolved the issue. I haven't had time to figure out what the differences between the masters are but I suspect Msft did some back end change with their customary lack of testing and that triggered a conflict. I imagine this will become more an issue as the updates roll out to more customers.

Answer 3

EDIT

My initial answer was incorrect, adding an 'After' to the CSSRegistration had no effect. The issue is not actually with our CSS being disabled.

Long story short, SPO is taking our CSS that we reference using:

<!--MS:<SharePoint:CssRegistration ID="CssRegistration4" Name="&#60;% $SPUrl:~sitecollection/Style Library/DigitalWorkPlace/css/main.css %&#62;" After=”corev15.css” runat="server">-->

and placing it into the page in a style block and disabling the redundant link to the external CSS file using the 'disabled' property:

<style type="text/css" data-themingsource="link to css file" data-original-href="link to css file">the content of the css file</style>

<link id="CssRegistration4" rel="stylesheet" type="text/css" href="https://unileverdev.sharepoint.com/sites/CI_ULAkumina/Style%20Library/DigitalWorkPlace/css/main.css?ctag=190108" disabled="">

When injecting the CSS into the style block SPO is transforming a specific part of the CSS into invalid CSS.

The CSS in question is part of bootstrap, SPO seems to try to encode some parts of an SVG, but mangles the string, resulting in invalid CSS...

.navbar-light .navbar-toggler-icon{background-image:url("data:image/svg+xml;charset=utf8,%3Csvg viewBox='0 0 30 30' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath stroke='rgba(0, 0, 0, 0.5)' stroke-width='2' stroke-linecap='round' stroke-miterlimit='10' d='M4 7h22M4 15h22M4 23h22'/%3E%3C/svg%3E")}

...resulting in the browser failing to apply any of the styles beneath that class.

Removing the classes from bootstrap is my temporary fix.

This process of injecting our CSS into a style block is pretty new (last few days), hopefully SPO will fix this so that we dont have to apply this hack.