💾 Archived View for gemi.dev › gemini-mailing-list › 000370.gmi captured on 2024-03-21 at 17:28:04. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
There?s a persistent worry on other threads that Gemini might become ?too complex?, for some definition of ?complex?. This is a reasonable worry, considering the very complicated mess we?re all running from. On the other hand, I think there?s a fairly, if not fully, general counterargument to all sorts of additions that we might want to make to the spec: ?There?s nothing wrong ? or even uncool ? about making a website with only HTML and, at most, 30 lines of CSS that looks great in Lynx.? Thoughts? Counterarguments?
Hello, > On the other hand, I think there?s a fairly, if not fully, general counterargument to all sorts of additions that we might want to make to the spec: I think if you want additions, just use WWW. Gemini focus on content and not formating. > ?There?s nothing wrong ? or even uncool ? about making a website with only HTML and, at most, 30 lines of CSS that looks great in Lynx.? Yes you can create cool website using some standard html tags and a little bit of css. But Gemini choosed its own gmi format specially to prevent some implementations to add this kind of cool features. > Thoughts? Counterarguments? WWW decadence was fun, let's never do it again :)
For me, I see nothing wrong with Gemtext and HTML living side by side. This isn't a zero-sum game, as much as the Web wants us to think it is with its focus on hyperscale. As Stacy mentioned, Gemtext is great for content and not formatting. If you want formatting, then use HTML! - meff Stacy Harper <contact at stacyharper.net> writes: > Hello, > >> On the other hand, I think there?s a fairly, if not fully, general counterargument to all sorts of additions that we might want to make to the spec: > > I think if you want additions, just use WWW. Gemini focus on content and > not formating. > >> ?There?s nothing wrong ? or even uncool ? about making a website with only HTML and, at most, 30 lines of CSS that looks great in Lynx.? > > Yes you can create cool website using some standard html tags and a > little bit of css. But Gemini choosed its own gmi format specially to > prevent some implementations to add this kind of cool features. > >> Thoughts? Counterarguments? > > WWW decadence was fun, let's never do it again :)
It was thus said that the Great Nathan Galt once stated: > There?s a persistent worry on other threads that Gemini might become ?too > complex?, for some definition of ?complex?. > > This is a reasonable worry, considering the very complicated mess we?re > all running from. > > On the other hand, I think there?s a fairly, if not fully, general > counterargument to all sorts of additions that we might want to make to > the spec: > > ?There?s nothing wrong ? or even uncool ? about making a website with only > HTML and, at most, 30 lines of CSS that looks great in Lynx.? > > Thoughts? Counterarguments? It's one of the anti-Gemini arguments I've seen on sites like Hacker News (https://news.ycombinator.com)---why not just use a stripped down HTML and webservers that do what you want? And yes, there is something to that agument, but solderpunk has made it clear he doesn't want any crack that will lead to the current web (and personally, I would love it if the "application web" went via QUIC and the "original hypertext web" stayed on TCP). The problem I see with gemtext (and having been on the mailing list from the beginning, way over half the messages have been about the gemtext format) is that people *want* their HTML, but it's mostly different subsets of HTML. About the only agreement is the absence of Javascript. Personally, I'm not a fan of the gemtext format as I find it restrictive in a way that I don't find plain text or HTML, but it is what it is. All I do is put up pages with the proposed specification and see if there are complaints (and there were---oh the surprise). Again, if you want formatting, HTML and Markdown are there for you to use on Gemini. -spc
It was thus said that the Great Stacy Harper once stated: > Hello, > > > On the other hand, I think there?s a fairly, if not fully, general > > counterargument to all sorts of additions that we might want to make to > > the spec: > > I think if you want additions, just use WWW. Gemini focus on content and > not formating. If gemtext was focused on content and not formatting, it wouldn't have headers, lists, or pre-formatted areas. My own websites: http://www.conman.org/ http://www.conman.org/people/spc/ http://boston.conman.org/ uses straightforward HTML (4.01 if anyone cares), and while I do use some CSS for formatting, it still has a structure that is visible if you strip away the CSS (on Firefox, if you go "View ? Page Style ? No Style" it is still readable). And you would have to really hunt about my websites to find the Javascript (it's there, just a very little bit of it). > WWW decadence was fun, let's never do it again :) I think I'm one of the few left that actually like hypertext qua hypertext. Sad. It's a neat concept. -spc
On Thu, 10 Sep 2020 23:17:19 -0700 Nathan Galt <mailinglists at ngalt.com> wrote: > On the other hand, I think there?s a fairly, if not fully, general counterargument to all sorts of additions that we might want to make to the spec: > > ?There?s nothing wrong ? or even uncool ? about making a website with only HTML and, at most, 30 lines of CSS that looks great in Lynx.? > > Thoughts? Counterarguments? I agree with this notion. text/gemini has a very simple format, still. I think there are several good reasons for that being the case: 1. It's easy to parse. You can write a parser in an afternoon, and a renderer for the terminal or your favorite GUI toolkit that same evening 2. It's easy to write pages. You can grasp every nuance of the document standard in an hour 3. It's human readable. You can easily read a text/gemini page as plain text because the markup is minimal 4. It has enough features to write very basic formatted documents, but not enough for the author to impose on the user Similarly, for HTML, there are good reasons for it being structured as it is. It supports nested documents that allow for greater control of formatting, but at the expense of all the reasons I listed for Gemini. If there is a good middle ground between HTML and Gemini, I'll happily support that as its own MIME type, but I think the final most important complexity that text/gemini should address is that it shouldn't be a "living standard". That has a huge cost to site admins and developers. -- Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200911/206a 58ba/attachment.sig>
> If there is a good middle ground between HTML and Gemini, I'll happily > support that as its own MIME type While I understand the desire to have something novel, there really is no need to reinvent the wheel here. The whole point of having mimetypes in gemini is so you can use whatever format you want to serve content. If you want basic linking and sections, use gemtext. If you want rich formatting (emphasis, boldface, etc) use markdown or asciidoc or any of a million lightweight markup languages. If you want deep control over the presentation of the document, use html. If you want no formatting at all, use plaintext. There's near certainty that there's an existing format that generally suits your needs unless you're doing something like math formulae, and even then you could just link to an image or use a pdf and LaTeX. The thing is, I think people have a misconstrued idea of what gemtext is. The long and short of it is that it's a gophermap with headers and code blocks. Sure, the syntax is different but at the end of the day that's all it is. If you can't live without stronger control over the styling and document structure you should just use a subset of html (There's absolutely nothing wrong with that! You can still browse gemini without having a gemini capsule yourself). You could even serve your html over gemini if you so chose, although I'm not sure how well it'd be supported by clients. > but I think the final most important complexity that text/gemini > should address is that it shouldn't be a "living standard". That has a > huge cost to site admins and developers. I think this should aim to be the highest priority over "making gemtext better." Obviously there's an exception right now since it's in the early stages and not finalized yet, but even now there shouldn't be massive changes made to the spec at all, let alone changes that turn gemtext into an ad hoc, impossible-to-parse implementation of half of html. -- Alex // nytpu alex at nytpu.com GPG Key: https://www.nytpu.com/files/pubkey.asc Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B https://e-mail.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200911/3d68 5ed3/attachment.sig>
It's true that the Gemini protocol is able to serve up a variety of file formats given its explicit requirement of mime-types in response metadata. I'm also happy with the simple stripped-down nature of the Gemtext format and am not looking for any major changes to be made to it at this time. However, I do want to throw in a counterpoint to recommending people abandon Gemtext and serve up more Markdown or HTML in Geminispace. While it is true that they can all be served up by the Gemini protocol, it is not currently the case that very many Gemini clients can render anything other than Gemtext. If enough people start to publish in Markdown and/or HTML, we may soon find our experience of surfing Geminispace to largely be about downloading Markdown and HTML pages whenever we click on links and then having to open the local files in our format-specific renderers of choice. HTML pages also reintroduce the issue of potentially requiring clients to download any number of auxiliary pages in order to render them. While we could hope that Gemini publishers will stick to a minimal subset of HTML (for each user's varying definition of "minimal"), there is no way to enforce this. This does not sound like much fun to me, and it would impose a much higher development cost on each browser developer as they would have to implement rendering engines for Gemtext, Markdown, HTML, etc. in order to provide their users with a more seamless browsing experience. Given uneven distribution of resources to maintain and extend clients, this could drive us down a path in which a smaller and smaller number of browsers come to dominate Geminispace as the number of requirements on what they have to render continues to increase. In a worst-case scenario, we ultimately end up recreating a post-web monopoly of Geminispace. Just my 2c, but I'd like to see more folks encouraging the use of text/gemini or text/plain in Geminispace rather than punting to more complex formats except in special cases. If anyone is feeling super restricted by Gemtext, I'd encourage them to spend some time on Astrobotany (gemini://astrobotany.mozz.us) for inspiration. YMMV, Gary Alex // nytpu <alex at nytpu.com> writes: >> If there is a good middle ground between HTML and Gemini, I'll happily >> support that as its own MIME type > While I understand the desire to have something novel, there really is > no need to reinvent the wheel here. The whole point of having mimetypes > in gemini is so you can use whatever format you want to serve content. > If you want basic linking and sections, use gemtext. If you want rich > formatting (emphasis, boldface, etc) use markdown or asciidoc or any of > a million lightweight markup languages. If you want deep control over > the presentation of the document, use html. If you want no formatting at > all, use plaintext. There's near certainty that there's an existing > format that generally suits your needs unless you're doing something > like math formulae, and even then you could just link to an image or use > a pdf and LaTeX. > > The thing is, I think people have a misconstrued idea of what gemtext > is. The long and short of it is that it's a gophermap with headers and > code blocks. Sure, the syntax is different but at the end of the day > that's all it is. If you can't live without stronger control over the > styling and document structure you should just use a subset of html > (There's absolutely nothing wrong with that! You can still browse gemini > without having a gemini capsule yourself). You could even serve your > html over gemini if you so chose, although I'm not sure how well it'd be > supported by clients. > >> but I think the final most important complexity that text/gemini >> should address is that it shouldn't be a "living standard". That has a >> huge cost to site admins and developers. > I think this should aim to be the highest priority over "making gemtext > better." Obviously there's an exception right now since it's in the > early stages and not finalized yet, but even now there shouldn't be > massive changes made to the spec at all, let alone changes that turn > gemtext into an ad hoc, impossible-to-parse implementation of half of > html. -- GPG Key ID: 7BC158ED Use `gpg --search-keys lambdatronic' to find me Protect yourself from surveillance: https://emailselfdefense.fsf.org ======================================================================= () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Please avoid sending me MS-Office attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
Gary Johnson <lambdatronic at disroot.org> writes: > However, I do want to throw in a counterpoint to recommending people > abandon Gemtext and serve up more Markdown or HTML in Geminispace. > > While it is true that they can all be served up by the Gemini protocol, > it is not currently the case that very many Gemini clients can render > anything other than Gemtext. If enough people start to publish in > Markdown and/or HTML, we may soon find our experience of surfing > Geminispace to largely be about downloading Markdown and HTML pages > whenever we click on links and then having to open the local files in > our format-specific renderers of choice. I see this largely as a feature, not a bug. HTML desired to be just this, the de facto and de jure landing spot on the web. It's now become a vehicle for everything: for applications hooking into a Document Object Model to modify state, for semantic markup, and for layout. This has also largely driven innovation into HTML away from other formats, because HTML is the format that everyone sees. > This does not sound like much fun to me, and it would impose a much > higher development cost on each browser developer as they would have to > implement rendering engines for Gemtext, Markdown, HTML, etc. in order > to provide their users with a more seamless browsing experience. Lightweight markup formats like Markdown and ReST are readable without your browser formatting anything. Lightweight clients can get away with not parsing anything and dumping a set of MIME types directly to the user (either on-screen, to stdout, or however the browser works). HTML has high quality parser implementations on various platforms in various languages. XML also usually has good quality parsers available on most platforms/languages. HNGopher, a Hacker News Gopher mirror, uses w3m to render HTML content into plain text. Nothing is stopping Gemini browsers from shelling out to w3m on platforms that have it available and rendering content this way. - meff
On Thu, 10 Sep 2020 23:17:19 -0700 Nathan Galt <mailinglists at ngalt.com> wrote: > There?s a persistent worry on other threads that Gemini might become > ?too complex?, for some definition of ?complex?. The only problem I've had with Gemtext is that it so closely resembles Markdown that sometimes I use the wrong syntax for URLs when I'm drunk. This isn't a bad thing, incidentally. Gemtext lends itself well to a Gemini-first/Web-second approach where you write your content as Gemtext first, then copy the file to the same name with a .md or .markdown extension, change the link syntax, and add frontmatter if you're using a static site generator like Jekyll, Hugo, or Pelican. Hell, you could probably just use pandoc and a makefile if you know what you're doing. Or, you could just take your gemtext, change the extension, and manually wrap everything in HTML tags. > On the other hand, I think there?s a fairly, if not fully, general > counterargument to all sorts of additions that we might want to make > to the spec: > > ?There?s nothing wrong ? or even uncool ? about making a website with > only HTML and, at most, 30 lines of CSS that looks great in Lynx.? > > Thoughts? Counterarguments? I think a lot of people concerned about web bloat would benefit from being directed to the following websites even if their names might be offensive:
On Fri, 11 Sep 2020 08:59:38 +0200 Stacy Harper <contact at stacyharper.net> wrote: > WWW decadence was fun, let's never do it again :) This should be added to the fortune cookie databases used by the BSD fortune utility. =^.^= -- Matthew Graybosch https://matthewgraybosch.com #include <disclaimer.h> https://starbreakersaga.com gemini://tanelorn.city "Out of order?! Even in the future nothing works."
On 9/15/20 2:50 PM, Matthew Graybosch wrote: > Hell, you could probably just use pandoc and a makefile if you know > what you're doing. I do that for my website (gemini://irth.pl / https://irth.pl). Gemini is simple enough to write a converter for yourself in like, two evenings: ? https://git.r23s.eu/wojciech/gm2html ? (I don't have a Gemini git front-end set up yet, excuse me :)) I run it with a Makefile to generate .html files, and I wrote some nice CSS to style it: https://github.com/irth/website/blob/master/Makefile For relative links it changes the .gmi extension to .html automatically, so links work well on both versions. If anyone wants, you can borrow my CSS, I'll probably add an MIT license and a README to the repos when I find some time and willpower. > It's still not that hard to create a static website if that's what > people really want to do. I just wonder if they've forgotten how. It is possible, but having a specification that forces you to do that allows the reader to have some expectations before clicking a link. If I see a gemini:// link, I know I won't have to sit through a few seconds of loading up all the javascript before seeing the text :) -- Wojciech ~irth Kwolek - gemini://irth.pl - https://irth.pl -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200915/74ea 37f5/attachment.htm>
---