During a project to migrate assets from one server to another it was proposed that we change how our files were being included. For the first step we wrote an interesting JavaScript solution to include files using a single script file. This allowed us to update core styles and/or scripts by adding them to that single script include. Amazing, I thought at first. Then after combing through the several hundred or so files to make sure that we had all the necessary files to make our templates and pages work correctly the testing phase arose a completely different problem in none other than Internet Explorer 8 (IE8). Usually the first inclination is to kick a chair or filing cabinet once a bug is discovered in IE8, because in the end it will usually involve some type of MacGyver method.

The migration involved moving the same styles that had been used for years from one server to another and then including them using a different method. So first method was to check the new include method for any issues within IE8. Of course nothing was wrong with the include method, but when I started digging through the sources in IE8 I noticed that after a certain point styles weren’t being shown anymore. Thanks to a few well worded Google searches I found an interesting article about a limitation within IE8 that prevented more than 31 individual stylesheets from being loaded in a single page. I stopped myself hard in my tracks and looked though the list of files in the include counting each one of them. There wasn’t 31, maybe half of that. Then it struck me that the page itself probably had special styles just for that page and then I found the remaining styles that were over the maximum and stopped somewhere near 40+. I shook my head in disgust that this particular site had such a horrible spider web of styles, but then went back to figuring out a solution for the migration. In the end I figured it would be easier for now to include the core styles via import statements from a single file and work though combining all those styles via Sass / SCSS later to make them easier to maintain. Bulk over time was added via modular CSS styles that allowed this issue to build to the point of this issue occurring.

It was funny that no other browser (Chrome, Firefox, or Safari) had the same limitation in loading stylesheets like that, but it was interesting that the feature they had been using in IE8 actually pointed out a larger issue that needed to be corrected across the board. In the end it is worth mentioning that I don’t ever recommend loading more than 10 stylesheets for a given page. There are instances where libraries or frameworks get included separately and while that is fine any more than that and then you are asking for a maintenance nightmare on larger sites. Small sites with under 100 pages should be build with a template structure so that one stylesheet can be loaded. One point of truth and failure.

Modular Styles with Sass

Most of the sites that I develop do use the modular approach to build each component and feature that a site will need for launch. The CSS method of building one stylesheet for: tables, navigation, layout, carousels, and more, is a worthy effort to maintain focused files that aren’t massive in size but there are better ways now. With Sass / SCSS being used heavily in my personal projects I have noticed that I can take the same modular approach to front-end development to keep each file small and concise, but build one big file that is succinct and comprehensive that will maintain what a client or user will see. Easy right. This one point of reference for a particular table style is great when developing not only one project but for when multiple projects need to share the same code base.

While building the Centurion Framework almost 4 years ago I started thinking about these modular pieces that would allow me to update multiple projects from a single source automatically. With a framework I could include what I needed for a project and move forward without any added bulk by copying / pasting CSS files or having to go through line-by-line and delete what I didn’t need. By adding Centurion to NPM and as a RubyGem I could not only include them in my own projects more easily, but also share them with the rest of the development community to use and add to.

As a developer it’s easy to stick with what you know and stay in the safe-zone, but you should always be looking on how you can streamline and optimize your workflow to do things better. For myself the Centurion Framework was one way I saw a need in my own personal projects to make my life easier, but the same method can be applied to any project. Look at the process, identify areas that can be optimized, and then find solutions to make the process easier. For the IE8 issue that was discovered in my own project it made me frustrated at first that IE8 couldn’t simply work, but it also started me thinking about how to optimize all those styles so that a simply browser limitation was corrected permanently so that other developers didn’t have to go through the same problems in the future.