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

Question

There are several ways to style the elements in each page, in Enterprise applications usually the CSS Framework size increased about 1 MB, and when your users are using slow internet connection, you should decrease css framework size.

we can create new CSS for our element like .Blah and value it in css framework and do this for each element which cause increase size of css framework, but a cleaner page

<div id="blah" class="blah"></div>

we can also use our css framework utilities in each view to format each element to keep size of css framework, but a non-clean page

<div id="blah" class="margin10 padding20 bg-color-red fg-color-white text-bold else"></div>

which of above approach is the best approach for an Enterprise application, while you ensure that a majority of your users are using slow internet connection

Koel

In my opinion, keep your HTML file size less than 30kb and forget about your obsession. Write your HTML code clean and readable (the second way, I prefer) and let the gzip do the rest for you. Otherwise, soon you will ask the same question about your CSS file. Once, I had a same obsession to reorder all of HTML tags attributes for better performance in gzip but not that much benefit we had gained. – Aargau

Extjs Framework. It's So powerful because of support OOP Well and is based on pure javascript and it's has Sencha command that remove and compress files for publish. you should utilize it :) – Lodicule

Having 15 classes that all reflect presentation is always a sign that the document itself (or the document model/wireframe) is suffering. There is rarely a need for a 1MB stylesheet and on those occasions where such heavy stylesheets are necessary (or can't be avoided), a well-designed web app will only require the browser to download this huge stylesheet once and rely on client-side caching after that initial request. – Bulla

Which CSS framework has 1MB??? – Cribriform

@zeroflagL when I say 1Mb, I mean css + webfonts + iconfont, any css framework, which supports many languages, can easily reach this size – Koel

I'm not aware of a framework that large, even with icon fonts and javascript included. Since people are only responding to the CSS part you really should clarify what's included and how you use it. E.g. there's no need to always send support for all supported languages, when only a single one is actually needed. Also don't forget that compression reduces the size by some orders. – Cribriform

@zeroflagL obviously, I don't talk about the exact file size, in my case it is exactly 622kb – Koel

Answer 1

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.

Fiftieth

Answer 2

I think the correct answer is: "Find a happy and maintainable In-Betweener".

The modular approach

Namespacing your CSS classes by modules can be very valuable. You can just drop that parent CSS to an element, have all children DOM elements respecting your CSS structure and you can end having a very modular and powerful CSS framework. But, As you sad, it can start bloating you CSS files as namespaces CSS classes would be applied to all child elements.

The "use-css-properties-as-css-classes" approach

You might get tempted to use this approach as it gives you great flexibility for your elements in the page. The problem is re-usability. If you define that a specific component should always have its title set to "bold". Do you expect to apply the class "text-bold" every time you need to use this component? This can become a maintainability nightmare and I'd use it for exceptions only.0

The modular-with-variations approach

My favorite one: Break down your app in common reusable UI components. Also think about how these components might vary: sizing, colors or optional child elements. Then apply CSS properties as classes for the exceptions.

Your CSS code would then live under the following structure:

1. Majority of CSS work encapsulated by modules/ UI components (CSS namespacing)
2. Some or several CSS variations for your UI components
3. Property-like CSS classes for exceptions and page-specific variations

Tips

• Download source codes from existing CSS frameworks such as Twitter Bootstrap and study how they reuse CSS across different UI components.
• Consider using pre-compiled CSS such as LESS or SASS as you can make use of functions and variables.
• Use short css names for component names (so they don't bloat your final CSS file
• group, minify and gzip your css files.

Examples

CSS classes

/* Panel Component */
.panel {
    width: 100%;
}
.panel-content {
    padding: 10px 20px;
}

/* Panel variations*/
.panel-success {
    background-color: #3F3;
}
.panel-with-icon .panel-content {
    padding-left: 50px;
}

/* Exceptions (Helpers) */
.pull-right {
    float: right;
}
.margin-top-20 {
    margin-top: 20px;
}

HTML usage

<div class="panel">
    <div class="panel-content">
        Simple panel
    </div>
</div>

<div class="panel panel-with-icon">
    <div class="icon">
        my great icon
    </div>
    <div class="panel-content">
        Panel with icon
    </div>
</div>

<div class="panel panel-success margin-top-20">
    <div class="panel-content">
        My successful panel with page specific tweaks
    </div>
</div>

I hope it helps you.

Porkpie

Answer 3

I always go with the 2nd approach, because:

1.It's easier to maintain, you never know when you'll edit your pages. So for example if you give your elements a class of my-color and you wanted to change that after a while, all you need to do is to go to your css file and change my-color color, Imagine the time you save, and of course time means money.

2.You don't repeat your style, and that'll lead to less .css file size, and thus a a faster website.

3.You can make your .css stucture once, and then reuse it in every project. You'll have to change the style only. For example, you can have .my-color in every project with different style. Instead of making it from scratch each time.

The drawback is you'll have a larger .html pages, but usually browsers cashe your page and

in many cases the amount of loss in markup performance will be greatly surpassed by the amount of gain in stylesheet performance

Quoted from http://www.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/

This approach is called OOCSS = Object Oriented Cascade Style Sheet, it isn't considered a best practice yet, but it's evolving.

You can read more here

http://oocss.org/

http://www.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/

Subminiature