Skip to main content

Dynamically altering CSS Style Sheets in JS

 I recently had a project which was running unit tests in an ajax call and color coding a corresponding row in a table according to the results. The calls were being made, the tests were being run, the results returned and the correct <div> being identified to change the background color. The problem: a CSS class in Bootstrap had such a particular specificity that it was overriding an effort I made to change the background color of the table row using classes. 

After searching how to dynamically alter a CSS style sheet I came upon this solution. 

The document.styleSheets property is a collection of the style sheets attached to the page. I needed to loop over them, identify the one I wanted to access since they can appear in any order, and then delete the rule I wanted (it wasn't being used anywhere. If it was, this would be much more complicated). Also since, it wasn't a true array, the each() method wasn't available. Throw back to a for loop.


for(var x=0; x<document.styleSheets.length;x=x+1){
   if(document.styleSheets[x].cssRules[0].cssText.toString().search(":root { --bs-blue:") > -1){
      document.styleSheets[x].deleteRule(162);
   }
}

This process identified the style sheet I wanted to access based on the text of the first rule. Admittedly this wouldn't scall across versions since who knows what the first rule for the next version of Bootstrap would be but it worked for now. 

Deleting rule 162 runs into the same issues as comparing the rule based on the text. It probably would have been better to loop over the array of rules to find the text of the rule I wanted to delete but I'll have to leave that for a later upgrade. In the meantime, this is working and my results are color coding as expected. 

Labels:

Comments

Post a Comment

Popular posts from this blog

Creating Stories and Tasks in Jira: Personas and our Software Development Team

Part of the CI/CD Development Series The next step is developing who is on our hypothetical development team. Given that it has a React front end and ColdFusion as the Server Side language, I came up with the following personas, all of which have their own needs and considerations for our development environment. I've listed all the jobs that need doing, not the people involved since, even on a small team or a team of one, these "hats" are all worn by someone, even if it's the same person. Personas for our Project Dev Ops Coordinator - The person responsible for smooth and accurate deployments CF Developer - The person responsible for the API and fulfillment code development and maintenance. React Developer - The person responsible for the front end development Database Coordinator - The person responsible for the schema, data, up time and, presumably the testing databases used by the developers. Lead Developer - The person responsible for coordinat
6 comments
Read more

The Three Deployment Environments: Production, Testing, Development

Part of the CI/CD Development Series A UML Deployment Diagram is a static picture that shows the different "nodes" that work together to create an environment. Typically these nodes consist of hardware, software or other key points. It's a high level overview, just enough detail to get the idea across of the layout without getting too lost in the details. These are the three deployment diagrams for our project. Production The production deployment is more elaborate than the other two below. Our project has a React front end which means that in addition to images and CSS files, it will also have a largish number of Javascript files. All of these are static and do not need any server side processing. As a result, we don't want them on our ColdFusion server taking up space, memory, bandwidth and other resources when we can use those resources for more efficient processing of ColdFusion files. This allows our server to handle more CF requests since they are not busy
1 comment
Read more

As the Dev Ops Coordinator, I need to set up our git repo into several branches with the appropriate permissions for each one

Part of the CI/CD Development Series The core of every CI/CD process is the code repository whether it be Git, Mercurial, SVN or whatever. The general idea is that it allows multiple developers (or whomever) to access your code in the appropriate way in the appropriate level. This can either be the ability for anyone to pull an open source project but not write to the repo directly or full access to a developer on your team to create branches, push to master or anything that needs doing. For our project, we're using git although the hosting provider was up for discussion between Github, Bitbucket by Atlassian or CodeCommit on AWS. We decided to go with AWS for two reasons. 1. We are going use other tools in AWS as part of the build so we decided to keep it all together. 2. We needed to solidify the ins and outs of using IAM for the process. Basic Steps Create the Repo Create the branches we need Use IAM to apply the appropriate permissions to each branch and to set up
1 comment
Read more