4½ Methods for Theming in (S)CSS
Harry Roberts – CSSConf Australia – March, 2015
Slide 2
Slide 2 text
Hello, Australia!
Slide 3
Slide 3 text
Hello, Australia!
Harry Roberts
Consultant Front-end Architect
@csswizardry
#4halfCSS
Slide 4
Slide 4 text
Consultant Front-end Architect
I help clients solve UI problems.
Lots and lots of different clients.
Lots and lots of different problems.
Slide 5
Slide 5 text
Theming Is Common
Slide 6
Slide 6 text
Theming Is Common
SaaS clients want to offer a varied product range.
White-label clients want to offer bespoke themes.
Hub clients want each part of a product to have its own colours.
Social network clients want to allow users to personalise things.
Slide 7
Slide 7 text
Theming vs. Customisation
Slide 8
Slide 8 text
Theming: defined by developers.
Slide 9
Slide 9 text
Theming
Requires developer input.
Finite amount of variants.
Known rules and constraints.
Slide 10
Slide 10 text
No content
Slide 11
Slide 11 text
Customisation: defined by users.
Slide 12
Slide 12 text
Customisation
Requires no developer input.
Infinite possibilities.
Whatever the user says goes.
Slide 13
Slide 13 text
No content
Slide 14
Slide 14 text
Advice on Theming
Slide 15
Slide 15 text
Advice on Theming
Avoid it if possible—make sure there’s a real business case.
KISS—always reduce the complexity involved.
Only make changes to cosmetic aspects—avoid altering box-model.
Enforce rules—deviation is expensive.
Use it as an up-sell—‘Any deviation is going to cost you.’
Slide 16
Slide 16 text
A Quick Note on Preprocessors
Slide 17
Slide 17 text
A Quick Note on Preprocessors
Some don’t need a preprocessor.
Some don’t neeeeeed a preprocessor.
Some need a preprocessor.
Slide 18
Slide 18 text
You should probably be using
a preprocessor.
Slide 19
Slide 19 text
No content
Slide 20
Slide 20 text
#1 – Theme Layer
Slide 21
Slide 21 text
Overriding default style with additional CSS.
Slide 22
Slide 22 text
Theme Layer
Possibly the most common approach (currently).
Start off with the base/default styling.
Use additional, subsequent CSS to override and redefine.
The Good
Only send as little CSS over the wire as necessary.
Alter the entire theme from one location.
You can theme anything.
Slide 63
Slide 63 text
The Bad
Lots of logic in your Sass.
Only supports a finite number of themes.
Theme information is spread out through the codebase.
Adding themes could be laborious.
Slide 64
Slide 64 text
#4 – Theme Palettes
Slide 65
Slide 65 text
Holding entire themes in a palette file.
Slide 66
Slide 66 text
Theme Palettes
Preload all of your theme settings into a palette.
Inject these settings into the project later.
Slide 67
Slide 67 text
Suited To
Fully bespoke theming for clients.
Adding specific branding to a project.
User Customisation
Drop the hex value(s) into a style block.
Bind onto utility classes rather than existing hooks.
Now just a case of decorating in the UI with the classes.
The Good
Requires zero developer input.
Allows users to ‘own’ their profile/platform.
Incredibly pragmatic—always a good thing!
Slide 86
Slide 86 text
The Bad
Requires zero developer input.
Lots of redundancy.
Wasted CSS over the wire.
Lose the ability to cache styles.
Slide 87
Slide 87 text
When to Use Which?
Slide 88
Slide 88 text
When to Use Which?
Who’s doing the styling: you or the user? – User Customisation.
Do the themes need to change once they’re on the client? – Stateful or
User Customisation.
Do you have themes that you want people to be able to toggle? –
Stateful.
Do you have sections of the site that need to look different? – Stateful.
Do you have preset themes that a client can choose from? – Config.
Do you offer bespoke theming for white-label clients? – Theme Layer or
Theme Palette.