Experience Styling

purple experience styling the recommended style setup uses builder pipelines docid\ eiuuvj e1ci9x9ddw2zd to process the styles before they get delivered in the app or web the experience loads the following four files on startup custom css fonts css platform css submit css all your styling changes should end up in the storefront/assets/custom css file, the others are for special use cases to make style development easier and allow better common styles, especially in multi brand setups, it is best to not write any styles into the custom css directly, but to generate it via pipelines from scss files for details on the pipeline architecture see builder pipelines architecture info docid\ ciuaizu5cdum4l25pv3p5 relative imports are not supported in web without using scss pipelines, as only the custom css gets inlined to optimize loading performance because scss also supports css, you can leave existing css files as they are and just @use them, except for when they use css @import s themselves, in which case they must be rewritten to @use declarations basic layout (in default/storefront/assets) custom css ← generated, read only styles/ index scss ← entry point, only import other files colors scss ← app colors custom scss / custom css ← changes for this app only other styles that can be shared across apps imports scss imports must not end with " scss" / " css", else they won't be compiled in! instead, import other files using @use " /custom"; for example to import the custom scss in web, for correct distinction between preview resources and live resources, requests contain the query parameter preview=true because you can't hardcode these in relative urls, like when you set a background image from css, it is best to use resource //dynamic links, e g storefront app bar logo { background image url(resource //dynamic/storefront/assets/logo png); } out of convenience and to support older styles, the sass pipeline scans all css / scss files for relative imports (e g paths beginning without a protocol prefix like https //) and replaces them with the according resource //dynamic links, which you could see in the outputted file { "$schema" "https //builder purplemanager com/api/public/schema/1 0/builder config schema json", "postprocessing" { "pipelines" { "styles default" { "type" "sass", "output" "default/storefront/assets/custom css", "input" "default/storefront/assets/styles/index scss", "watchfiles" \["default/storefront/assets/styles/ / "] } } } }@use " /colors"; @use " /custom"; styling of content for posts that are displayed directly inside the purple experience (basically everything except for pdf issues and old read mode), the best way is to just use a separate scss file, e g storefront/assets/styles/article scss all post related styling should be scoped for storefront content body which is the outermost wrapper around the displayed content styling recommendations for multi brand apps the ideal solution is to have all base styling in the storefront/assets/styles folder, so they can be just copied from one app to another for per app overwrites, an extra file could be used which sets the css variables, fonts, colors etc example for a multi brand setup