Test major Koha Wiki changes or bug fixes here without fear of breaking the production wiki.
For the current Koha Wiki, visit https://wiki.koha-community.org .Working with SCSS in the OPAC and staff interface
The OPAC and staff interface's default templates use Sass files in SCSS format to generate the CSS files used in the themes. Sass is a "CSS extension" (similar to LESS) which allows authors to use "variables, mixins, operations and functions." Koha's Sass files contain some use of variables and mixins, but their primary difference from standard CSS is the logical grouping of style rules through nested rules.
When making CSS changes in the OPAC or staff interface, changes should be made to the .scss files, not the .css files.
As of 2018-09-09 the only Sass file in the staff interface is staff-global.scss
Setting up your development environment
Processing of Sass files is handled by a yarn build process which in turn runs a gulp script. koha-testing-docker and KohaDevBox' have both yarn and gulp already installed and functional.
As each Koha version might have some different dependencies, you need to run the following command before you start:
yarn install
Manually installing the tools
If your environment doesn't have yarn and gulp installed, you need to follow this guide.
- Install Node.js and the Node Package Manager ("npm").
- Use npm to install yarn
sudo apt-get install nodejs npm [not necessary in kohadevbox] sudo npm install -g yarn yarn install
If this doesn't work or you're using koha-testing-docker, try the following:
wget -q -O- https://deb.nodesource.com/gpgkey/nodesource.gpg.key | sudo apt-key add -
Add "deb http://deb.nodesource.com/node_8.x stretch main" (where stretch matches your Debian distro) to "/etc/apt/sources.list.d/koha-node.list" Run the following:
apt-get update apt-get install nodejs npm install -g yarn cd <koha-git> yarn install
- Next, install required node modules by running the following command in the Koha base directory
npm install -E
Compiling Sass files
After you have made changes to any .scss file, compile your changes.
For the staff interface, run
yarn build
For the OPAC, run
yarn build --view opac
The yarn build
process automatically compiles SCSS to CSS, adds automatic vendor prefixing, and minifies the CSS.
There is also a yarn css
command available which might be used by
developers who are making changes to Sass. This command does two things
differently:
- Adds .css.map files which aid CSS debugging using in-browser inspector tools.
- Compiles staff-global.css without minification. It can be useful to see unminified CSS during development, especially to see how SCSS compiles.
Autoprefixing
The build process includes a tool called autoprefixer, used to "parse CSS and add vendor prefixes to CSS rules using values from Can I Use." autoprefixer is run without any explicit options. The default configuration adds automatic vendor prefixes in order to provide coverage for:
- Browsers with greater than 1% global usage
- The last 2 versions of browsers
- Firefox ESR.
This tool eliminates the necessity of adding vendor prefixes to SCSS code.
Guidelines for editing Sass files
As of 2018-08-09 when Bug 19474 and Bug 20427 were initially pushed to master, Koha's SCSS files differ from their previous CSS counterparts primarily in that they use nested syntax. There are two other Sass-specific features to note:
- Some variables are defined near the top of the file. These variables can be used in place of the strings which define them.
- Some mixins are defined.
When adding style rules to Sass files please look for existing rules in which your additions might be logically nested. Remember that nesting adds specificity to your CSS, which may not be necessary for the style you want to achieve. The minimum required specificity is recommended.
Adding Sass files
To add a new CSS file to the OPAC or staff interface, simply create the corresponding .scss file in the css/src
directory. Each .scss
file in the css/src
directory is automatically compiled, minified, and saved to the css
directory.
Committing Sass files
When committing patches, don't include the compiled .css files into any patches, but only the changed .scss files. The RM or RMaints will add the compiled files when pushing the patch.
Noting that yarn build is needed in your test plan is recommended.
Reviewing changes of the compiled CSS file
git show --word-diff $SHA1 | egrep '(\[\-)|(\{\+)' | sed -r 's/^.*(\[\-.*\-\]\{\+.*\+\}).*$/\1/g'
For example :
git show --word-diff aebd3f6a53 | egrep '(\[\-)|(\{\+)' | sed -r 's/^.*(\[\-.*\-\]\{\+.*\+\}).*$/\1/g'
[-textarea{font-family:NotoSans}.navbar-]{+textarea{font-family:NotoSans,sans-serif}.navbar+}
[-textarea{font-family:NotoSans}.navbar-]{+textarea{font-family:NotoSans,sans-serif}.navbar+}
[-textarea{font-family:NotoSans}.navbar-]{+textarea{font-family:NotoSans,sans-serif}.navbar+}
[-textarea{font-family:NotoSans}.navbar-]{+textarea{font-family:NotoSans,sans-serif}.navbar+}
It shows that there are 4 instances of "textarea{font-family:NotoSans}.navbar" replaced by "textarea{font-family:NotoSans,sans-serif}.navbar"
Going further: beautify the css before making the diff https://scripter.co/git-diff-minified-js-and-css/
Using .sass-lint.yml
.sass-lint.yml is a set of rules for writing consistent SCSS. It is a configuration file for linting SCSS with sass-lint. Various code editors can be set up to do inline SCSS linting, or it can be done on the command line. Currently our SCSS files do not pass all sass-lint tests. New additions should.
See Sass lint rules for information about some notable rules.
- Getting involved | Development workflow | Bug Reporting Guidelines | RFCs | Plugins | Plugin hooks
- Version Control Using Git | git bz | Commit messages | Sign off on patches | QA Test Tools | How to QA | Debugging in VIM
- Coding Guidelines | Koha Objects | Rest Api HowTo | Coding Guidelines - API | Unit Tests | Continuous Integration | Interface patterns | Database updates | Adding a syspref | Bootstrap and LESS
- Debian Packages | Building Debian Packages | Easy Package Building | Commands
- External: Dashboard | Bugzilla | Schema | perldoc | Jenkins