Here's an idea that has been in my mind for a little while. I think it's a good one, but feedback is welcome. I thought that even if we end up using something very minimal (like the recently proposed "initial whitespace means fixed content" idea, which I'm still very excited about!) as the format for Gemini maps, it might still be a good idea to include a notion of "sections" (probably, but not necessarily, using Markdown's # Section ## Subsection ### Subsection syntax). This idea has nothing to do with text formatting as such, and the spec would be totally silent on the presentation of these headings, with no implication that they should be in a different size, font, colour, whatever (though I suspect many clients might do this). Rather, it's supposed to be a purely semantic thing, to *organise* the content in a long page. Advanced clients could do things like display a table of contents, or "jump to next (sub)section" navigation hotkeys, etc. If it makes things look prettier, that's a nice side-effect, but really it's about elevating the "textual content is king" philosophy of Gopher to the next level. Basic clients could, as always, be totally blind to this without it causing problems. This might seem like an odd thing for me to propose when I've been so resistant to defining a proper markup system for Gemini. IMHO this is something quite different, but I understand that it might not look it. If this idea is unpopular I'm prepared to drop it without much of a fight, but I thought I'd at least float it. -Solderpunk
solderpunk <solderpunk at SDF.ORG> writes:
[section headers]
> This idea has nothing to do with text formatting as such, and the spec
> would be totally silent on the presentation of these headings, with no
> implication that they should be in a different size, font, colour,
> whatever (though I suspect many clients might do this). Rather, it's
> supposed to be a purely semantic thing, to *organise* the content in a
> long page.
I think that a lot of the other things that go under "text formatting"
have semantic value that clients could take into account, too. Things
like *emphasis* and **strong emphasis** (i.e., as opposed to italic and
bold). I like the idea of clients generating TOCs and so forth, but I
think it's an argument in favor of using a semantic markup language in
general. I'm not sure where you could fairly draw the line once you
started down that road.
--
Jason McBrayer | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.?
| ? Robert W. Chambers,The King in Yellow
---