Established CSS & 3rd Party App Integration

CSS can be a beautiful thing; of course conversely, it can be an ugly thing. But I’m less interested in aesthetics and more interested in how it can make my development work easier.

Photo: russweakley

CSS is very helpful due to its flexibility but unfortunately it has some glaring shortcomings.

Ferdy Christiant highlights one of these shortcomings in his article suggesting the standardization of CSS Selectors. The main impetus for suggesting yet another standard?? 3rd party app integration.

At the corporate level, multiple web apps usually are presented along side each other or within some sort of a CMS or Portal. Good form aside, it is generally assumed to be good practical advice that you should integrate the style sheets of these apps with one another in order to give them the same look and feel as well as to provide a central resource for managing that look and feel.

In real world application (when done correctly) this is where I often see CSS make the biggest contribution toward helping my development (and subsequent maintenance) actually become easier.

Welcome to the Neighborhood

Ferdy uses such a scenario to illustrate his frustrations. Bringing in some 3rd party app off the street and integrating it into your already seamless and well-planned environment is always a nightmare.

Oh boy can I relate - if anyone has stumbled across a method or application that works well for handling such events please share. As of yet, I haven’t known anything besides the painful process of manually updating both the stylesheet and source code over a period of days and sometimes weeks.

It has been my experience that the process of integrating the app is usually so painful that the mere mention of “upgrade” brings back those terrible memories and the upgrade itself is avoided like the plague and never actually carried out.

Standardize the Elements?

Ferdy throws out the suggestion of adopting a new standard of naming CSS selectors. His suggestion is that all all ISVs name their selectors the same way (i.e. “l_hdr_m” (layout header menu), “l_ftr” (layout footer), etc..) thereby assisting integration efforts.

I sure feel his pain on this one - and I even like his suggestion, but I’m afraid as the comments suggest, that there might be too many ways this solution could go awry.

Another Approach

Perhaps it would be beneficial to start with addressing the upgrade issue. At least the dread of upgrading might be lessened and provide development with a sense of only having to clear one hill instead of an infinite amount of work.

It might be an interesting approach to create some sort of reuseable abstraction layer that handles integration on request.

In reality this would probably require the same amount of manual work for selector mapping as the old fashioned way but at least it would make upgrading easier.

Does anyone know of a solution like this, or alternative, already on the market? I’m sure a lot of people would be interested in lessening the sting that comes from problems such as this.