Section 49.7 Finding Styles and Making Changes
If you are modifying existing styles or trying to identify how those will interact with your new content, begin by using your browser’s developer tools to inspect the element you want to change. Identify the style rules that are currently applied and where those rules are located in the source—the browser should tell you which SCSS file was responsible for each rule. You can also use the browser’s developer tools to test changes to the style in real time before modifying the source.
Then using that information, find the relevant source file in the
css directory. Make your changes, and then rebuild the theme (Section 49.2) to test. Make sure to test different screen sizes (desktop, tablet, mobile) using your browser’s developer tools as well as in both light and dark modes.
If the rules you have modified or added are in “shared” files like those in
components, be aware that your change will affect every theme that uses that component, so you should check how it looks in other themes.
You generally should have a commit for the CSS that is separate from the commit for the content changes that require it. For example, you might have one commit that updates the XML to produce new HTML and another commit that updates the corresponding SCSS styles for that content.
The files in
css/dist are checked into the repository so the common themes work without a build. However, your pull request should not not include updates to those files (stale builds tend to cause merge conflicts with other work that has been in progress). The individual merging the pull request is responsible for rebuilding them and committing the changes.
Follow the usual conventions when submitting (Chapter 51 and Chapter 53), and raise larger ideas, such as a brand-new theme, on the
pretext-dev discussion group first.
