|
|
|
|
|
by simonrepp
2868 days ago
|
|
What you're seeing there is actually validation :), the lat/lng type is not magically inferred but instead explicitly requested by the code - if it were not valid it would generate a user-friendly, localized error message. Also the underlying document hierarchy that holds the data is validated. So on the contrary it is actually hard not to validate content in eno. The quirky looking syntax you mention is probably familiar to you from YAML or paper forms ("Name: Joe"), and Markdown ("# Section"), likewise if you have two levels you use "## Subsection". There's quite a few things that eno solves (there's only so much space on a frontpage, sorry), but if you want one of the more prominent ones: It's considerably hard to win over users without technical background to switch to secure, statically generated content solutions when the most prominent format works like this: http://yaml.org/spec/1.2/spec.html I've explained eno in 5mins to a non-technical intern who is now managing content at a client of mine and in months I haven't heard a single question about how eno works! User empowerment. <3 |
|
Please make this clear on the website! I think it’s a clever idea.
Also, this has garnered some attention on Lobste.rs [1], if you’re interested to read the discussion there as well.
[1]: https://lobste.rs/s/jno6gb/eno_notation_language_libraries