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.
I'm using Meteor to build a site that has different CSS and scripts (jquery mobile) for mobile devices than it does for desktop browsers. I'd like to be able to conditionally include these in the head element based on the user agent. I'm sure this can all be dynamically injected into the DOM, but is there a Meteor best practice for this kind of thing?
i would suggest adding a browser specific class to the body element like so (client/lib/environment.js):
if(navigator.userAgent.indexOf("Trident/4")>-1)
$("body").addClass("ie8");
i use less and then just have an ie8.less file like so:
.ie8{
//override normal styles here - may have to use !important
}
this doesnt meet your goal of only loading what's applicable to each client, but it does fit the bill for browser specific styles
if your files are externally stored and you are using meteorite, you could maybe use this https://atmosphere.meteor.com/package/external-file-loader to detect and then load the needed scripts
however, if you store your files in your meteor app, they've probably already been combined and sent to the browser
See this question: Excluding bootstrap from specific routes in Meteor . A similar approach may be used to achieve what you need.
Also, be aware of CSS #media command, it is commonly used to differentiate mobile styles.
#media only screen and (max-width:500px) {
...
}
I am building an app on top of webkit, I need to modify a CSS file (edit a selector), which I can do once the page is loaded using Javascript. In my particular scenario I may load the page many times and I would like to mutate the CSS in the cache (using Javascript, as opposed to hacking webkit). Any ideas?
Without entirely understanding your use case I see at least three cheap and fast methods to override some styles:
use one of the many bookmarklets out there (e.g. this one by Paul Irish) to play around injecting styles or
use a short snippet of javascript ondomready to inject a stylesheet with selectors and styles into the head of the document (similar to the bookmarklet above) or
define a specific enough CSS selector and simply include an inline style element in your document (which I would not suggest)
All three methods are basically the same. Depending on what you have, are able to edit or want to achieve either method may be more suitable.
User stylesheets or extensions like Stylebot for Google Chrome may be another possibility to look into.
Weird stuff like loading referenced stylesheets via javascript's XHR, get the content of the file, modify or inject stuff and reapply the styles to the current document are possible as well but probably not what you're looking for.
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 would like to control which parts in Stackoverflow are visible to me by a css file.
There are about ten css -files in Firefox installation folder. I am not sure whether I should edit them or not.
How can I customize Stackoverflow by CSS in Firefox?
You can create a file called "userContent.css" in your profile folder and it will be loaded on each page. Here's more information: http://www.mozilla.org/unix/customizing.html
If you need to make changes which only affect one particular site instead of every site, then you can use this syntax:
#-moz-document domain(stackoverflow.com) {
body {
background-color:#f0f;
}
}
The CSS equivalent of GreaseMonkey is the Stylish extension which allows you to overwrite site CSS without modifying your userChrome.css file.
With Stylish installed, you can simply create a custom user style for stackoverflow containing your css overwrites without risking messing up userChrome.css. You can also disable or enable that particular stylesheet at any time. Also, make sure to use !important in your style declaration as CSS specificity comes into play.
Try using firebug from http://getfirebug.com
You can also use greasemonkey to do further customization.
You can get a very handy addon in Firefox, called GreaseMonkey. It executes a custom javascript after a page loads, and is able to modify the html on the client side. For example people use it to strip out various elements, change color, fonts, rearrange elements etc
There is also a book about it available online for free
You can get the Greasemonkey add-in here.