Refused to apply style

the actual issue is GET http://localhost:63342/css/normalize.css 404 (Not Found). MIME type issue is a result of this error - the web server responds with HTML 404 page instead of expected CSS.

You have leading slashes in your URL (/css/normalize.css) -
note the leading / before css. Such slashes tell the browser to resolve URLs from the web server root. But, as the built-in web server serves files from http://localhost:63342/<project name>, no resources can be loaded from http://localhost:63342 - thus 404 errors are thrown.

To work out the issue, change URLs to the ones relative to current file; or, if it's not possible for some reason, just use a different web server to serve your app (OpenServer or whatever server you prefer)

>Why should the debagger need a root file when the html document to style.css specifies the path without root css.style css?

it has nothing to do with debugger, it's a way the built-in web server work. You can debug your app on any server, the IDE doesn't force you to use a built-in one

> it has nothing to do with debugger, it's a way the built-in web server work. You can debug your app on any server, the IDE doesn't force you to use a built-in one

In the same b/css folder there are 2 css style.css and normalize.css files. Style.css  perfectly sees and normalize.css requires additional root path b/. In reality, when booting to a hosting server, it will give an error and in WebStorm it works as if it is necessary, and hence it is a bug.

I don't understand what you mean by "perfectly sees and normalize.css requires additional root path b"

Anyway, it's definitely not a bug, the web server works as designed

Дебаггер прекрасно видит style.css, но в той же директории отказывается видеть normalize.css, проект работает при дополнительно указанном пути с литерой корня в webstorm, что вызовет ошибку при загрузке на сервер обычный онлайн, . так как по таким путям что видит webstorm дебагер, невозможно на рабочем сервере  этот файл увидеть. что и показывает oserver. То  есть прописка пути с литерой корня одобрится штормом но не будет работать на реальном сервере . И наоборот ошибка в пути  декларируемая webstorm дебагером ровным счетом правильное решение на сервере. Запись правила @import url('/css/normalize.css'); это правильное решение a @import url('/p/css/normalize.css'); сработает только в Webstorm

У вас что русский, что английский непонятны одинаково, вы уж простите

Если путь к style.css в URL не содержит `/` в начале, то файл будет нормально загружаться

Дебаггер здесь не при чем абсолютно. И не нужно использовать префиксы вроде @import url('/p/css/normalize.css'), попробуйте вместо этого относительные пути, они на всех серверах работают. Или просто не используйте встроенный веб сервер, отлаживайте прямо на реальном сервере

href="css/style.css" 

Файл сss не содержал / , он нормально отображался, и работал, не работал присоединенный правилом

@import url('normalize.css')

файл, правило было записано в style.css. Что интересно OS видит normalize при пути

 @import url('/css/normalize.css'); 

таком а WS видит его так

'http://localhost:63342/css/normalize.css'

(не видит так как еще одну сss директорию дебагер в этом случае ищет почему то в сss существующей директории),
затем меняю правило на 

 
@import url('css/normalize.css'); 

тут ws

'http://localhost:63342/b/css/css/normalize.css' 

создает ищет в еще одной директории css которая никому не известно как почему то обьявляется, в этом случае и OS не видит присоединенный normalize. Правило обьявленное

@import url('/normalize.css'); 

WS видит так

 'http://localhost:63342/normalize.css'

, но не считывает OS тоже не видит его, далее

@import url('normalize.css'); 

WS видит нормально и OS видит нормально, всё начинает работать. Косяк тут в том что

@import url('/css/normalize.css');

правило записанное так было видно OS и не видно через дебаггер WS ибо странные пути он ищет, вышеописанные правила это подтверждают, вопрос решен, теперь буду воевать с angular- WS-OS это та еще головоломка.

style.css нормально отображается именно потому, что в href нет слэша в начале, т.е. путь к файлу ресолвится браузером относительно текущего файла (HTML странички), а не относительно рута веб сервера.

В @import директиве вы должны ууказать путь к normalize.css относительно расположения файла style.css - если они лежат в одной папке, это будет

@import url('normalize.css')

или

@import url('./normalize.css')

Обратите внимание, что, когда вы открываете страничку в браузере, это не WS видит или не видит файлы, это уже браузер исполняет ваш код и запрашивает файлы по адресу, вычисляемому в соответствии с правилами обработки URLs. Другое дело, что браузер запрашивает у сервера файл по определенному адресу, и сервер либо отдает этот файл, или отвечает ошибкой. Разница между встроенным сервером и Openserver в том, что в первом запросы к руту сервера возвращают ошибку

@import url('/css/normalize.css')

Но вот такую конструкцию видит OS и считывает нормально равно как и

@import url('normalize.css') 

Как ни странно. Я понял про пути Ваше последнее обьяснение растолковало, жаль что не сразу так описали, может я не толком обьяснил все равно спасибо.

VS Code can live preview in Chrome, Intellij refuses to aplay CSS, so it's a bug. You can replicate https://github.com/TarikGul/Sudoku-solving-visualizer/blob/master/dist/index.html

It's not a bug, WebStorm built-in web server has  X-Content-Type-Options HTTP response header set to nosniff - this header instructs browsers to disable content or MIME sniffing which is used to override response Content-Type headers to guess and process the data using an implicit content type. While this can be convenient in some scenarios, it can also lead to some attacks. nosniff blocks a request if the request destination is of type style and the MIME type is not text/css, or of type script and the MIME type is not a JavaScript MIME type

If WebStrom tries to be holier than a pope or more paranoid than web browsers and VS Code Live Server, then it is a bug.

Why don't you want to support scss? There is hardly a thing as "scss vulnerability" https://www.google.com/search?q="scss+vulnerability"