Change Details

There exists the concept of postprocessors in celerity: https://we.phorge.it/source/phorge/browse/master/src/applications/celerity/postprocessor/ These processors just build a variable map (based on the [[ https://we.phorge.it/source/phorge/browse/master/src/applications/celerity/postprocessor/CelerityDefaultPostprocessor.php$20 | default variables ]]) and then replaces an idiosyncratic variable syntax in all css files. It does exactly what [[ https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties | CSS varibales ]] can do. My proposal: - ditch this postprocessor system - migrate all default variables in a css file, which is part of the core css package ```lang=css :root { ...variables } ``` - create an extra css file for every postprocessor to overwrite the css vars - wrap the information about these css files in a celerity theme class - replace all `{$var}` celerity embeddings in with var function: `var(--var)` - refactor the accessibilty selection to an selection of themes (maybe even multiple themes?) - embed the theme css files according to selection Future: - makes it possible for an extension to offer themes (which are for now only overwrites of the default css vars) What do you think about this idea?

There exists the concept of postprocessors in celerity: https://we.phorge.it/source/phorge/browse/master/src/applications/celerity/postprocessor/ These processors just build a variable map (based on the [[ https://we.phorge.it/source/phorge/browse/master/src/applications/celerity/postprocessor/CelerityDefaultPostprocessor.php$20 | default variables ]]) and then replaces an idiosyncratic variable syntax in all css files. It does exactly what [[ https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties | CSS varibales ]] can do. My proposal: - ditch this postprocessor system - migrate all default variables in a css file, which is part of the core css package ```lang=css :root { ...variables } ``` - create an extra css file for every postprocessor to overwrite the css vars - wrap the information about these css files in a celerity theme class - replace all `{$var}` celerity embeddings in all css with var function: `var(--var)` - refactor the accessibilty selection to an selection of themes (maybe even multiple themes?) - embed the theme css files according to selection Future: - makes it possible for an extension to offer themes (which are for now only overwrites of the default css vars) What do you think about this idea?

There exists the concept of postprocessors in celerity: https://we.phorge.it/source/phorge/browse/master/src/applications/celerity/postprocessor/ These processors just build a variable map (based on the [[ https://we.phorge.it/source/phorge/browse/master/src/applications/celerity/postprocessor/CelerityDefaultPostprocessor.php$20 | default variables ]]) and then replaces an idiosyncratic variable syntax in all css files. It does exactly what [[ https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties | CSS varibales ]] can do. My proposal: - ditch this postprocessor system - migrate all default variables in a css file, which is part of the core css package ```lang=css :root { ...variables } ``` - create an extra css file for every postprocessor to overwrite the css vars - wrap the information about these css files in a celerity theme class - replace all `{$var}` celerity embeddings in all css with var function: `var(--var)` - refactor the accessibilty selection to an selection of themes (maybe even multiple themes?) - embed the theme css files according to selection Future: - makes it possible for an extension to offer themes (which are for now only overwrites of the default css vars) What do you think about this idea?