Thoughts on Gemtext
This document is a summary of Gemtext雜感.
Protocol and Markup Language
First, we should clarify that the Gemini protocol and the Gemtext markup language are not the same thing. Certainly, the Gemtext document is Gemini's native response format, closely related to the protocol and its users. However, users are not required to deliver Gemtext documents, and can publish documents in other formats (e.g., HTML).
On the other hand, since most of the content that can be consulted with the Gemini protocol is Gemtext documents, it is inevitable that the quality of the content will be affected. Therefore, the two evaluations are very easily confused.
I am not familiar with either protocol or markup language, but as an HTML document author, here are my intuitive impressions of the Gemtext language/document.
After viewing some Gemtext documents
- ASCII art too much
- Take up a lot of space
- Must skip to the text.
- It slows down the reading.
- Some fonts are corrupted and meaningless (environment-dependent expressions)
- Cannot be hidden
- No alternative text
- I don't deny the artistic expression of characters. However, it is bothersome (in some cases, it is a clear barrier) for users who simply want to read textual information. Even if visual representations are acceptable, they cannot be received reliably (depending on font, letter spacing, and line spacing). Images and style sheets are better, because they can be disabled (if the user agent supports them). In addition, there is an alternative text, or the text can be referenced as is.
- The specification only defines the type of font. Users may adjust letter spacing and line spacing (especially for reading code).
- From 5.4.4 Preformatted text lines in the Speculative specification:
Preformatted text lines should be presented to the user in a "neutral", monowidth font without any alteration to whitespace or stylistic enhancements.
- If the placed ASCII art is meaningless (in HTML, an empty
alt attribute value, that is, an expression whose absence does not interfere with referencing), then it is a decoration. Appearance control.
- When there is no visual information, it is difficult to judge whether the preformatted text is a code or an artistic/decorative expression (even if the context can be used to judge). The fatal problem is that important information is replaced by ASCII art. For example, if the author's name, contact information, and headline are only represented in ASCII art, it will be difficult for the user to find the information.
- Information that users need (such as document titles and headings) should simply be text.
- Authors should be aware that they run the risk of their ASCII art becoming a series of unintelligible symbols.
- Project Gemini stipulates that it is up to the client/user to decide how to render the document,
but makes no mention of accessibility or alternative representations for ASCII art or preformatted text.
- Alternative representations for preformatted text: Authors are not required to use alternate text. Clients are also not required to render alternative text. From 5.4.3 Preformatting toggle lines in the Speculative specification:
Any text following the leading "```" of a preformat toggle line which toggles preformatted mode on MAY be interpreted by the client as "alt text" pertaining to the preformatted text lines which follow the toggle line. Use of alt text is at the client's discretion, and simple clients may ignore it. Alt text is recommended for ASCII art or similar non-textual content which, for example, cannot be meaningfully understood when rendered through a screen reader or usefully indexed by a search engine. Alt text may also be used for computer source code to identify the programming language which advanced clients may use for syntax highlighting.
- Even if it were mandated, it would not be possible to enforce the setting of alternate text (unless it is treated as an error) as long as there are people who mark up the text manually.
- Why should I see ASCII art instead of images?
- Japanese ASCII art is not always represented in monospace fonts. It is quite possible that it may appear on a text line. In this case, there is no workaround.
- If an image is an appropriate complement to the document, then an image should be chosen. Just link to them.
- Decorative symbols
- Navigation (back to home page link, etc.), signature, license missing/existing
- Like HTML, needs to be added manually
- Cannot add meta information to content. I want to use at least the following information:
- Release Date
- Revision Date
- Signature (creator, copyright holder)
- Publisher's contact information
- In HTML,
- Cannot provide the relationship between contents. (In HTML,
- With only 3 heading levels, the Gemtext language is intended for simple, short documents.
- No matter how simplified the standards and specifications are, if the authors do not have the awareness of separating the document from the decoration, an accessible document cannot be created. How many authors have considered access from screen readers?
- The author cannot have a style sheet - that's the expectation, there is no decoration at all in the document. Therefore, authors need to be careful not to destroy the information (although it is fine to just write the document as usual).
- The specification contains no warnings or guidelines for accessibility.
- No solutions, alternatives, or directions are provided for expressions that reduce accessibility.
- It can be compared to the HTML 4.01 specification. HTML can easily break accessibility because of the author's freedom, but it can also be structured with care, and the notes in each chapter include practical advice.
- From the author's point of view: what content is there to distribute that gives up meta-information, clarification of relationships, and accessibility?
- Simplifying the markup language weakens the document (less information, lower accessibility/usability).
- Why specifications do not operate as targeted: human error
- Even if there is a specification for structuring documents, the problem is that humans cannot write structured documents. Therefore, the only way is to educate them or force them to do so. The specification undertakes the latter. The former is a human (social) problem, and is the part that humans are least willing to take on.
- For example, the HTML specification gives authors a certain amount of attention by explaining which elements and attributes are (un)recommended and why and in what situations.
- It is irresponsible to rely on the authors' (users') autonomy. Humans are always smarter or dumber than the specification. The specification designer should indicate the desired behavior to the user.
- The designer's responsibility is even greater if it is a native response format. This affects the quality of the distributed content. Therefore, Gemtext tends to be equated with the evaluation of the protocol itself. Also, those who are dissatisfied with the distributed content will try to control the quality of the content by revising the Gemtext specification.
- The FAQ begins like this:
Gemini is a new application-level internet protocol for the distribution of arbitrary files, with some special consideration for serving a lightweight hypertext format which facilitates linking between files. Gemini exists to deliver documents that are formatted plain text, or, to put it crudely, something better than plain text. If you want to make your documents accessible, you should use HTML.
- Given the low accessibility of Gemtext, it is not surprising that useful resources are not moving into Gemini!
- Simply put, the Gemtext language is inferior to HTML in the amount of information it can accommodate.
- Authors who want to give screen reader users the same information as visual representations will choose HTML (for example, emphasis at the inline level will be read with a strong accent).
- Authors who want to provide meta-information (such as contact information, licenses, etc.) in their documents will also choose HTML (the Gemtext language includes links, but does not imply a relationship with the document).
- Distribution in a lightweight hypertext language is not futile, but it is too functionally poor. I would like to see the document provided in HTML if it is of universal value. Because inline marks, meta-information, and so on can be used in many environments. If the HTML Living Standard is bloated, then HTML 4.01 or ISO-HTML is fine. If you want to advertise in Gemini, just link to it. Perhaps the coexistence of HTTP and Gemini will work that way. People will get local (subject-specific) information in a safe place and find meaningful HTTP content.
- If I were to join the Geminispace, I would provide HTML documents. This is because the documents I write are suitable for HTML (emphasis at the inline level, aiming for universal access, desire to provide meta-information, etc.).
- Balance. Specification Summary: Clients who can write in a weekend's time can only handle simple text. As a result, I would not choose Geminispace if I had to endure continuous blank lines, ASCII art, symbol-decorated headings, and other document forms that are not suitable for Gemtext. It goes without saying that a well-structured document is easier to read. Even in Geminispace, I need a content fitter.
- The difference between Gemtext and HTML is mainly semantics - as mentioned above, the amount of information that can be accommodated. Such as the
rel attribute to indicate the relationship between documents, the
cite attribute to indicate the URI of the quotation source, etc. Gemtext does not allow for the association of information to each line (it does not provide semantics).
- Therefore, the automatic conversion to HTML that hosting services sometimes provide is significant in that it can be browsed from the Web, but it does not increase the amount of information in the document itself.
- It may be less burdensome to parse a single line with a single function, but only humans have that (semantic) readability.
- The client can recognize the quotation, but cannot detect or get the source of the quotation.
- Even the writing of signatures and licenses is not standardized - it depends on the author's style. If we have a standardized format, both humans and machines can easily see where things are. This will improve accessibility/usability.
- Aggregators and search engines will also find it easier to process. For example, a uniform license format would make it easier to search for content under a particular license.
- Others found Gemtext unsightly:
- Stepping away from Gemini - Drew DeVault's geminispace:
I like to read medium- to long-form technical content. All of my favorite authors for this post only on HTTP
- Clearly, medium- to long-form technical documents are not suitable for Gemtext.
Halfway separation of document and appearance
- My concern stems from what happened in the early days of the Web, and what still happens on bulletin boards (in the form of plain text postings). Consecutive line breaks, letter spacing via whitespace, symbol rulings, and ASCII art. These cannot be eliminated even with style sheets (if the line break is caused by the
br element, it can be fixed).
- This indeed happens with HTML, but most website authors know HTML and CSS (a means of controlling appearance) and manage to separate documentation and decoration. The only sites that still use symbols and ASCII art are those that only allow plain text posting (bulletin boards and social networking sites), or authors with limited knowledge of CSS. In short, proper (text-only) information is achieved by having a place for authors to vent their egos. Readers can disable the author's style sheet and avoid the ego.
- Gemtext has no means of decoration. This is because it practices separation of document and appearance. The problem is that some authors either do not understand that principle or resist it. They try to improve accessibility/usability for the author/reader by decorating the document themselves. We can say we'll trust the client to do this. But until clients with a high degree of control over appearance come into vogue, authors will not change their tune. Just as the Web once was.
- The author doing the decorating may have accessibility/usability barriers (difficulty reading) in referring to the Gemtext document. Considering that the author is the assured reader of the document, it is natural to try to alleviate the barrier.
- ASCII art is not acceptable. This is because, unlike images, it is not a data format that machines can process. It cannot be reliably ignored (extracted), replaced with an alternative representation, or linked.
- ASCII art is not a logical presentation. Unless the purpose of ASCII art is to showcase ASCII art, all ASCII art can be missing and not interfere with document reference. If not, it is because it is being used as a substitute for some data format (especially text and images).
- Why should the title of a document be represented by ASCII art? There is no necessity. Unless it can be processed as data, ASCII art is a definite barrier to the user.
- Since it is not a data format, it cannot be eliminated by the specification. Existence depends on the author's judgment.
Paragraph, section, and topic separators are logical document structures, but text lines and blank lines have no such meaning in the specification.
- A blank line is an ornamental expression when taken to an excessive degree. I hope you understand how inconvenient a meaningless blank line (space) is.
- I do not know how it is in English-speaking countries, but in Japan, there are a certain number of authors who use excessive line breaks to express pauses. This is a form of procrastination of reference, as mentioned in 變らない人々、變らないWeb, and it prevents the user from accessing information. Scene changes and chapter breaks should be indicated as part of the structure of the document, and authors should not control headings and chapter margins.
- Headings and body text indicate document structure (sections), and authors do not need blank lines.
- In HTML, blank lines in the source do not affect the appearance, but they do in Gemtext.
- If document structure and appearance are separated, what is consecutive blank lines? Does document structure exist there? Why shouldn't the client collapse consecutive meaningless blank lines? The specification doesn't explain why; are you saying that authors who break 10 or 50 lines don't exist (there is a precedent in HTTP/HTML, and I'm afraid it's possible in Gemtext documents!).
- From 5.4.1 Text lines in the Speculative specification:
Consecutive blank lines should NOT be collapsed into fewer blank lines.
- No limit on the number of lines. A compliant client will render blank lines whether 100 or 1,000 lines. No consideration of author or editor errors.
- Why can authors control line spacing?
The specification does not say anything about the handling of whitespace characters on lines other than preformatted text.
- What is the justification for rendering consecutive whitespace characters, other than to reproduce the grammar of the language?
- If the grammar consists of only a single whitespace character, then two or more whitespace characters should be combined into one.
- If document structure and appearance are separated, what is consecutive whitespace characters?
- If the rendering of consecutive whitespace characters is tolerated, the author may use whitespace characters to adjust margins and letter spacing.
- How are tab characters handled?
- If the client renders consecutive whitespace characters, the entire document can be said to be preformatted text. Similar to blank lines, appearance control using consecutive whitespace characters occurs in HTTP/HTML and is also possible in Gemtext documents.
- In HTML, single-byte whitespace characters do not affect the appearance, but they do in Gemtext.
- In HTML, double-byte whitespace characters affect appearance, and some authors in Japan use this to control appearance.
- No limit on the number of characters. A compliant client will render whitespace whether it is 100 or 1,000 characters. No consideration of author or editor errors.
Significance of In-Line Marks
- Gemtext does not have any inline level marks.
- From 2.10 Why doesn't text/gemini have support for in-line links? in the Project Gemini FAQ:
Because text/gemini is an entirely new format defined from scratch for Gemini, client authors will typically need to write their own code to parse and render the format from scratch, without being able to rely on a pre-existing, well-tested library implementation. Therefore, it is important that the format is extremely simple to handle correctly. The line-based format where text lines and link lines are separate concepts achieves this. There is no need for clients to scan each line character-by-character, testing for the presence of some special link syntax. Even the simplest special link syntax introduces the possibility of malformed syntax which clients would need to be robust against, and has edge cases whose handling would either need to be explicitly addressed in the protocol specification (leading to a longer, more tedious specification which was less fun to read and harder to hold in your head), or left undefined (leading to inconsistent behaviour across different clients). Even though in-line links may be a more natural fit for some kinds of content, they're just not worth the increased complexity and fragility they would inevitably introduce to the protocol.
- From 5.1 Overview in the Speculative specification:
The format permits richer typographic possibilities than the plain text of Gopher, but remains extremely easy to parse. The format is line-oriented, and a satisfactory rendering can be achieved with a single pass of a document, processing each line independently.
- The value of the inline mark is to improve accessibility.
- Authors cannot make their warning notice stand out. Search engines (e.g., geminispace.info) cannot even highlight search terms. Therefore, people use spaces, symbols, and emoji to attract the reader's attention. As already mentioned, decorative expressions affect accessibility. This ad hoc substitution can occur, in part, through carelessness on the part of the author, but also because the markup language lacks the necessary markings.
- The significance of the mark is not only that it gives meaning, but also that the format (means of providing information) can be standardized.
- Information can be provided regardless of language, culture, writing style, or access environment. (Universal access!)
- What is the rationale for providing block-level quotations but not inline-level quotations?
- The absence of inline markings makes parsing easier for the client (and development easier itself). In other words, the client developer's convenience takes precedence. While developer/user autonomy is respected, is the impact on the quality of distributed content justified?
- Is being able to create a client in a weekend's time a benefit worth the low amount of information/accessibility?
- Text surrounded by asterisks is not always emphasis. Text enclosed in quotation marks is not always a quote. Markup language serves as a common marker to communicate information to people. The marks that Gemtext leaves out are too everyday, too substantial, too utilitarian.
Appendix: Notes on Protocol
- Opinion that Gemini has no commercial value and can be community-driven (by keeping the implementation simple): Gemini is Useless - Alex's space
- It is possible to insert advertisements (text, links, ASCII art).
- Opinion that TLS mandates do not consider hidden services: kill-9 - harmful - software - gemini
- The significance of implementing a protocol rather than a service or markup language is to ensure that the content is secure and simple.
- From 2.5 Why not just use a subset of HTTP and HTML? in the Project Gemini FAQ:
The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume *only* that kind of content in *only* that kind of way. It's impossible to know in advance whether what's on the other side of a https:// URL will be within the subset or outside it. It's very tedious to verify that a website claiming to use only the subset actually does, as many of the features we want to avoid are invisible (but not harmless!) to the user. It's difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers, so if somebody breaks the rules you'll pay the consequences. Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch. Even if you did it, you'd have a very difficult time discovering the minuscule fraction of websites it could render.
- Content does not return blank pages, replace content, or test whether the user is a human (e.g., Captcha).
- Markup documents with poor content (in terms of information content and accessibility) in widespread use
- HTML documents can also be distributed, but the client may not support it.
- Although the darknet is highly anonymous, it does not change the fact that most websites are composed with HTML and CSS and require a user agent that complies to complex specifications.
- As noted in 變らない人々、變らないWeb, site creators on the darknet (who even respect privacy) are not always familiar with and sensitive to accessibility/usability and HTML.
- I can only think of a (very local) light-weight diary as a use. But I prefer a micro web diary (a diary of thoughts in an ordered list):
- Is it suitable for people who are not familiar with markup languages or who have hassle with markup?
- I can't say for sure until there are more Japanese-language documents. I wonder if there are people who write regularly.
- I could relate to the idea, but I didn't have the necessary marks. I can't write a sentence without emphasis. Even novels have emphasis.
- My reasonable answer is to write in HTML. Rather than imitating HTML badly, mature, proven, universal-access oriented HTML itself is a safer way to provide documents.
- If everyone involved in the Geminispace does not think about accessibility, the quality of the distributed content will not be maintained. Especially since ASCII art used as a substitute for images is a detriment and will cause hell for those who have come for purely text. Project Gemini is sidelined by the current situation and feels very experimental and merciless. The reader is as helpless as ever. We have to wait for the specification or the client to get smarter (humans don't get smarter). A certain level of complexity is an investment in the user. At some point, the client will have to become complex for the sake of comfort (e.g., ignoring ASCII art, emojis, symbols in headings, etc.).
- From 2.5 Why not just use a subset of HTTP and HTML? in the Project Gemini FAQ:
Alternative, simple-by-design protocols like Gopher and Gemini create alternative, simple-by-design spaces with obvious boundaries and hard restrictions. You know for sure when you enter Geminispace, and you can know for sure and in advance when following a certain link will cause you leave it. While you're there, you know for sure and in advance that everybody else there is playing by the same rules. You can relax and get on with your browsing, and follow links to sites you've never heard of before, which just popped up yesterday, and be confident that they won't try to track you or serve you garbage because they *can't*. You can do all this with a client you wrote yourself, so you *know* you can trust it. It's a very different, much more liberating and much more empowering experience than trying to carve out a tiny, invisible sub-sub-sub-sub-space of the web.
- No, I'm protesting because I'm having to look at garbage. HTML/CSS can accommodate and isolate garbage somewhat more easily. That's why I still use HTTP.
- Gemtext language is vulnerable to human complexity.
- The quality of content also affects the motivation of client developers. Developers develop clients because they want to access the content, and if the desired content is not available, they will not develop. The question is whether the complexity of the design is worth the effort (return). If the complexity is deemed reasonable, the developer will begin work.
- In other words, Project Gemini has decided that meta information and inline marks, in addition to scripts and trackers, are not worth the effort.
- However, it did recognize the value of unlimited blank lines, emojis, and ASCII art.
- The low Gemini population is also probably related to differences in document structure. Like other markup languages, Gemtext has its own writing style and associated reading style. For those familiar with website conventions, Gemtext documents may be difficult to read.
- More than the specification itself, I am dissatisfied with the lack of guidelines for accessibility. Not to say that it should be as sophisticated as HTML. There is no all-purpose markup language. However, accessibility is a very ethical issue (because it creates information gaps), and a specification has a social responsibility. Society needs precepts.
- On the whole, Gemtext is tolerant, and in view of the prevalence of ASCII art, it will quickly become a mess as the population grows. I feel that it is a specification that relies heavily on human decency. Certainly that is a common fact of markup languages. But we dare not be vulnerable (handling of blank lines, whitespace characters).
- Sites can be created in plain text. How could it not be popular? I wanted to give everyone a warning before Gemini becomes popular.
- Writing never stops. Just edit and upload the file as is. Suitable for notes and diaries.
- Someone will certainly need Gemini. The challenge is to attract authors (resources). Spreading clients is also important. We need information.