Considering our main site ... we have 31 files in css/ ... and 9 more (.css) in the root directory. There are likely a few more hiding in other locations.

Now, granted, some of them are specific to some sub-system or 3rd party JS module, etc. And some of them are duplicated by someone who thought that "cp" is the same thing as "cvs" ... or something like that (obligatory meme, language warning: )

https://imgur.com/VbWttOp

But SHOULD we engage on a project to move all CSS to OneFileToRuleThemAll.css ... (and, while we're at it, remove all though pesky style=''foo" declarations in the HTML ...) ?

What say ye?

    I use a few but that's becuase of plugins, one for the main styles. I'm willing to concede that maybe wrong I guess

      All this time and I'm still debating with myself on this subject. If CSS had some sort of modularisation mechanism of its own it might make things easier — being able to break CSS into sections from within CSS itself to follow how the site itself is divided into sections.

      I'll assume that the reason for multiple first-party CSS files is that different sections of a site are differently themed, and that the theming is done using additional CSS files following a site-wide base. (Another way it might be broken up is functionally, with different classes of widget having their own style sheets so that, say, the datepicker looks the same across the site because datepicker.css. If a framework is involved, then it could be injecting CSS <link>s to do this.)

      A couple of benefits of OneFileoRuleThemAll.css:

      One request for one file serves to provide styling for the entire session.
      When sections of the site are restyled to look more different from/similar to each other, there is less refactoring needed before/after the change.

      Less refactoring in general. 'Cos where are you going to move it to?

      A couple of problems:
      The need include the CSS for parts of the site the user never has any use for (fifty rules for styling comment box widgets when the user isn't logged in and doesn't even get a comment box).

      CSS's lack of modularisation: more opportunity to step on each other's work (you can't just tweak this style to make it look right where you are without looking through the rest of the site to make sure it doesn't break things somewhere else).

      As for those style= attributes: what makes that element so different that it has to look different from any other element? And if there are a bunch of elements with that style, why are they all styled the same individually? Couldn't think of a class name or something?

      As for the image:
      https://thedailywtf.com/articles/The_Developmestuction_Environment

      Maybe look into using SASS? I've not tried it, as I'm not much into client-side stuff these days, but I think it could be leveraged to essentially include() separate CSS sources programmatically?

      Weedpacket

      I can think of several potential explanations for the inline CSS, none of which are particularly good, but all of which are potentially "valid", if you get my drift.

      1. The person writing the code didn't know (or more likely didn't want to try and figure out) which of the dozens of CSS files to put the directives into.
      2. The inline CSS exists to be available for JS manipulation? I'll have to think about that one.
      3. The inline CSS is mostly about positioning an element.
          2 months later

          If the styles are broken up by functionality or page (and honestly, one doesn't preclude the other) then separate style sheets is fine. The advent and fairly quick adoption of HTTP/2 via TSL has made round trips to the server less of an issue that it once was. I'm not recommending going completely nuts - don't make a separate style sheet for your paragraph and anchor tag styling, but if your home page has an elaborately styled carousel and call to action, or handles the hero image in a completely different manner than other pages, break those styles out and only include them on the home page. Start with the most general rules for shared areas in the global CSS file, then overwrite through specificity in targeted files.

          I use .less (I know, but I like it) and have a tooling setup where my gulpfile (again - webpack's fine, but preferences and whatnot...) loops through an array of source files defined in my package.json file and compiles, transpiles, and minifies each on it's own. Any of the package.json-specified .less files can include any other files (whether also specified or not). This lets me separate source files in a way that makes sense for development, but also to concatenate and include the global styles into a single sheet, then override them as necessary on a per-page basis by including a specific style sheet on specific pages.

          I also just realized this post is a couple months old - sorry about the resurrection...

            Oh, I don't mind this in your case ... the point is group discussion, and AFAIK nothing's really changed much CSS wise around here --- YET, anyway
            . 🙂

              Write a Reply...