Why is the custom CSS of a subverse loaded as CSS inside the HTML source code, instead of a separate CSS file?

1.3K

•

Answered Why is the custom CSS of a subverse loaded as CSS inside the HTML source code, instead of a separate CSS file?

About the priority: I know that whichever comes last out of two identical CSS references (whether in the same style sheet or multiple style sheets of the same page), has the higher priority.

Whether a style sheet CSS is embedded in the HTML source code (<style> … </style>) or outsourced to a separate file (<link rel="stylesheet" href="stylesheet_filename.css" />) makes no difference in terms of priority, as long as the tags are at the same position.

But is there a technical reason for having the custom style sheet inside the HTML source code instead of a separate file?

It does obviously not bother me, but I am just wondering whether there is a technical reason for having the CSS contents inline in the HTML source code, instead of a dedicated .CSS file, referenced to using `<link rel="stylesheet" href="custom.css" />`. ---- About the priority: I know that **whichever comes last** out of two identical CSS references (whether in the same style sheet or multiple style sheets of the same page), has the higher priority. Whether a style sheet CSS is embedded in the HTML source code (`<style> … </style>`) or outsourced to a separate file (`<link rel="stylesheet" href="stylesheet_filename.css" />`) makes no difference in terms of priority, as long as the tags are at the same position. But is there a **technical** reason for having the custom style sheet inside the HTML source code instead of a separate file?

[–] [Sticky] • 1 pt

Editing on a static css prevents you from compiling it every time you change something in it.

Once the changes will be validated, they will get pushed to main.css.

link

[–] • 0 pt

main.css

But the custom subverse CSS is not a part of main.css, but written between <style> tags inside the HTML source cide.

parent
link

[–] • 1 pt

It's injected at the bottom of the sub's page so it takes over and supersedes main.css

(poal.css will soon be merged with main.css so all the !important; tags won't be necessary anymore)

parent
link

[–] • 1 pt

Probably because css is dynamically generated, as in everything is coded in one language, whether js or whatever is the new old, and then it spits out the whole shit on demand as an html5 soup

link

[–] • 0 pt

Indeed, that's possible.

The CSS generated in the HTML source code is not exactly the same as the CSS code in the editing text fields (the CSS generated in the HTML source code has no /* comments */, all invalid CSS removed, the direct image links instead of %%variables%%, and it lacks some line breaks).

parent
link

[–] • 1 pt

(edited )

Well it certainly won't let you upload raw text for security reasons, so it passes the whole shit to the shreder in order to remove unnecessary code and unwanted code, evidently

Have you tried add svg image via your css? Because if that works... Well that's a potential security flaw eventually

Something like

body { background-image: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' width='10' height='10'><linearGradient id='gradient'><stop offset='10%' stop-color='%23F00'/><stop offset='90%' stop-color='%23fcc'/> </linearGradient><rect fill='url(%23gradient)' x='0' y='0' width='100%' height='100%'/></svg>"); }

parent
link

[–] • 1 pt

Of course, it does not work.

But I wonder why that filtered CSS is embedded inside the HTML instead of a separate CSS file.

Not that it bothers me, but I would like to know a technical explanation.

parent
link

Load more (1 reply)

[–] • 1 pt

But is there a technical reason for having the custom style sheet inside the HTML source code instead of a separate file?

I'd argue there is. From an implementation perspective it's easiest to simply have the custom CSS copied from a database field into the template which renders your page.

This functionality could also be implemented in such a manner, that the same content is returned when the user accesses some url like /userdata/custom.css. But that's additional work. So why bother, if it works as inline code?

The only upside would be, that the responses are slightly shorter, and it may very well be, that the bottleneck is not bandwidth but processing power.