How Are CSS Frameworks Used

What is a CSS framework?

CSS frameworks are just CSS files. They provide pre-written CSS that you apply to your HTML by using the class names defined by the framework in its CSS file.

  • Some frameworks are focused on one particular task, e.g. page layout. 960.gs is a good example of this.
  • Some frameworks are more extensive, and include pre-written CSS for typography, form layout, print styles etc. Blueprint is a good example of this.

Some frameworks also include reset styles, which attempt to reset all styles for all HTML elements to very neutral defaults. These are automatically applied to all HTML elements, so you don’t add classes to your HTML to apply them. A lot of them are based on Eric Meyer’s CSS reset.

What is the best Approach for CSS framework of an Enterprise Cloud application?

File sizes

My first point would be that when dealing with an enterprise level application the actual total quantity of css when measured in megabytes is slightly less important, even for slow internet connections. It's important that the pages you load into an empty cache of a potential conversion that just clicked your pay per click ad for the first time are as tight as you can possibly make them, but for an app that a user is paying for and is intending to invest their time and effort, priming a cache every release, even with a megabyte of css is less of a problem. You could load it all last on the login page so it's all sorted while they put their credentials in.

Furthermore, you'll have the time to investigate some other techniques, such as loading critical 'above the fold' css in it's own, optimised file first; and splitting the css files up so that the common stuff is loaded on the first page view but any page specific stuff is loaded per page, as it's visited (for the record, this can be very good for the aforementioned PPC targets).

CCS Tricks goes into more detail here and here.

Complexity

One of the bigger considerations of enterprise cloud applications is the maintainability of the css. You're probably going to have a team of developers and a complex user interface. These things can quickly turn into a maintenance nightmare if the wrong decisions are made concerning the approach to css.

It's all very well if you users can load a page in 0.1s less, but if it takes you 30mins more to make every simple css edit then you're in trouble.

My recommendation

You want a combination of both. You should strive for semantic, context free css selectors in order to hit maximum re-usability (and low file size) and maximum maintainability. This allows for effective file size management and effective, scalable development.

For example:


.blue-box

.header-login-box

.contact-form-submit .green-button

bad: not semantic, or too context specific. I'm assuming that .blah pretty much falls into this category, judging by the phrase 'do this for each element'.


.login-box

better: easier to re-use, semantic, but still too contextual


.box--highlighted

.button

.button--standout

even better: really re-usable because of complete decoupling from page context, but still clearly semantic, making it easier to maintain.


With the final examples you break your app UI designs down into modules which are defined and re-used wherever they are needed. It's conceivable that you may use more than one per HTML element, but you won't have ten.

It's also OK to use utility classes, such as .pull-left in fact, Harry Roberts at CSS Wizardry, a successful consultant whose done this stuff in the wild for real clients recommends it.

Three further avenues of investigation

There are currently three organisational / naming strategies for scalable css architecture that try to tackle the problem, you might want to look at them in more detail:

BEM: docs introductory article

OOCSS: docs introductory article

SMACSS: docs and introduction

All three will help maximise re-usability and minimise file sizes while giving you rules to follow to keep things tight and help with new members of the team.

Do you use a CSS framework?

No, I'm not using any framework, just a well thought out naming system that I reuse over and over and a basic css with a few resets and some base styles.

Why am I not using a css framework?

The use of a framework usually assumes that the designer is familiar with its conventions which is quite often not the case - you're not the one designing the page or the client has his own designer. And even if this is not the case, there will always be designs that won't fit into 960 pixels or simply have an even size so you can't use your magical .span-4 class.

Which leads me to the next point. The naming is not semantic. In theory you would expect a framework to ease maintaining a large site. However, suppose you have to make a slight design change. This basically means changing the html across all the template views involved. This is hard and risky even with a versioning system, because it's one thing having to rollback to a single css file, and another to 100 views. All because input.span-19 should have 5pixels less. CSS frameworks - the new inline css.

What about cross browser issues? Either you're using a framework or not this is not going to change. There are browsers or operating systems that have certain particularities. Bottom line - Internet Explorer will still suck as much.

CSS Frameworks stand out for discipline and I have to give them credit for that, but in the end it's all about the one writing the code.

CSS framework used by Vue.js website

From what I can see in their style.css they are NOT using any framework. It's 100% their code.

The only 3rd party libraries they use are:

  • Font Awesome
  • Google Fonts
  • styles for Algolia's search

Sample Image

Are CSS Frameworks Really Worth Using?

The main use I have for CSS frameworks is that they tend to force you to think about how you're going to organise you code rather than provide you with indispensable tools for your day to day tasks.

For that reason, I'm a fan of boilerplate rather than things like blueprint as boilerplate tends to focus on how you structure your css stylesheets and imports rather than providing you with a collection of semantically confusing helper classes.



Related Topics



Leave a reply



Submit