There’s a new proposed lexicon for Markdown-based content in AT Proto. I could support this. The problem is that currently there’s no good way to have multiple formats, and I think HTML is still the richest, most complete way to represent blog posts.
@gmclean I think the goal is that eventually we could have lots of different Bluesky-compatible clients that could display blog posts (or edit them?) in a consistent way.
@manton I think HTML and markdown have a complex relationship.
If I dial back to the HTML I wrote in 1996, it was very much a data output format. Eventually adding some cascading style sheets so that you could control some basic rendering of that data format.
But as the technology expanded, HTML and CSS have essentially become rendering and display formats. We deprecated H tags and P tags for DIV and SPAN tags. That's kind of when Markdown down came into existence. To render structured text without CSS concerns.
So I think the underlying question with a blog is really a decision about what you are trying to produce. Are you trying to produce a structured data file with some styling? Or are you trying to produce a digitally rendered interface?
In the case of a blog post, I can see both outputs as equally valid depending on context. So I can see value in both. This may be a case for author's intent. If an author doesn't intend for a markdown post, then maybe it can't be output that way?
@manton Hi, author of the proposed Lexicon here! So the context for this proposed Lexicon is built on two stakes:
There are a lot of us out there doing really interesting things with static site generators and automating putting that content on ATProto so it can be read by a variety of tools that sit on the protocol like GreenGale or PotatoNet App. In this way, the goal is to present the capability to consume ATProto in the style of an RSS Reader as much as a Social Network. Making the content as generic as possible while providing tooling to hint at rendering complexity for willing clients is how I see a way to make that possibility become closer to reality and more likely to be adopted. The goal is not so much to use ATProto as a blog here (though that is very possible!) but to offer content through ATProto as a distribution venue.
Markdown has become a sort of standard language for offering content up generically outside of RSS. I love RSS and I don’t intend to undercut it when I say this (there’s also an extension that allows you to put MD in RSS out there). But there seems to be a growing number of tools that read and speak Markdown, and by presenting Markdown as simply as possible it makes it available to them. In this sense it acts as a very useful fill-in for the standard.site Lexicon, which provides a generic content field that can be filled with a lexicon-defined object. This is, as far as I can see, the most generic version of that object and the most accessible to readers and writers of the specification; opening it up to more people to use, in part to drive the reasoning above.
To answer @gatesvp - The goal here is to produce a feed of content with hints that allow for richer styling–if the reader view wants to use them–but not require anything other than a render of plain text. It is essentially exactly as you say - an offering of structured text that can be rendered without CSS.
LMK if that answers the question! Would love to get feedback if you’ve got it.
@Chronotope Thanks for the details! I’ll take a closer look. We already support the Markdown in RSS extension across Micro.blog too.
@manton — there’s so much happening with RSS, eventually they will see it too and will just interop without all the unnecessary reinvention.
@manton @nicobao.dev It’s intended to support more detail for the standard.site lexicon that is aimed to support Posts. It isn’t its own lexicon, so much as it is a lexicon intended for use inside others’ lexicons.
@manton It’s def at a proposal state, so the goal is to get feedback. LMK if there’s something working or missing. I’m working on updates based on feedback here - github.com/AramZS/ma…
@manton @manton Would love any feedback from you as well.
@dave I hope so! The goal here is to make the solution as interop as possible with an RSS-y way of thinking, which is to provide the tools to rendering surfaces to do what they want but maybe also some information to get a richer-to-the-intended-mode rendering process if they want it.
