uwu recently posted some of their thoughts on a markup language
for the hypothetical project a number of us have been discussing
that would exist between gopher and the web.
I agree with solderpunk that encryption should be a given.
As for markup syntax, I have been working on some ideas. I have
a much more full document that I have been working on that I
will likely share at some point, but my basic ideas are as
follows:
Links, emphasis, horizontal spacing, vertical spacing, keywords,
preformatted text, and document ident/version are the options that
make sense to me (maybe with some form of input field as well).
A document would be typed out like any other and anything with
a tag going on its own line. Whitespace and newlines are ignored
by the parser (except for during tokenization for determining the
end of a tag).
nl 5
The above would add 5 newlines
hs 4
The above would add four spaces before whatever text came on the
next line.
link I'm a link -> ???://someplace.space
The above would display as "I'm a link" and would link to the
address. If the file is non-text instead of '->' you would use
'>>'. Clients could diferentiate the look of those links to
indicate a download vs something that would appear on screen.
em I am emphasized text
The above would be emphasized. It is on the client to decide
how to do so, based on its capabilities. The spec would not
enforce bold, italics, underline, background color, text color,
etc.
pre
Any text under .pre would appear as written until
endpre
A link could be made bold as follows: .link.em
- - - - - -
Those are my basic ideas. .keywords would have a list of items
that describe the page and is an optional value.
All documents would start with a language declaration:
markupname 1.0
The language name plus the version of the language would let the
client know to parse the file further. In doing so, there does
not need to be much of a parsing pass on regular text files that
are not enhanced. They can just be printed to screen.
I know this is maybe too simple for some folks, or maybe not
elegant enough. Not sure. It seems to fit the bill for what I
would want. It would provide inline links and a few basic tools
for differentiating text and links. It would also do away with
the gophertype concept for the most part and instead simplify
to content that can be displayed by the client and content that
is to be downloaded.
- - - - - - -
This post feels a little scattered. I'm tired from the week. I'll
try to follow up soon with better examples.
In other news, my new bike arrived today! My first moutnain bike
(I have historically been cross/gravel bike guy). I assembled it
and tuned everything up. Then I went to pump the tubes up. The
first one went fine, but the rear kept popping the tire off of
the rim. After a few times I noticed a defect in the tire where
the rubber lip is supposed to seal on the rim. So, no ridding
until I get a new tire. Big bummer. I wrote the company and sent
photos, so I am hopeful they will get a enw tire out to me soon.
Then I can hit the trails by my apartment.
I've been enjoying hearing everyone's thoughts on this potential
protocol. I dont always agree with all of them, but I think that
a lot of input from various perspectives has a good chance of
landing things in a place that would be useful to people. I look
forward to more discussions!
