37 lines
3.3 KiB
Plaintext
37 lines
3.3 KiB
Plaintext
# re: experimenting with ways to format documents on gemini
|
|
=> gemini://nytpu.com/gemlog/2020-09-05.gmi the original post by nytpu
|
|
|
|
## Introduction
|
|
Reading nytpu's post on formatting definitely got me thinking about formatting my gemlog and gemini site. When first building it, I realized how much there is to think about (even in a simple system like gemini).
|
|
|
|
* How do I handle navigation? A menu system? Do I need a back link?
|
|
* This looks great on bombadillo, but how does it look on other clients?
|
|
* Then of course after reading nytpu's article, how do I handle links?
|
|
* Are there any courtesies we could do w/ links? Should we hide the URL? Should we show it? Should we specify the protocol or leave that up to the browser?
|
|
* What about if the author specified the client used to design their site for a "best viewing experience"?
|
|
|
|
## My Thoughts
|
|
When building my site, I decided to go with a menu system that sits at the bottom of every page. I kept it at the bottom to keep the main content first and easily accessible. I chose links for the tabs you can go to, and h3 for the current tab. Of course, this looked fine on a pure text based browser, but when you start using other browsers, h3 renders differently and can look terrible. I'm definitely rethinking the navigation system.
|
|
|
|
In regards to links, I think nytpu has it right. Basically group the links as footnotes at the bottom of a section.
|
|
|
|
The option for headers is nice. I tend to keep h1 as the title, while using h2 as my section headers. If I need to use subsections, h3 is it.
|
|
|
|
This is all building up and becoming a lot to keep track of when writing, and this leads me to my next point: maybe there should be a new standard[1] or style guide that people can use to help keep geminispace easier to read and less messy.
|
|
|
|
=> https://xkcd.com/927/ [1] https://xkcd.com/927 (no, we don't need another standard)
|
|
|
|
## Why a style guide?
|
|
### Design & Consistency
|
|
So a style guide is somewhat enforced by the limited tools available to formatting text in a gmi file. It's awesome. But, if I wanted to write this article as one long h1 sentence, I could, and that would be awful. Also, it keeps consistency across a website and if multiple people use it, across the geminispace.
|
|
|
|
### A system allows automation
|
|
Since gemini does have a specification, one could create frameworks or templates for generating content more easily. Something like bb[2] could be setup to export gmi files translated from Markdown or HTML. Now, this could technically be done without an additional style guide, but a style guide would make it a bit easier. i.e. by denoting # as the title for instance. Or, some kind of tool could be developed to parse files and insert "components" (i.e. a menu component everywhere there is a $menu).
|
|
|
|
=> https://tildegit.org/team/bashblog [2] https://tildegit.org/team/bashblog
|
|
|
|
## Conclusion
|
|
I'm going to begin developing a style guide and possibly other tools to aid in building my gemini site and gemlog. I'd love to work with others on this so I will be hosting this on tildegit[3]. Please feel free to open PRs and contribute to the discussion! Of course this should never amount to anyting more than a guide for users to pick and choose from or some kind of framework to start with.
|
|
|
|
=> https://tildegit.org/swiftmandolin/gemini-style-guide [3] https://tildegit.org/swiftmandolin/gemini-style-guide
|