Write JSON as CSS
MORE PAIN! NO GAIN!
Instead of make your work of write JSON (maybe YAML) configuration file better this will make it worse.
We really hope you didn't try to cheat using any pre-processor like stylus, sass, less, because if you do, your verbose CSS will gain features like variables, includes, mixins and etc, please don't do that.
Unintended side-effect, every selector merges objects deeply, this means that if you write your selector two times your object will:
- Merge properties
- Overwrite if exists
Fortunately, unlike any pre-processor or browser, include
isn't supported, otherwise you
could use it to make any included file change any property of final
json, like happens when mutiple css files have same selector, example.
Please look at tests and anti-patterns to known what you should and shouldn't do.
- Make array harder to write
- Find a way to set keys with spaces ie:
{ "stylops analis": "Stylopidae"}
- Support other CSS features (more selectors, import, variables, media-query)
$ npm install -g stylops
$ stylops (-v|--version|version)
stylops/0.0.1 linux-x64 node-v15.2.1
$ stylops --help
USAGE
$ stylops -i test/fixture.css -o fixture.json
...
- Your root object is @page, ie:
/*
{
"root-property": "root property value"
}
*/
@page {
root-property: "root property value";
}
- Atributes should be valid json value (null, true, 3, "avocado")
/*
{
"root-property": 3.14
}
*/
@page {
root-property: 3.14;
}
- Your object property name is a tag selector, ie:
/*
{
"sub-obj": {
"property": "value"
}
}
*/
sub-obj {
property: "value";
}
- Array should be writed with :nth-child(index)
/*
{
"sub-obj": [
{
"property": "value"
}
]
}
*/
sub-obj :nth-child(0) {
property: "value"
}
4.1 Simple Array (unstable)
/*
{
"sub-prop": [
1,
2.2,
"string",
false,
null
]
}
*/
@page {
sub-prop: array(
1,
2.2,
"string",
false,
null
);
}
- Awsome json
- Awsome yaml
- Configs Suck
- Configuration complexity curse
- Configuration complexity clock
- Configuration files suck
- Conflang 2021
- Design Criteria for Programming Languages
- Do you know YAML
- Extensibility over Configuration
- Every Sufficiently Advanced Configuration Language is Wrong
- INTERCAL, YAML, And Other Horrible Programming Languages
- Language Evaluation Criteria
- Noyaml
- Painless YAML Templating
- State of config file formats
- Structured text tools
- Taming the Beast: Comparing Jsonnet, Dhall, Cue
- Use placeholders in yaml
- XML is better than YAML
- Archieml
- Cfg
- Coil
- Cue
- Echelons
- Edn
- Eno
- Expr
- Dhall
- Freemarker-template-for-json
- Frep
- FDT
- Grfon
- Gura
- Hcl
- Hjson
- Hocon
- Icinga dsl
- Ion
- Jinsi
- Jjay
- Jo
- Json2json
- Json2json
- Json template literals
- Json-template-engine
- Json templating
- Json-creator
- Json-pn
- Jsonapter
- Jt
- Jt
- Jtc
- Jtool
- Json-e
- Jsonnet
- JsonNext
- Jxc
- Kale
- Kanabo
- KDL
- KSON
- MERC
- Merge-yaml
- Meson
- MSON
- Nickel
- Nix
- Onion
- Pkl
- Preserves
- Rabl
- Refmt
- Refs
- Rego
- Rjsone
- Ron
- Samovar
- SML
- Skylark
- Spiff
- St
- Tao
- Tjson
- Toml
- Template
- Templateur
- Tmpl
- Virgo
- Watson
- Yaml-merge
- Yamlenv
- YamlInc
- Yamlp
- Yamlpal
- Yamlpath
- YAMLScript
- Yang
- yconf
- Yglu
- Ytt
- Ziggy
Sometimes, we don't like a language used as config because, some developers did a poor job on the application side, like not validating it, or in the case o CSS presenting different behavior in different browsers.
Sometimes, it goes in oposite direction, not only implementing it well, but exteding its functionality to match application domain:
- Serverless.JS: YAML with vars, includes and js function call
- Ansible: YAML with vars, imports and loops
- NixOS Modules: Nix with modularity, merge and type validation