💾 Archived View for rawtext.club › ~sloum › geminilist › 000395.gmi captured on 2020-09-24 at 02:36:02. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
solderpunk solderpunk at SDF.ORG
Sun Jan 19 20:01:23 GMT 2020
- - - - - - - - - - - - - - - - - - - ``` On Sun, Jan 19, 2020 at 08:15:14PM +0100, Brian Evans wrote: > I've mostly been sitting back through all of this list and raw mode > talk, only occasionally popping in small points here or there. But > I figure if this is a community decision it is good if those in the community > voice their support or lack of support for ideas. It definitely is, if people who don't feel good about proposed changeskeep quiet and all I hear on the list is agreement it will just lead tothe most vocal members driving things. I'm glad you've spoken up. This will be a quick and kind of partial reply, sorry. But, verybriefly, I understand the concern about lists (of all the recentproposed changes, they are the least valuable IMHO because they onlyconcern presentation). How do you feel about the heading proposals?IMHO they are probably the most valuable of these changes because theycan be totally ignored from the perspective of presentation and yetstill do genuinely useful stuff, like automatically generated tables ofcontents, which do nothing but make large and well-structured textcontent easier to read, or help with automatic generation ofuser-friendly menus or feeds to bodies of content. That's good stuff,surely? > I really do not want to, and likely will not, add support for lists in my current > or any future gemini client I make. I don't see the point. As I intend to actually write all this stuff in the spec, if I decide toadopt it, supporting the list line types will be strictly optional, sothis is absolutely fine. For a text-based client like Bombadillo, thedifference between supporting lists and not is an extremely smallaesthetic thing that some users probably won't even notice. > I do appreciate all of the work and thought that has gone into trying to > figure these things out. It just feels unnecessary for a simple protocol > like gemini. Why get complex when just serving markdown or html or > whatever you like will do the job and people can read it as they see fit. > We are definitely starting to get into the territory with the proposals > where some client authors will support some things and some wont... > which will create a fractured view of gemini to users. So why not keep it > simple and cohesive by just having links and move on to other things? The fractured Geminispace thing is a real concern, but actually I thinkan argument can be made in both ways here. If text/gemini is keptextremely simple and plain and the official policy is "Serve Markdown orHTML if you want even basic text styling" then people may well do that.Some clients will add support for rendering those but many won't becauseit's so much more complicated (far worse than what has been proposedhere!). Then we end up with two regions of Geminispace, the text/geminisubspace which anybody can visit and the Markdown subspace which onlypeople using the fanciest clients can visit. IMHO, this is a worse kindof fracturing than one where we adopt the proposed new text/geminisyntax and different clients implement different subsets of the optionalfeatures. After all, the only reason I've been so positive about theserecently proposed changes is that they all seem to degrade verygracefully if a client doesn't recognise them and treats them equivalentto text. The degree of fracturing possible is actually very slight. > Just my two cents at the moment. One cent of opinion from client or server authors is valued equal to onedollar of opinion from anybody else. :) Cheers,Solderpunk