TLDR; skip to the problem section 👍
Background
We have a very large monolith legacy application. We are in the process of stripping functionality out into a new application.
These two applications have vastly different UI's built in vastly different architectures and technologies. As our users will be navigating freely between the two, currently, we need to unify the UI to some degree so the transition isn't so jarring.
It was decided to have a large CSS override style-sheet that we just load over the top of the legacy application (So we could spend more time focusing on the new app). This sheet, whilst massive, works.
Our legacy app has a root CSS file that is included on every page, regardless of how (some is classic ASP, some uses master pages, some is manually).
The problem
So we decided to use a #import tag in the root style sheet to pull in our re-style override.
Whilst we acknowledge that blocking rendering of the page is a horrible anti pattern we need this behavior to prevent flashing of the old UI, until the override sheet takes over.
We thought that CSS in the head will block rendering of the page until its loaded, however it doesn't appear to be waiting for the imported CSS. Is this expected behavior with regards to imports? Is there any way to make the user agent wait? Any information how how to achieve this would be very appreciated.
Thanks
There is no way to apply another CSS file synchronously to the CSS file it is embedded in. But as you already doing a lot of bodging in this project, here are some suggestions I can make:
(But before that: All of those aren't really good, not to say best-practice, and have definitely some danger to it.)
Hide the GUI in the critical section: Add a CSS rule in the root stylesheet, that hides the GUI, and another in the new stylesheet that overrides it and shows the GUI again.
If you can add something to all HTML pages: Add a loading screen. Something like
<div class="loading-screen" style="display:fixed;top:0;left:0;width:100vw;height:100vh;background-color:white;z-index:1000">Loading...</div>
and hide it again with the new sytylesheet: .loading-screen { display: none; }
All in one: Throw away the idea of using #import and write the content of your new stylesheet in the root stylesheet.
The best practice would probably be to rework the hole site structure or at least rework/remove the old GUI style.
Related
The browser I'm using, qutebrowser, allows me to set a CSS file that applies those styles to every web site (but doesn't allow you to set it per page/domain, as far as I can tell), so I downloaded a dark theme CSS stylesheet from solarized-everything-css, but it seems the result on some website is unsatisfactory.
Therefore, I'd like to know if CSS offers a way to not apply a sequence of rulesets (in my case it'd be the whole stylesheet) on some domains. Something long the lines of
#this-web-site-is-NOT-in-the-black-list-in("list.txt") {
/* the content of the dark theme CSS goes here*/
}
If it was possible, then I would add each problematic site to that sort of blacklist.
CSS itself cannot do this, because CSS is designed to apply only to a site from which it is loaded within the browser environment. Normally this happens by looking at resources listed in an HTML file's <head>, but can also happen from JavaScript injection via userscripts/addons/extensions a user has installed in their web browser.
So you need to use a 'user' style for this, which means you need to use a web browser that supports this. If the browser you're using (qutebrowser) does not allow you to set specific domains/URLs, then this will not be possible for you without creating your own user script (written in JavaScript, presumably) to apply this functionality on top of what the browser supports natively.
I am building webpapp with a JS framework (InfernoJS based on ReactJS).
I was wonderring how much important is it to load only usefull CSS.
In JS Framework website (with angularjs, Reactjs...), you have your CSS for all your routes which is loaded but depending on your page you may only need 20% of your CSS rules on the webpage.
For exemple:
You have '/about' with the ComponentA, for the JS Framework website you will load the CSS for ComponentA on the '/home' page as well but in that case that CSS is irrelevant.
I am wonderring if developping code to load only the css of the component display will really improve my performance espacially for SEO.
How the browser handle the unsed CSS?
Is it loaded in the memory waiting to find an element on which it can be applied?
Is It the same for every browser?
Edit:
#Psi partially answer it. I will reformulate it to make it more understandable.
On JS framework base, your page is splited in different components, most of the time, you will have a component Header, Body, Footer.
So if I go on the route '/home' and '/about' the component Header and Footer should be the same but the Body component will change.
So for optimization, I am considering to load the CSS for the Header and Footer component every time. However, the CSS loaded should change depending on the route and if I change the route (the page is not reloaded, It is handled by JS), the other Body component will be loaded but I will have the CSS of the Body component of the precedent route. In fact, generally you have the CSS for all your Body Components for every routes of your website.
So you have a lot of unused CSS rules. So should it be interesting to change the CSS loaded by adding and removing a <link> or I will probably consum to much ressource doing it and the browser have a good enough optimization about it?
To answer your question, there are several layers of thinking you need to go through.
First of all: Of course, every css that is loaded into your page will take the memory it needs to hold it active, because your html-page (although it may be static) possible could be changed dynamically (e.g. $.addClass).
So the browser knows what styles are being used at the moment, but has no way to determine possible future elements, thus being forced to keep every css definition in memory (or paged onto the disk).
The second thing is loading time. Depending on the order your css is being loaded, you may run into the situation where first your page loads and the css is being applied afterwards. This can even be visible to the user, being presented a non-styled page at the beginning and getting it styled later on!
This can be an issue even when loading only the necessary css via #import or <link rel="stylesheet">, so the best way is to provide the css in the html itself (loading it dynamically when rendering the html to the page).
This reduces loading time in two manners:
When loading the css via reference (i.e. #import or <link>), the browser starts opening a new connection (or uses the same connection after your html has been transferred completely) and requests the css linked in your html. So the browser
Loads the html although no css has been loaded yet and displays the html as soon as possble (always)
Needs additional time to establish a new connection or to wait for the html transmission to be finished before it even starts to load the css
If the used css is loaded very late, this can be a matter of seconds!
Although not asked:
For javascript, the exact opposite is desired in most cases: The browser starts executing a script as soon as it is received and pre-compiled. This may lead to unwanted behavior, when the html the script refers to is not loaded yet. So unless you are using a promise to ensure the page has been loaded before executing something, you should place in-line javascript as far as possible to the end of your page.
[edit]
To match your additional question:
It's hard to say. Of course, an optimized css will perform slightly better than an overloaded one in the client, but this makes design much harder as you have to keep track of any changes in any document and adapt your css accordingly. Also it might lead to discrepancies between same classes on different pages (e.g. .headline in page1 looks different to .headline in page2) when you want to update a class.
[edit]
If you generate the stylesheet automatically (dynamically), you may create more overhead by putting effort in the optimization than you save by the reduced stylesheet parsing time.
I am looking to the wisdom of the crowd for views on best practice for implementing CSS.
Our site was initially built using SASS compilers for CSS. Over time as more functionality has been added, each with specific styles, the CSS files and partials have become large. Loading all CSS for the entire site seems a waste of resources and time, particularly when a large percent is not utilised on any given page. However I am still told that this is more efficient than either inline styles or CSS style blocks within the page.
I am currently considering stripping down everything but core CSS to the SASS CSS file and then creating a series of specific CSS files that are loaded as required.
How have others approached this problem. Is there a consensus on the "best practice" when CSS files become large?
Thanks
D
You can write SASS only for specific parts of your site and load styles for specific pages only. For example you don't have to load styles for product list when you are on product page.
In the meantime you can have global stylesheet for something like menu, footer.
Loading styles inline or in block prevents styles from caching and makes your user download it each time they open website.
This is the perfect opportunity to clean up your styles and start fresh. I would reccomend you create layout.scss for styles used in all pages, and component_X.scss for specific component styles.
We can write CSS as the following types:
Inline CSS
Embedded CSS
External CSS
I would like to know pros and cons of each.
It's all about where in the pipeline you need the CSS as I see it.
1. inline css
Pros: Great for quick fixes/prototyping and simple tests without having to swap back and forth between the .css document and the actual HTML file.
Pros: Many email clients do NOT allow the use of external .css referencing because of possible spam/abuse. Embedding might help.
Cons: Fills up HTML space/takes bandwidth, not resuable accross pages - not even IFRAMES.
2. embedded css
Pros: Same as above regarding prototype, but easier to cut out of the final prototype and put into an external file when templates are done.
Cons: Some email clients do not allow styles in the [head] as the head-tags are removed by most webmail clients.
3. external css
Pros: Easy to maintain and reuse across websites with more than 1 page.
Pros: Cacheable = less bandwidth = faster page rendering after second page load
Pros: External files including .css can be hosted on CDN's and thereby making less requests the the firewall/webserver hosting the HTML pages (if on different hosts).
Pros: Compilable, you could automatically remove all of the unused space from the final build, just as jQuery has a developer version and a compressed version = faster download = faster user experience + less bandwidth use = faster internet! (we like!!!)
Cons: Normally removed from HTML mails = messy HTML layout.
Cons: Makes an extra HTTP request per file = more resources used in the Firewalls/routers.
I hope you could use some of this?
I'm going to submit the opinion that external style sheets are the only way to go.
inline CSS mixes content with presentation and leads to an awful mess.
embedded CSS gets loaded with every page request, changes cannot be shared across pages, and the content cannot be cached.
I have nothing against either method per se, but if planning a new site or application, you should plan for external style sheets.
Inline
Quick, but very dirty
This is (sadly) also the only really sane option for HTML formatted email as other forms often get discarded by various email clients.
Embedded
Doesn't require an extra HTTP request, but doesn't have the benefits of:
Linked
Can be cached, reused between pages, more easily tested with validators.
You want external css. It's the easiest to maintain, external css also simplifies caching. Embedded means that each separate html file will need to have it's own css, meaning bigger file size and lots of headaches when changing the css. Inline css is even harder to maintain.
External css is the way to go.
Where to start!!??
Say you had a site with 3 pages...
You could get away with Inline CSS (i.e. CSS on the page itself, within tags).
If you had a 100 page website...
You wouldn't want to change the CSS on each page individually (or would you?!)...
So including an external CSS sheet would be the nicer way to go.
Inline CSS is generally bad. It's much easier to modify the style of a page when all the styles are located in one central location, which inline CSS doesn't offer. It's easy for quickly prototyping styles, but shouldn't be used in production, especailly since it often leads to duplicating styles.
Embedded CSS centralizes the styles for the page, but it doesn't allow you to share styles across pages without copying the text of the embedded style and pasting it in each unique page on your site.
External CSS is the way to go, it has all of the advantages of embedded CSS but it allows you to share styles accross multiple pages.
Use external CSS when:
you have a lot of css code that will make your file messy if you put it all inline
you want to maintain a standard
look-and-feel across multiple pages
External CSS makes it a lot easier to manage your CSS and is the accepted way of implementing styles.
If the styles are only needed for one file, and you don't foresee that ever changing to apply to other pages, you can put your css at the top of the file (embedded?).
You should generally only use inline CSS if:
It's a one-time formatting for a specific tag
You want to override the default css (set externally or at the top of the file) for a specific tag
To everyone in the here and now, reading after 2015, with projects like Polymer, Browserify, Webpack, Babel, and many other important participants that I'm probably missing, we have been ushered into a new era of writing HTML applications, with regards to how we modularize large applications, distribute changes and compose related presentation, markup and behavior into self-contained units. Let's not even get started with service workers.
So before anyone forms an opinion on what is and isn't feasible, I would recommend that they investigate the current web ecosystem in their time to see if some issues related to maintainability have been gracefully solved.
Pros:
Allows you to control the layout of the entire site with one file.
Changes affect all documents at the same time.
Can eliminate redundant in-line styling (Font, Bold, Color, Images)
Provide multiple views of the same content for different types of users.
Cons:
Older browsers may not be able to understand CSS.
CSS is not supported by every browser equally.
In this case, the pros far outweigh the cons. In fact, if the site is designed in a specific way, older browsers will display the content much better (on average) than if the site were managed with tables.
If you are using a server side language, why not embed CSS and use conditional programming to display it as necessary? For example, say you're using PHP w/ Wordpress and you want some homepage specific CSS; you could use the is_home() function to show your CSS in the head of the document for that page only. Personally, I have my own template system that works like so:
inc.header.php = all the header stuff, and where page specific CSS would go I put:
if(isset($CSS)) echo $CSS;
Then, in a specific page template (say about.php), I would use a heredoc variable for the page specific CSS, above the line which includes the header:
Contents of about.php:
<?php
$CSS = <<< CSS
.about-us-photo-box{
/* CSS code */
}
.about-us-something-else{
/* more CSS code */
}
CSS;
include "inc.header.php"; // this file includes if(isset($CSS)) echo $CSS; where page-specific CSS would go ...
<body>
<!-- about us html -->
include "inc.footer.php";
?>
Is there something I'm missing that makes this approach inferior?
Pros:
1) I can still cache the page using standard caching techniques (is there a caching method that takes advantage of a CSS only external file??).
2) I can use php for special case conditional formatting in specific class declarations if absolutely necessary (PHP doesn't work in a CSS file, unless I'm missing some server directive I could set).
3) All my page specific CSS is extremely well organized in the actual PHP file in which it's being used.
4) It cuts down on HTTP requests to external files.
5) It cuts down on server requests to external files.
Cons:
1) My IDE program (Komodo IDE) can't follow the Heredoc formatting to properly highlight the CSS, which makes it slightly harder to debug syntax errors in the CSS.
2) I really can't see any other con, please enlighten me!
I know that there are questions regarding this same topic, but for HTML. What are some good conventions in regards to using external stylesheets in a Flex app.? How would you break up the stylesheets (names of stylesheets and what they include)?
Flex compiles the external CSS file when you publish your project.
There is a way to load CSS at runtime using Flex; it can be done by compiling CSS files into SWF files and load them at runtime using StyleManager.loadStyleDeclarations.
See the LiveDocs on Stylesheets at Run Time for more info.
Some conventions we use in organizing stylesheets:
Have one main.css stylesheet that holds all of the data for skinning the base application.
Have one fonts.css stylesheet to store all of the fonts in the main app, because these can get quite messy.
The main.css stylesheet is included in the main swf via the <mx:Style source="main.css"/> tag. We load our app with as little as possible, and once everything is loaded, if we need to immediately show some text (sometimes we just have a video playing if it's an advertising site), we fade/tween in the main elements and load the fonts.css via StyleManager.loadStyleDeclarations at runtime.
If we have an admin panel, we have an admin.css stylesheet which we load at runtime because the main app doesn't need it.
We don't need to divide up the CSS anymore than that because we usually create a whole set of skins in a Theme, so the stylesheet is just applying those skins to components and is pretty lean (using Flex 4). I tend not do divide stylesheets into anything smaller (like "pages.css", "comments.css", "popups.css", or even "controls.css", etc.) because it would be overkill and too much to manage for little in return. That's common with HTML, but that's because HTML requires CSS for nice presentation; Flex could do without CSS entirely.
When developing, one of us usually develops most of the skin right away (having a default wireframe setup, like those found on ScaleNine as they do the photoshop/flash/after-effects. There's no way to not have to recompile the css swf if you make changes. But if it is loaded at runtime, you only have to recompile the css file and not the main swf, which is useful but not really useful during hardcore skin development.
I tried keeping the main stylesheet separate during development (in a custom Theme), and it made development a LOT harder, because I had to recompile the css separately every time I made a change and sometimes I had to recompile the main app too, and there were strange and hard-to-track-down bugs, etc. Then I was compiling two different apps. So I recommend keeping the main css file part of the main app.
If you wanted runtime css without having to recompile anything, try Ruben's CSS Loader and check out the source. But that would come at a runtime performance cost.
Flex is not something I've dealt with, but I did some research. It looks like the code to call a remote stylesheet is this:
<mx:Style source="com/example/assets/stylesheet.css" />
Flex Quick Start: Building a simple user interface: Styling your components says this:
Note: You should try to limit the
number of style sheets used in an
application, and set the style sheet
only at the top-level document in the
application (the document that
contains the tag). If
you set a style sheet in a child
document, unexpected results can
occur.
The implication of this seems to be that multiple stylesheets are not really possible. It sounds like what you want to do is organize your stylesheets, check out Organizing Your Stylesheets and Architecting CSS for some ideas for approaches. It looks like you have classes and basic tags, but the W3C stylesheet specifications are different from the Flex stylesheet specification.
As a non-Flex developer, Namespaces looks interesting as a way to organize namespaces: How to use the new CSS syntax in Flex 4.